The short answer I think is yes - yes it is TWS's fault. Yes, as suggested, if I specify the absolute GDG data set name in the JCL, I see only the enqueue for the absolute GDG data set and no enqueue for the GDG base. And MVS/DFP does not allow the data set to be deleted by another tso user or batch job in this instance (as we all hope and expect). I don't know for sure if it has to do with enqueuing on both the GDG base and the actual gdg data set. I don't know why it is possible in some circumstances for a TSO user or some other job to delete a gdg allocated to a job restarted by TWS, but TWS is apf-authorized and is modifying JES control blocks so I can't see another culprit here. I'm just making sure that the problem is on record so that someone running into this in the future will find that it has happened before.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of McKown, John Sent: Wednesday, September 08, 2010 11:55 AM To: [email protected] Subject: Re: S737 Abends, Deleted GDG Data Sets and TWS > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Tabor, Rich > Sent: Wednesday, September 08, 2010 1:38 PM > To: [email protected] > Subject: S737 Abends, Deleted GDG Data Sets and TWS > > 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. Is that really TWS's fault? I don't know TWS's internals. But I would guess that the restart is like CA-11s. That is, when you restart a failed job, CA-11 (and TWS?) replaces the relative GDG number with an absolute GDG number. When this is done, then the GDG base is not enqueued by the initiator. Try it yourself. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
