> unreasonable to expect CLOSE to do anything for you I hear you. I suspected as much already. OTOH, the DFSMS manual says what it says below about CLOSE unconditionally; it doesn't say "if DCBOFLGS is on."
> Have you checked... Yes, it works correctly in all other cases that I have tested. > you are probably already priming your working DCB Indeed I am. I anticipated the answer on this forum "how hard could re-priming be?" You know how it is: the other guy's programming issue is always simple, because you only know about the one issue, not all the surrounding complexity. Re-priming it (which I am currently resigned to doing) is obviously not the greatest programming task ever but it is more difficult than trivial. The DCB is one of three in an assembler subroutine package called from a HLL; the DCBs are opened, read/written, and closed in an unpredictable order (from the package's point of view). There is a lot of common code that "doesn't know" which DCB it is pointing to. I currently prime the three DCBs once in one big MVCL. It's going to take some cleverness to re-prime one DCB under the right circumstances without writing code that is offensively kludgey, or re-designing the whole module. (There's currently no "back pointer" from a working DCB to its model, and seeing as how you can't simply code [you have to "build"] an ADCON in a DSECT, and as how DCBs are different lengths [requiring a different or executed MVC], the solution seems more complex than the problem deserves.) I could easily clear RECFM, LRECL, and BLKSIZE at the time of the ABEND but I wonder if there are other fields (buffer pool?) that have a similar problem. I can test, but will one ABEND behave differently from another? Do I have to test every possible OPEN and I/O ABEND? The "DFSMS Using Data Sets" discussion of DCB ABENDs implies you are pretty much on your own. I suspect this is one of those classic MVS stories. When the gurus of the sixties designed QSAM, the theory was that after a DCB ABEND the program went away, so it didn't matter what state anything was left in. Then, some other guru thought up ABEND recovery ... Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of ibm-main Sent: Saturday, January 21, 2006 7:29 AM To: [email protected] Subject: Re: QSAM DCB not restored by CLOSE following S013-18 on OPEN Have you checked DCBOFLGS? If the DCB is not marked as OPEN, it may be unreasonable to expect CLOSE to do anything for you. This would account for why you see the same whether you issue the CLOSE or not. You may be expected to clean up your own DCB in an ABEND scenario. Have you checked that RECFM, LRECL, and BLKSIZE are restored to zero in a non-ABEND scenario? As for "brute force", if you are writing reentrant code, you are probably already priming your working DCB from a static, clean, unused DCB anyway. At 2006-01-20 20:35, Charles wrote: > From "DFSMS Macro Instructions for Data Sets" > >2.3.9 CLOSE--Disconnect Program and Data (BDAM, BISAM, BPAM, BSAM, QISAM, >and QSAM) > >The CLOSE macro creates output data set labels and allows you to position >volumes. 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
