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
