My point is why CATALOG address space is not considering the new volume RBI035 why is it that still expecting RBI031 even though I have recreated the SCLM1.PROCLIB with catalog option and it got created in RBI035. If I see the LISTC for SCLM1.PROCLIB it shows the volume as RBI035
Error as : IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB Why the catalog is still expecting the dataset from RBI031 itself ? JAcky On 3/28/08, Lizette Koehler <[EMAIL PROTECTED]> wrote: > > Jacky, > > You cannot move a JES2 JCL defined PROCLIB while JES2 is up. If it is in > an > SMS Managed pool, you probably need to look at coding PROCLIB statements > in > JES2 rather than the JCL. > > Mark makes a valid point. > When JES2 had JCL coded PROCLIBs they are not ENQUEUED so if your security > product does not have the general access of READ and only a few groups > that > have ALTER, you can have these types of issues. > > I would recommend that your security product specify a UACC of READ (if > you > are a RACF Shop) and only the group responsible to support JES2 have > ALTER. > > > When a JES2 JCL defined proclib is delete JES2 does not care. Once JES2 > has > opened the PROCLIB data set it builds a TTR list and uses that rather than > going back to the dataset. It just reads the TTR pointers it built for > that > data sets. I do not have the in depth details on how that works, but if > you > are interested, I am sure there are several on this list (like Mark Z) > who > can provide that. > > Once the TTRs are built, if the data set is deleted, JES2 just goes on > using > those TTRs to access the procs. Should you compress JES2 JCL defined > proclib you can run into similar issues, though I think you the a HASP > message that states an I/O error has occurred. > > My preference has always been for the use of JCLLIB statements in > Application JCL, and PROCLIB statements to reduce these types of errors in > JES2. > > Should the recommended actions not correct the problem, you will most > likely > need to bounce JES2 so it can find the new home of the proclib data set > and > rebuild its TTRs. If you do need to abend JES2 you do not need to stop > work. However, I think things that use the SAPI interface may abend with > JES2. This is like VPS or similar products. IIRC, I have abended JES2 > and > not really seen any issues with currently running work. > > Lizette > > > >Hi, > > > >In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in > >sequence resp. Later due to some reason RBI1.PROCLIB was deleted and > >recreated. > > > >But after that we are facing problem that PROCs from the RBI1.PROCLIB are > >not getting invoked. > > > >What could be the problem ? > > > > That RBI1.PROCLIB was deleted! ;-) > > Even though the library is not ENQed by JES2 (due to the NODSI entry in > the PPT) the library is still in use. If the proclib is defined in the > JES2 > JCL > you'll have to $PJES2,ABEND and restart JES2. If you are using dynamic > proclibs, just issue $TPROCLIB(*) and that should fix it. > > ---------------------------------------------------------------------- > 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
