On Fri, 2 Jul 2010 13:26:41 +0200, Thomas Berg wrote: >> > >> >How ? The "shut the door" job is *waiting* for EXCL ENQ (OLD). >> > >> As I read it, "shut the door" never completes its wait. So >> you don't know how many other jobs may have previously >> allocated the data set SHR, opened it, done BLDLs, and not >> yet closed it. They are holding TTRs which will point to >> unpredictable content once you compress (w DISP=SHR). > >(The "STD" job is cancelled by the compress job when it's finished.) >Yes, a couple of other jobs has opened the pds and if they haven't >finished their update it may theoretically cause local corruption >in the pds. But I have never experienced that, maybe because of the >30 seconds wait I do before beginning the compress. > I was concerned less with directory corruption than with the harmful effect on other DISP=SHR jobs already running.
>And of course, this is in a test environment. > Ah! So you don't care if a few jobs fail. I, also, often operate in that mode. >BTW, the "STD" is not a problem in this case, the only potential >problem is the compress (job). >And if You are worried You can always wait until all jobs that may >have opened the pds are finished before You start the compress. Then >there is no problem anymore regarding the risk ds corruption. > IOW, simply submit a compress job with DISP=OLD. I sometimes do that, too. Then the operators telephone me to complain about the flood of MIM ENQ messages on the console, and to relay complaints from other testers attempting to allocate the data set. -- gil ---------------------------------------------------------------------- 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
