当恢复PF后，原有逻辑文件关联错了是怎么回事

35200159

当恢复一个PF后（因为不是我本人做的，不知道是用的RSTOBJ，还是直接拷贝），系统会自动建立一个备份的PF，这时，原有的逻辑文件关联并没有发生变化，而是关联到了备份的那个PF上，所以应用出了问题，
有二个问题，一是在什么情况下，系统会自动建立一个备份的PF，二是，为什么系统关联会出错，不知道我描述的清不清楚，希望有知道的朋友告诉下，谢谢

xuguopeng

因为RST前的PF和你备份中的PF不同,所以系统会自动重命名以前的PF,如果你只是要RST数据,最好是RST到别的地方再CPYF,或把原来的删除再RST

35200159

"因为RST前的PF和你备份中的PF不同",是指什么不同？，结构是相同的，数据肯定不同，但我现在测试，数据不同，不会产生备份PF，我现在想产生都没办法产生了，

qingzhou

原帖由 35200159 于 2007-7-18 14:21 发表
"因为RST前的PF和你备份中的PF不同",是指什么不同？，结构是相同的，数据肯定不同，但我现在测试，数据不同，不会产生备份PF，我现在想产生都没办法产生了，

就是说，你当前存在的PF文件和磁带中备份的PF文件存在差异，所以当执行RSTLIB/RSTOBJ动作后，系统会自动检测当前的PF文件情况。当发现数据存在差异，系统出于安全考虑，会将PF重命名，以免被误覆盖。所以 guopeng建议是先RST到个人LIB下，然后再cpyf或insert到当前PF中。

另外第2个问题，LF是依赖于PF存在，其实质是PF文件的“索引”，PF与LF关系好比SQL2000中table与index关系。所以，维护PF时需要格外当心，尤其是关联LF的时候需要用dspdbr去检测PF与LF的关联关系。

passthru

不知道搂主对上两位的解释理解了没有？

OS/400操作系统是建立在db2之上的操作系统，所以as400上的任何操作都可以用操作数据库的角度进行考虑。

经常做开发的人员会经常看到check level error信息。因为as400 obj都是基于一个32位（还是48位，还是128位，我目前手上没有环境查看）的连结信息进行系统登记。如，一个rpg程序文本创建，就会产生一个连接信息进行系统登记；该程序编译成功就会，就会有一个新的连接信息进行系统登记；在用系统脚本命令call这个rpg obj，系统就会去在运行环境（路径）下，找到第一个满足条件的obj进行后续操作。

lf都是基于pf之上连接信息创建的，在系统中进行登记。pf的变更都会使得相应的lf连接信息发生变化（这些信息的变化，os/400让用户在创建lf前，做出策略选择，如创建一个lf时，用f4参数进行设置。话题扯远了，呵呵）。

如你所说，restore的pf，不能用保留的lf使用，就是os/400登记的连接信息不一致，肯定会报check level error。

恢复办法：
1）如果，你确定要恢复到备份日期的断点，就把现有基于这个pf的所有lf，以及基于这些pf和lf之上的程序重新编译。这是一种非常生硬的手段。这样做，等于系统重新创建了个obj的连接信息。

2）二楼的操作方法比较柔和。   把这个pf改名恢复或恢复到自己的lib下，然后用copyf替换现有的pf数据。这样做，a）保留pf和lf的系统登记连接信息不变；b）因为一般编译lf都采用系统默认值：当pf数据变化时，lf立即随之变化。当pf数据copyf后，os/400系统就会立即创建新的lf和更新连接信息，并登记。

是不是太复杂了？不知道我表述清楚了没有？

[ 本帖最后由 passthru 于 2007-7-18 16:36 编辑 ]

35200159

三位大侠说的我都明白，但为什么我现在恢复一个文件，数据肯定不同，系统即没有自动建立一个旧PF的备份，LF也没关联错，我想知道我说的情况是在哪个特定情况下产生的，我现在想重复一下LF关联错误，却做不出来这样的结果了

passthru

呵呵，都明白还再提出不明白问题。

old pf文件内容：

a1 ...
a2


new pf文件内容：

a1
a2
b1

index lf 文件内容：

a1 （pf地址）
a2 （pf地址）
b1 （pf地址）

如果用old pf文件替换new pf文件，b1就会产生错误。（假设obj关系保持良好）
如果用old pf文件内容替换new pf文件内容，b1就会在系统自动重建lf过程中去掉。