At 05:54 -0700 on 10/25/2011, Charles Mills wrote about Re: Looking
for clues on a bug in assembler:
My conclusion was the following sequence -- and there may be other details
that are significant, but this is my best guess as to the significant
details:
1. OPEN DCB, no error
2. GET DCB --> Drives SYNAD exit as expected
3. CLOSE DCB, no error reported
4. OPEN DCB, no error
5. GET, GET, GET, ..., GET (last record), GET --> QSAM branches to "random"
address, not the specified EOD address --> S0C4
However, if between steps 3 and 4 I add a step to restore the DCB to the
values it had before step 1, then all works as expected.
This behavior is contrary to the clearly stated QSAM CLOSE documentation:
"The fields of the data control block (DCB) and DCBE are restored to the
condition that existed before the OPEN macro was issued, and the data set is
disconnected from the processing program."
Have you tried writing a sanity check program? Have it do steps 1-3
and compare what is in the EOD field before and after steps 1 and 3.
If the field has not been restored then this should catch it. Also
try doing a compare of the copy of the DCB that you use for the
restore with the DCB which was opened and closed. That should show a
bad restore. Doing snap shot dumps of the DCB and DCBE at each stage
should show the failure. Sending that in should help document the
problem as it occurs.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
