We experience this S737 abend maybe once every couple of years where a JCL-allocated GDG actively being updated by one batch job can be deleted by a TSO user or another batch job. We found it very hard to believe this could even be possible but we did recreate the problem and found that our job scheduling product TWS was responsible for disabling this very basic MVS data set protection.
To recreate, we used a simple two step job. Step1 allocates the GDG(+1) DISP=(NEW,CATLG) and Step2 updates GDG(+1) DISP=OLD. If step2 abends (or the job is cancelled in step2), then we are ready to use TWS to restart the job in step2. After TWS submits the restart, we are then able to issue a TSO DELETE command, or use ISPF 3.4, or submit another batch job to delete it. Eventually the restarted job abends S737. We found that when we display the enqueues for the GDG being created using 'D GRS,RES=(SYSDSN,<gdgbase>)' that two enqueues are returned, one for the GDG base and one for the actual data set name for the GDG. For the restarted job, the enqueue for the GDG base is not present, which presumably allows the data set to be deleted even while allocated to another job. Anyways, we just want TWS job scheduling customers to be aware of this exposure. If anyone has seen any unexplainable S737 abends in the past, it just may be that their job scheduling product may be involved. ---------------------------------------------------------------------- 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
