项目中的，不能设置带key的PF
带key的PF的弊端：
1）如果pf未设置key，最后添加的记录肯定在pf的最后位置。如果设置了，就会按key值排序存放。发生问题，不能查找最后一条记录。
比如一个系统突然发生一个故障，如果要分析原因，就会从数据开始查找。每个pf obj，400系统都有最后修改时间记录，但是对应这个操作的数据，因为PF带key，而无法查找。
2）无法调整系统对key文件的维护时间。所以对带key的pf每写入一条记录，系统就要立即自动维护key文件。对几千万条pf的key文件维护，就要占用大量的系统运行时间。
IBM建议，一个pf关联的lf，或连接文件，最好不要超过10个。对非必要的lf维护，可以人为的安排到系统较闲的时间再做维护（LF生成编译中有参数设置维护时间策略）。
注释：
1)如果pf中带有其它条件过滤参数，会使得建立在这个pf之上的其它文件数据丢失。
2)对一个pf之上的lf超过10个，且必须使用另外的索引条件的应用，可以采用400 query，或RPG程序描述文件来生成定义索引文件。对可以实现MQT的OS400系统，建议采用MQT。
其它：
观点1： LF只存记录号,这些记录号是按照LF的key排序的。
答：不对，必须存在key值排序和对应的pf记录号。想想看，如果做过c+树的排序计算方法，就知道了。如果只存在按key值排序的记录号，当往pf中添加一条记录后，系统拿什么数据来做c+树排序呢？
问：若通过一个LF往PF中写入记录，在lf维护前使用lf会产生什么样的影响？是否有这条记录吗？
答：肯定有问题。所以编程策略要制定好。
通过lfA写入的记录，系统会马上对这个lfA进行维护。但是，建立在与这个lfA关联的pf之上的其它lf，就可以不一定要立即维护。
阅读(1779) | 评论(4) | 转发(0) |
