With regard to using READ AT END / NOT AT END, I use it quite often, and I believe it can be safe IF you DON'T include the FILE STATUS clause in the SELECT statement. This causes (for NON-VSAM file) an abend if there is an I/O error, which in my mind is perfectly acceptable. YMMV.
I've required IBM support something similar for VSAM processing, and while they agreed to it years ago they have yet to implement it. So in any case where you specify FILE STATUS I agree that you should not use [NOT] AT END (and [NOT] INVALID KEY), but rather you should check the associated FILE STATUS field. Or you can use DECLARATIVES! As for the "religious" titles for my sections, that was just a bit of whimsy. Hope I did not offend anyone! Frank ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Bill Woodger <[email protected]> Sent: Friday, August 12, 2016 12:09 AM To: [email protected] Subject: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding) I may have to reply initially with a thesis on "Not using FILE STATUS considered harmful - and AT END even without NOT AT END is a worse pain" (I'll leave the sub-tiles for later). PROCESS-MY-FILE. PERFORM UNTIL EXIT READ MY-FILE INTO MY-RECORD AT END EXIT PERFORM NOT AT END PERFORM PROCESS-MY-RECORD END-READ END-PERFORM. What happens here if something "goes wrong with the file", something not quite bad enough to kill the program, but something bad enough to get a non-zero FILE STATUS? You get a Big Fat Loop. AT END and it's brother are "ephemeral". Beyond the END-READ they do not exist. The point about a "priming read" is not so much that you have to have two READs, it is that you have two READs where there is a simple distinction (first vs not-first) which is highly useful and which doesn't bog-up your other plain ordinary file-processing logic. Empty file - is that OK? "Header processing"? Do you want to jam those into AT END/NOT AT END? OK, you don't always need those - but does that drive you to having different constructs for processing a file? With the priming-read, the processing of a record is only entered - when there is a record. With the "read a record other than logically the last thing" there's always code to skip out "just in case" the end-of-file happens (it pretty much always happens, and potentially at least, always does happen). Unfortunately I don't have time to read more now. I have to say that the religious jargon is entirely unknown to me, but I think if I just treat it as a "progression", I'll be on the right track? I'm not going to look up religious words on the internet for any nuance, just to be able to understand this better - so if there is more meaning to their use than "progression", please let me know :-) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
