If the manual doesn't state the content of R1, don't rely on it :-) The only thing you really need to sense EOF is to know that the branch to the specified EODAD has been taken, so (as you mention) I would normally keep MYEODAD DS 0H outside the loop.
I'm not aware of any quirks of IDF, so I'll just say that at MYEODAD you should still have addressability, so there you could set a MYEOF flag in your working storage followed by BR R14, then change your loop's code to check that flag every time, using TM, CLI or whatever. The performance penalty for this should be small. Roops On Wed, 8 May 2024, 23:35 David Eisenberg, <[email protected]> wrote: > I hope someone can help me; my question pertains to the QSAM GET macro. > Please consider this code snippet: > > OPEN SYSIN > GETLOOP GET SYSIN,BUFFER > MYEODAD DS 0H > <branch to label EOF at end-of-file ???> > B GETLOOP > EOF CLOSE SYSIN > * > SYSIN DCB > DDNAME=SYSIN,MACRF=GM,DSORG=PS,RECFM=FB,EODAD=MYEODAD,LRECL=80 > > I've deliberately placed the EODAD address immediately after the GET. My > question: is there anything I can test immediately after the GET to > determine whether a) I successfully read a record, or b) I've reached the > EOF? > > The IBM manual says that after a GET, R1 points to the record that was > read; however, I don't see any indication in the manual of where R1 points > when the EOF is encountered, nor do I see any return code setting in R15 at > EOF. I have empirically observed that at EOF, R1 points to an area in > storage containing the string 'EOV ', but I don't know if I can rely on > that. > > Does GET tell me anything when the EOF is reached? Or is there something > in the DCB that I can test to tell me that I'm at the EOF? > > (I know that it looks silly to have the EODAD in the middle of the GET > loop. This is about my trying to overcome an IDF limitation regarding > single-stepping.) > > Any help would be appreciated; thank you! > > David >
