On Fri, 28 Mar 2008 12:03:54 -0500, Mark Zelden wrote: > >>In an earlier contribution, you mentioned that JES holds no ENQ >>on the PROCLIBs. That sounds terribly dangerous. Why would they >>design it that way? >> > >How would you ever re-allocate a proclib if it was ENQed? At least >before TSO. Shutdown JES2, then run a batch job to do the rename. >Wait... you can't run a batch job, JES2 is down! > To my meager understanding, if JES2 is down you're SOL, whether or not it ENQs (but is there a special case in which JES2 might crash but fail to free the ENQS?) By my ancient experience, if JES2 is down, TSO is likewise SOL (or was it Roscoe, then?)
If JES2 is up, then: o Submit a job with: - STEP1 IDCAMS ALTER NAME - STEP2 IEFBR14 with DISP=OLD on the PROCLIB catenands. o The job waits on PROCLIB ENQ o Stop JES2 o Start JES2 o JES2 waits on PROCLIB ENQ o The RENAME job completes freeing the ENQs o JES2 allocates PROCLIB and continues. Hmmm. This requires JES2 stopped and started on all systems in the GRSplex. But the timing isn't entirely critical; ENQ helps. It would help if there were a JES2 command to close, free, allocate, and open PROCLIB; even better if it did some thorough verification of PROCLIB validity and required operator confirmation before proceeding if it detected any anomaly ( CANCEL | RETRY | CONTINUE :-) -- gil ---------------------------------------------------------------------- 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
