为什么有时有重复纪录会造成程序死循环
以下就是一个重复纪录回造成死循环的典型例子。
F_KEY是FILE1的第一个KEY.
STD_RTG是被程序许多地方调用的标准子程序。程序员不动脑筋地就把它抄过来使用。
如果程序中有两个或以上的纪录的KEY值相同，那么当READ读到第二条重复的纪录之后，
本来FILE1的指针时指向第二条重复的纪录后面那条记录的，可是子程序中的CHAIN又把
FILE1中的指针扳回到第一条重复纪录的右面，也就是第二条重复的前面。。。
F_KEY是文件FILE1中的KEY FIELD.
C KEY1 SETLL FILE1
C READ FILE1
C DOW NOT %EOF(FILE1)
C ...
C EXSR STD_RTG
C ...
C READ FILE1
C ENDDO
C ...
C STD_RTG BEGSR
C ...
C F_KEY CHAIN FILE1
C ...
C ENDSR
[ 本帖最后由 franliu 于 2009-11-25 07:55 编辑 ]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
使用UNIQUE是一个好的办法，可是由于历史的原因，许多现成的软件包都不使用UNIQUE.
大型软件公司的产品，需要雇佣许多程序员。由于成本的关系，有所多程序员是新出炉的菜鸟。要全面控制程序质量是很困难的。一个折衷的办法就是允许重复，这样总比结果却胳膊少腿好一些。
如果你自作主张加上了UNIQUE, 那些没有出错控制的程序就成了*MSGW, 有出错控制的可能就“死人不管”假定写或者更新成功了。。。
某ERP软件中有50%程序以现有纪录中最大的流水号码加以一的办法来生成新流水号的。
这样的逻辑，在多用户环境，再加上在缓冲区里没有被写进磁盘的纪录的因素，不重复有可能吗？
要把这些烂程序重新写一遍工作量太大，没有人愿意干哪吃力不讨好的活。干这种活写不出漂亮的报告。
研发部主任宁可计划发出新的版本或者至少 NEW RELEASE, 可以借此向大老板邀功。
最多做个重新排序的程序应付一下。。。
这就是现状。。。
还有一点要提一下，使用了UNIQUE之后，为了防止重复，写纪录就不可以一块一快写了，只能一个记录一个记录写，程序运行要慢得多。
[ 本帖最后由 franliu 于 2009-11-26 15:32 编辑 ]
我们建立的逻辑档一般不可能KEY值重复的，重复的一般写不进去
本来就要靠key值来定位查找记录，不唯一有什么用
明显的和无条件的死循环通常在程序测试阶段就被排除了。只有那些隐蔽的才能通过测试，被放进实际运行的环境中去。
总之我想拿出来跟大家分享的是排除系统故障的一种思路。希望对大家有用。
而且，养成在循环内不使用任何会移动主循环内文件指针的操作的好习惯。
其实很多死循环是在不经意时才会出现的,,要是知道了在写出来就没意思了..
胖有形的手册里第几页介绍这种情况啊？你有没有搞错啊？请把页号告诉我。
我大略看了《手册》，他所讨论的死循环都是无条件的，属于菜鸟程序类。这类东西都不可能通过测试进入正式运行的环境。我拿出来讨论的问题是只有当有重复纪录的时候才死循环的例子。
这个问题胖有型的《ILE程序员速成手册.doc》里面有详细说明，大家可以看看，
不好意思，记错名字了
http://bbs2.chinaunix.net/viewth ... p%3Bfilter%3Ddigest
[ 本帖最后由 insmile 于 2009-11-25 12:35 编辑 ]
这个例子挺经典的,,不过最好逻辑文件的key该为唯一的,比较好..
这个是值得深思，但是一般情况下都不会去用同一个文件来读两次的，要做也是两个不同的LF
发生死循环多了一个调试的思考方法
[ 本帖最后由 lizi211314 于 2009-11-25 09:14 编辑 ]