On Thu, 19 May 2011 10:00:36 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote:
>On Thu, 19 May 2011 08:56:49 -0500, Tim Deller wrote: > >>I would try coding a wait (for a few seconds at least) after the dataset close. >>This would allow time for the deallocate and catalog update to complete. >> >Grrr. I detest designs that require the programmer to use delays >to (hopefully) resolve race conditions. > Thanks everyone for the ideas so far. It happened again yesterday and now I'm leaning more towards this being caused by the dataset being in use by another job. The long story: This in-house written program had been working just fine for over 10 years. Late last year we upgraded from z/OS 1.4 to 1.11. The first thing we noticed was 314-40 (I think) abends when these volumes were getting defragged. It seemed to be caused by this program was issuing the SVC99 with 'DATA.SET.NAME(0)' as the dataset name. We could see that it was not enqueueing on the Goovoo, just the name of the base. According to the FM, if you want to allocate via relative generation you need to specify the generation in the DALMEMBR text unit, so I changed the program to do that. So far so good, but now it appeared that if a new generation was created, this STC would continue to allocate the previous one. Had to turn on S99GDGNT to force a LOCATE each time. That corrected that problem now it's experiencing the problem in the original post in this thread. What I'm thinking now is that daily when a new generation of this GDG is created via a batch job, this STC cannot allocate it successfully. The logic in the program is to wait 30 seconds and try again if it gets returned dataset in use, but from the timings of the job and messages, it doesn't appear that it's ever going through that 30 second loop. What we see is that it is setting on enqueues for all of the generations of the GDG. Dana ---------------------------------------------------------------------- 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
