I think there are actually a couple of solutions here. 1) Do not put user proclibs in JES2. Use the JCLLIB statement instead. 2) If you do put a user proclib in JES2 then make it with only primary allocation and no seconday. Allow for growth. If it fills up then use the JCLLIB statement 3) If you do need to compress a proclib in JES2 be aware during the compress process you can get I/O errors while the JCL is trying to convert. Just resubmit the job.
To compress: Use DISP=SHR in the COMPRESS JCL (usually IEBCOPY). Next have a second batch job ready to go to access a proc in a different PROCxxx statement. It is okay to use a dummy. This process causes JES2 to close and reopen PROC00. JES2 remembers the members TTR pointers and keeps them in storage, so it does not need to read the proclibs everytime to find out where they are. The use of the other PROCxxx entry is to force JES2 to relearn the TTR pointers. Be prepared to have jobs resubmitted should they get I/O errors during conversion. My preference is to always use a JCLLIB for everything except SYSTEM Proclibs. And to always allocate my system proclibs with only primary and very big. If you do have proclibs that have secondary extents, always scheule a compress job weekly when batch can be quiesced. Lizette ---------------------------------------------------------------------- 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
