如何在已有資料的physical file中增加一欄位?

qingzhou

[quote]原帖由 "WT99"]已上三種方法已試過,都成功啦!謝謝各位的不吝指教! 總結下,感覺用CHGPF, Source library/file/member處指定改後的source來源,level check改成*no的方法最簡單.[/quote 发表：


对于修改PF，我有如下建议：

1。首先通过CPYF将数据做备份；

2。然后将需要修改的PF的代码做备份；

3。如果该PF有关联LF，通过DSPDBR找到关联后用DLTF删除LF（注意：不是用RMVM删除物理的LF的source）；

4。修改PF，将需要修正的字段进行调整，建议是改大，而不是改小，否则容易会出现错误；

5。利用CHGPF进行重新编译PF, Source library/file/member这3个参数要明确指定来源，这点很重要；

6。编译PF成功后，重新用CPYF将数据拷贝回来；

7。确保无误后删除备份的PF。

另外，我还得提提建立“公共数据字典”（PF）的好处。

我们平时在开发系统时可能都没注意要建立数据公共字典，什么叫“数据共同字典”呢？通俗的说就是将整套系统中所有涉及的、具有公共属性的字段归纳成一个PF文件来处理，其他相关PF可参照这个公共PF来套用属性，这样组合成的PF就叫做“公共数据字典”。那我们不禁会问？这样做有什么好处呢？不是多此一举吗？

我们都知道，日后在维护系统时，公共数据字典给我们带来的好处就很明白了。

例如：我现在要修改某个PF中某个字段长度，如果没有建立公共数据字典，那你可能要修改整套凡是涉及这个PF的代码，可想而知维护量是多大，万一有什么地方疏落，那就麻烦大了。 有了公共数据字典，我们只需修改这个公共数据字典即可，然后重新编译一下，其他相关参照的PF文件都顺理成章修改过来，减轻了多少维护负担和风险。


还有，不建议采用“level check改成*no的方法”来偷工减料，这种做法存在极大的数据安全隐患，对于这个问题，我也曾经和IBM资深工程师、培训的老师交流过，都一致否定这种做法。大家都知道企业数据的重要性，不要贪一时方便而日后给自己留下无穷的祸害，重新编译吧。。。

giraffe

有了公共数据字典，我们只需修改这个公共数据字典即可，然后重新编译一下，其他相关参照的PF文件都顺理成章修改过来，减轻了多少维护负担和风险。？？？？？
我测试了一下，当参照文件字段长度修改了，而参照的PF文件的字段不能随之更改，也得必须重新编译。

qingzhou

当然都是要全部重新编译，没说不编译呀。
我一开始就建议不要采用“level check改成*no的方法””来偷工减料，这样做是很不安全的做法，数据也存在安全隐患。
如果整套系统牵涉的PF、LF、DSPF、PRTF、CLP、RPG很多，开发人员都是会采用编写一个专门用来编译的CLP程序来实现连锁编译机能。

另外，采用“公共数据字典”还保证了系统后台PF的统一性。

fairyboy

恩，一般大的系统都有他的公共数据库PF，各使用部门的数据可以相互交换的。

pl421

受用

thursday

为什么我用CPYF拷贝不了，从一个库里到另一个库，而用3在OPT，就能拷贝阿？

thursday

我发现在OPT打3也能拷贝数据阿！可以吗？

ibmas400

晕~~~

  Copy File (CPYF)是拷贝数据，Copy Source File (CPYSRCF)是拷贝源码，2者会一致么？

另外，该帖解答得很好，建议斑竹设精。

raydream

如果没有LF，只要用SQL语句就可以实现了