RES: compress a proclib
I've always compressed a PROCLIB with IEBCOPY (DISP=SHR) and never had a problem. But there is another possible solution : 1) Remove PROC00 from JES2 PROC and substitue it by PROCLIB statment in JES2PARM like sample below PROCLIB(PROC00) DD(001)=(DSNAME=SYS1.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(002)=(DSNAME=SYS2.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(003)=(DSNAME=SYS3.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(004)=(DSNAME=SYS4.PROCLIB ),UNCONDITIONAL 2) Let's assume SYS3.PROCLIB gets full. Create another proclib (SYSX.PROCLIB) and copy SYS3.PROCLIB into it. 3) Substitute SYS3.PROCLIB by SYSX.PROCLIB issueing the command $TPROCLIB(PROC00),DD(003)=(DSNAME=SYSX.PROCLIB). 4) Realloc a new SYS3.PROCLIB (or use PDS86 to enlarge it) and copy SYSX.PROCLIB back. 5) Substitute SYSX.PROCLIB by SYS3.PROCLIB (same command above) Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD Alphaville Suporte Técnico - Software Básico Mainframes Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 AVISO LEGAL BR Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. +**+ LEGAL ADVICE BR This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- 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
Re: compress a proclib
Thanks for your comments. I compressed the proclib in place at a very low activity time on the system. -- 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
Re: compress a proclib
Bruce, That's how I remember it also. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Hewson Sent: Thursday, 3 August 2006 1:18 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: compress a proclib Actually, because JES2 normally does not have a ENQueue on its PROCLIBS, you should be able to compress it with DISP=OLD. That will stop any I/O errors for JCLLIBs. Regards Bruce Hewson -- 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
Re: RES: compress a proclib
On Thu, 3 Aug 2006 09:00:56 -0300, Ituriel do Nascimento Neto [EMAIL PROTECTED] wrote: I've always compressed a PROCLIB with IEBCOPY (DISP=SHR) and never had a problem. But there is another possible solution : 1) Remove PROC00 from JES2 PROC and substitue it by PROCLIB statment in JES2PARM like sample below PROCLIB(PROC00) DD(001)=(DSNAME=SYS1.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(002)=(DSNAME=SYS2.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(003)=(DSNAME=SYS3.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(004)=(DSNAME=SYS4.PROCLIB ),UNCONDITIONAL 2) Let's assume SYS3.PROCLIB gets full. Create another proclib (SYSX.PROCLIB) and copy SYS3.PROCLIB into it. 3) Substitute SYS3.PROCLIB by SYSX.PROCLIB issueing the command $TPROCLIB(PROC00),DD(003)=(DSNAME=SYSX.PROCLIB). 4) Realloc a new SYS3.PROCLIB (or use PDS86 to enlarge it) and copy SYSX.PROCLIB back. 5) Substitute SYSX.PROCLIB by SYS3.PROCLIB (same command above) Looks a bit like swapping out a LNKLST lib... but it doesn't have to be that complicated! With dynamic proclibs you can compress them (DISP=SHR or OLD is better since that will stop JCLLIB access) and then just issue $TPROCLIB(*) or RO *ALL,$TPROCLIB(*) if other systems in the sysplex share the same proclib. We do have to compress PROCLIBs occasionally. The above procedure is what I have been using since dynamic proclib support and have never run into a problem. I have also used it to fix the compress problem when I get calls from another support group that has compressed their proclib and starts seeing strange results. BTW, all our production PROCLIBs were swapped out to PDSE long before dynamic proclib support to avoid these compress issues. These PROCLIBs were constantly updated and needed to be compressed on a regular basis. One other note... if you compress a PROCLIB allocated to *MASTER* (MSTJCLxx) and a proc is started with SUB=MSTR, you're SOL until you IPL if you run into strange results. There is no refresh trick. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: compress a proclib
On Wed, 2 Aug 2006 15:25:15 -0500, Peter Ten Eyck [EMAIL PROTECTED] wrote: I have read various posting about the problems of compressing a PDS proclib. Then I'm wondering why you didn't find what you needed in the archives. I have a proclib call TEST.PROCLIB which out of space. snip TEST.PROCLIB is known to JES2 through the following PROC (JES2 on z/OS 1.4). //JES2 PROC MEMBER=JES2PARM,ALTMEM=JES2PARM, // PLIB2='SYS2.PROCLIB',PLIB3='TEST.PROCLIB' //IEFPROC EXEC PGM=HASJES20,DPRTY=(15,15),TIME=1440,PERFORM=9 //ALTPARM DD DISP=SHR,DSN=SYS1.PARMLIB(ALTMEM) //HASPPARM DD DISP=SHR,DSN=SYS1.PARMLIB(MEMBER) //PROC00 DD DISP=SHR,DSN=SYS1.PROCLIB // DD DSN=PLIB2,DISP=SHR // DD DSN=PLIB3,DISP=SHR // DD DISP=SHR,DSN=CPAC.PROCLIB // DD DISP=SHR,DSN=IPO1.PROCLIB // DD DISP=SHR,DSN=SYS1.IBM.PROCLIB // DD DISP=SHR,DSN=IOE.SIOEPROC //HASPLIST DD DDNAME=IEFRDER How do I resolve this problem if it is not safe to compress? Search the archives for Curious Proclib Problem. $PJES2,ABEND and hot start (restart) is a 100% cure. Otherwise, this is from a post of mine that was in the thread I just mentioned: Another problem is that each converter subtask has its own DCB for the problib concatenation. The number of subtasks is defined by CNVTNUM in PCEDEF. There is a trick to try and close and re-open the concatenation, but the more subtasks you have, the harder it is to force them all to be closed and re-opened. You have to flood the system with enough trick jobs to force all the tasks to be busy. The trick job is to use a /*JOBPARM P=? pointing to a name that is not the PROCLIB concatenation thathas been changed. You can even make up a name - /*JOBPARM P=PROC999. You need to submit as many of these at once as you can (put multiple jobs in a data set and submit the data set). Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: compress a proclib
OK, maybe I'm living a charmed life. But if I need to compress a PROCLIB, I just run IEBCOPY with a DISP=SHR on it. I've never had a problem. The only problem that I can think of that might occur is if a job went to the converter and tried to use the PROCLIB during the actual compress process. That job will get a JCL error. And you may get a nasty message about the converter subtask abending. But JES2 stays up. What am I doing right? Oh, if I need to reallocate a PROCLIB, then I do the $PJES2,ABEND trick. But only late at night and with everybody understand that there will be a short outage for JES2. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: compress a proclib
On Wed, 2 Aug 2006 15:49:24 -0500, McKown, John [EMAIL PROTECTED] wrote: OK, maybe I'm living a charmed life. But if I need to compress a PROCLIB, I just run IEBCOPY with a DISP=SHR on it. I've never had a problem. On Wed, 2 Aug 2006 15:46:36 -0500, Eric N. Bielefeld [EMAIL PROTECTED] wrote: I have never had a problem compressing a proclib on the fly. See the first post in the thread I metioned - Curious Proclib Problem. Post was on Wed, Feb 28 2001. I could quote it again here, but what fun would that be. The archives are a beautiful thing. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: compress a proclib
On Wed, 2 Aug 2006 15:55:19 -0500, Mark Zelden [EMAIL PROTECTED] wrote: On Wed, 2 Aug 2006 15:49:24 -0500, McKown, John [EMAIL PROTECTED] wrote: OK, maybe I'm living a charmed life. But if I need to compress a PROCLIB, I just run IEBCOPY with a DISP=SHR on it. I've never had a problem. On Wed, 2 Aug 2006 15:46:36 -0500, Eric N. Bielefeld [EMAIL PROTECTED] wrote: I have never had a problem compressing a proclib on the fly. See the first post in the thread I metioned - Curious Proclib Problem. Post was on Wed, Feb 28 2001. I could quote it again here, but what fun would that be. The archives are a beautiful thing. :-) Well.. I just re-read some of that thread and the problem was actually caused by allocating a new proclib / renaming a proclib. However, you can see the same symptoms after a compress. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: compress a proclib
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
Re: compress a proclib
Actually, because JES2 normally does not have a ENQueue on its PROCLIBS, you should be able to compress it with DISP=OLD. That will stop any I/O errors for JCLLIBs. Regards Bruce Hewson -- 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
