Re: ISPF FREED SYS1.PARMLIB
Steve, I believe that IPLPARM is separate for a reason. Lets get back to what you are using SETLOAD for. That is to fix a PARMLIB issue. You do not need a fully specified LOADxx member to do this. All you need is the necessary PARMLIB statements to fix your problem. As such, I would have no problem keeping a LOADFX (LOADfix) member in PARMLIB, maybe even temporarily, just to address this issue. After all, in reality, most of us don't use SETLOAD bey much as it is. Dave Dave Jousma Mainframe Services [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Horein Sent: Saturday, September 01, 2007 11:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ISPF FREED SYS1.PARMLIB Thanks to everyone that contributed! As suggested, SETLOAD was the way to go for me. I once again have a properly sized SYS1.PARMLIB. However, while reviewing SETLOAD documentation, questions spring to mind: Do you folks concatenate your SYSx.IPLPARM (if you use it) to PARMLIB in LOADxx? I was also curious if IEFPRMLB could be made to include by default the PDS where LOADxx was found at IPL time, much like it includes by default SYS1.PARMLIB. I've recently taken to using LOADxx found in SYSx.IPLPARM on the IODF volume instead of finding LOADxx in SYS1.PARMLIB. When I first issued my SETLOAD command, it failed because I didn't specify DSN=SYSx.IPLPARM as I should have, because at this time, I don't concatenate SYSx.IPLPARM. I know, how I concatenate PARMLIB is my choice, but I'd hate to be viewed as 'out there' if this isn't considered standard practice! ;) I don't know if I'm OCD, but I like having any/all of my LOADxxs found in one place. I happen to choose SYSx.PARMLIB for that. I've also considered creating a SYS1.LLA.PARMLIB (and system specific SYS1.LLA.PARMLIBs) to contain CSVLLAxx members, excluding CSVLLA00. I guess there's a line to draw between being organized and easily maintainable. Thanks again for being the group that you are! This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: ISPF FREED SYS1.PARMLIB
In [EMAIL PROTECTED], on 09/01/2007 at 10:23 AM, Steve Horein [EMAIL PROTECTED] said: I was also curious if IEFPRMLB could be made to include by default the PDS where LOADxx was found at IPL time, much like it includes by default SYS1.PARMLIB. Easily; they could just as easily back out the change once the complaints started. This is a case of If it's not broke, don't fix it. The whole point of having an IPLPARM library is to separate out the LOADxx members. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: ISPF FREED SYS1.PARMLIB
We've never entertained the idea of concatenating the IPLPARM library along with other PARMLIBs. The name says it all. It is used only at IPL time at the earliest possible stage of initialization, so early that it does not even need to cataloged because LOADxx actually tells the OS where to find the master catalog. IPLPARM can also contain NUCLSTxx, used only to build the nucleus. None of the 'normal' members of IPLPARM are needed once IPL takes off. Hence concatenating it with, say SYS1.PARMLIB, while not harmful, satisfies no useful purpose. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Steve Horein [EMAIL PROTECTED] COURT.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: ISPF FREED SYS1.PARMLIB 09/01/2007 08:23 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Thanks to everyone that contributed! As suggested, SETLOAD was the way to go for me. I once again have a properly sized SYS1.PARMLIB. However, while reviewing SETLOAD documentation, questions spring to mind: Do you folks concatenate your SYSx.IPLPARM (if you use it) to PARMLIB in LOADxx? I was also curious if IEFPRMLB could be made to include by default the PDS where LOADxx was found at IPL time, much like it includes by default SYS1.PARMLIB. I've recently taken to using LOADxx found in SYSx.IPLPARM on the IODF volume instead of finding LOADxx in SYS1.PARMLIB. When I first issued my SETLOAD command, it failed because I didn't specify DSN=SYSx.IPLPARM as I should have, because at this time, I don't concatenate SYSx.IPLPARM. I know, how I concatenate PARMLIB is my choice, but I'd hate to be viewed as 'out there' if this isn't considered standard practice! ;) I don't know if I'm OCD, but I like having any/all of my LOADxxs found in one place. I happen to choose SYSx.PARMLIB for that. I've also considered creating a SYS1.LLA.PARMLIB (and system specific SYS1.LLA.PARMLIBs) to contain CSVLLAxx members, excluding CSVLLA00. I guess there's a line to draw between being organized and easily maintainable. Thanks again for being the group that you are! -- 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: ISPF FREED SYS1.PARMLIB
Thanks to everyone that contributed! As suggested, SETLOAD was the way to go for me. I once again have a properly sized SYS1.PARMLIB. However, while reviewing SETLOAD documentation, questions spring to mind: Do you folks concatenate your SYSx.IPLPARM (if you use it) to PARMLIB in LOADxx? I was also curious if IEFPRMLB could be made to include by default the PDS where LOADxx was found at IPL time, much like it includes by default SYS1.PARMLIB. I've recently taken to using LOADxx found in SYSx.IPLPARM on the IODF volume instead of finding LOADxx in SYS1.PARMLIB. When I first issued my SETLOAD command, it failed because I didn't specify DSN=SYSx.IPLPARM as I should have, because at this time, I don't concatenate SYSx.IPLPARM. I know, how I concatenate PARMLIB is my choice, but I'd hate to be viewed as 'out there' if this isn't considered standard practice! ;) I don't know if I'm OCD, but I like having any/all of my LOADxxs found in one place. I happen to choose SYSx.PARMLIB for that. I've also considered creating a SYS1.LLA.PARMLIB (and system specific SYS1.LLA.PARMLIBs) to contain CSVLLAxx members, excluding CSVLLA00. I guess there's a line to draw between being organized and easily maintainable. Thanks again for being the group that you are! On Thu, 30 Aug 2007 17:57:48 -0500, Steve Horein [EMAIL PROTECTED] wrote: Hi all, Ugh - Long days short nights has taken it's toll on me. Instead of viewing our shared SYS1.PARMLIB with 'V' in ISPF, I instead freed it with 'F'. Yeah I know, F V are not even on the same row on the keyboard. Now SYS1.PARMLIB is 100% used. I've allocated 'SYS1.PARMLIB.SIZE' with the original primary, 0 secondary. Would it be safe to: 1) IEBCOPY the freed SYS1.PARMLIB into the SYS1.PARMLIB.SIZE, 2) rename the freed SYS1.PARMLIB to SYS1.PARMLIB.DONT.DELETE, 3) finally rename SYS1.PARMLIB.SIZE to SYS1.PARMLIB? Searching the archives makes me think I'd be fine, what with all of the topics relating to compressing PARMLIB, but I'd rather ask outright about the whole rename/swap idea. I have system specific PARMLIBs concatenated before SYS1.PARMLIB, so any required changes could be made there if D37 issues arise before the next IPL. Thanks, and any suggestions would be helpful! -- 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: ISPF FREED SYS1.PARMLIB
On Sep 1, 2007, at 10:23 AM, Steve Horein wrote: Thanks to everyone that contributed! -SNIP Steve, Indeed this was an interesting discussion. What got me curious is that quite a few people do not run with SYS1.PARMLIB without an expiration date. I have *ALWAYS* put expdt on all sys1 libraries. I do it for two reasons. 1. Its a double check incase I finger check and save something that was not to be saved. 2. its a double check against the security people to make sure they haven't oops'd a definition. I think if you would have (in this case) did a F to the library it would have asked the operator and you could have called them and said reply M But it also asks the first question I have does every one put expdt on all sys1 libraries (or some) ? Ed -- 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: ISPF FREED SYS1.PARMLIB
Lizette Koehler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I am not sure you have a problem. When you issued the FREE SPACE command against the PARMLIB data set, you only force it to go back to the primary space if it could. For instance, if your SYS1.PARMLIB had CYL 1,1 and had 5 extents, then the free would would have left it CYL 1,1 but maybe now down to 1 extent. It is not an issue unless something is looking for a member at the exact TTR location it was before. I would first issue a D GRS,RES=(*,SYS1.PARMLIB) and see what has it in current allocation (yes there are other methods). Next I would review the allocation (option 3.2 or 3.4) and see what the FREE did. You maybe okay. The free does not reduce your secondary allocations or remove what was there. It is more like a Compress. F - Free unused space- not destroy data set. Lizette Lizette, This is not true. FREE frees all space behind the last used track/cyl and it does not change the allocation amounts. It does not touch the data, either by reorganize or compress. In the case of CYL 1,1 and 5 extents there is nothing to free, because all extents have been taken to write data into. If it was compressed and the last data would be in extent 3, the last 2 cylinders will be freed. If the dataset is CYL 5,5 and has 5 extents, the 5 cylinders in the last extent will probably not used all and the unused cylinders will be freed. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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: ISPF FREED SYS1.PARMLIB
Steve, If you have the freebie PDS tool, you can add space to it on the fly. That is what I would do. Or, you can create a new parmlib, with a new name, do a SETLOAD command to make the system use the new parmlib, then fix the real one, and do another SETLOAD to go back. Dave Dave Jousma Mainframe Services [EMAIL PROTECTED] 616.653.8429 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: ISPF FREED SYS1.PARMLIB
Eric Bielefeld wrote: Does anyone know what release the SETLOAD command came with? I never heard of that command until this discussion. OS/390 V1R2? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: ISPF FREED SYS1.PARMLIB
Does anyone know what release the SETLOAD command came with? I never heard of that command until this discussion. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Jousma, David [EMAIL PROTECTED] Steve, If you have the freebie PDS tool, you can add space to it on the fly.That is what I would do. Or, you can create a new parmlib, with a new name, do a SETLOAD command to make the system use the new parmlib, thenfix the real one, and do another SETLOAD to go back. Dave Dave Jousma Mainframe Services [EMAIL PROTECTED] 616.653.8429 -- 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: ISPF FREED SYS1.PARMLIB
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 08/31/2007 11:06:07 AM: Eric Bielefeld wrote: Does anyone know what release the SETLOAD command came with? I never heard of that command until this discussion. OS/390 V1R2? OS/390 V1R2 (JBB6602) it was. BROWSESYS1.MACLIB(IEFPRMLB) Line 1587 Col Command === Scroll = *01* CHANGE ACTIVITY: * * * * Flag LineItem FMIDDate IDComment * * * *$L0=PARMCAMG JBB6602 950630 PDNN: Concatenated Parmlib Support * *$L1=PARMCJBB6602 950630 PDNN: Concatenated Parmlib Support * *$L2=PARMCJBB6602 950707 PDNN: Concatenated Parmlib Support * *$01=OW25172 JBB6602 970428 PDNN: MOVE FREECLOSE under READ * *$P1=PXD0213 HBB7703 990713 PDXB: More parmlib data sets* Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
ISPF FREED SYS1.PARMLIB
Hi all, Ugh - Long days short nights has taken it's toll on me. Instead of viewing our shared SYS1.PARMLIB with 'V' in ISPF, I instead freed it with 'F'. Yeah I know, F V are not even on the same row on the keyboard. Now SYS1.PARMLIB is 100% used. I've allocated 'SYS1.PARMLIB.SIZE' with the original primary, 0 secondary. Would it be safe to: 1) IEBCOPY the freed SYS1.PARMLIB into the SYS1.PARMLIB.SIZE, 2) rename the freed SYS1.PARMLIB to SYS1.PARMLIB.DONT.DELETE, 3) finally rename SYS1.PARMLIB.SIZE to SYS1.PARMLIB? Searching the archives makes me think I'd be fine, what with all of the topics relating to compressing PARMLIB, but I'd rather ask outright about the whole rename/swap idea. I have system specific PARMLIBs concatenated before SYS1.PARMLIB, so any required changes could be made there if D37 issues arise before the next IPL. Thanks, and any suggestions would be helpful! -- 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: ISPF FREED SYS1.PARMLIB
I am not sure you have a problem. When you issued the FREE SPACE command against the PARMLIB data set, you only force it to go back to the primary space if it could. For instance, if your SYS1.PARMLIB had CYL 1,1 and had 5 extents, then the free would would have left it CYL 1,1 but maybe now down to 1 extent. It is not an issue unless something is looking for a member at the exact TTR location it was before. I would first issue a D GRS,RES=(*,SYS1.PARMLIB) and see what has it in current allocation (yes there are other methods). Next I would review the allocation (option 3.2 or 3.4) and see what the FREE did. You maybe okay. The free does not reduce your secondary allocations or remove what was there. It is more like a Compress. F - Free unused space- not destroy data set. Lizette Hi all, Ugh - Long days short nights has taken it's toll on me. Instead of viewing our shared SYS1.PARMLIB with 'V' in ISPF, I instead freed it with 'F'. Yeah I know, F V are not even on the same row on the keyboard. Now SYS1.PARMLIB is 100% used. I've allocated 'SYS1.PARMLIB.SIZE' with the original primary, 0 secondary. Would it be safe to: 1) IEBCOPY the freed SYS1.PARMLIB into the SYS1.PARMLIB.SIZE, 2) rename the freed SYS1.PARMLIB to SYS1.PARMLIB.DONT.DELETE, 3) finally rename SYS1.PARMLIB.SIZE to SYS1.PARMLIB? Searching the archives makes me think I'd be fine, what with all of the topics relating to compressing PARMLIB, but I'd rather ask outright about the whole rename/swap idea. I have system specific PARMLIBs concatenated before SYS1.PARMLIB, so any required changes could be made there if D37 issues arise before the next IPL. -- 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: ISPF FREED SYS1.PARMLIB
On Thu, 30 Aug 2007 17:57:48 -0500, Steve Horein wrote: Hi all, Ugh - Long days short nights has taken it's toll on me. Instead of viewing our shared SYS1.PARMLIB with 'V' in ISPF, I instead freed it with 'F'. Yeah I know, F V are not even on the same row on the keyboard. Now I understand that a batch job can override SPACE on an existing data set for the duration of that job. So, what if you run a job declaring a suitably large secondary extent and copy a small dummy member into the library? (One of us will learn something.) 2) rename the freed SYS1.PARMLIB to SYS1.PARMLIB.DONT.DELETE, Actually, you can't delete it until you get exclusive access, and once you have exclusive access it's probably OK to delete. -- 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
Re: ISPF FREED SYS1.PARMLIB
On Thu, 30 Aug 2007 17:57:48 -0500, Steve Horein wrote: Hi all, Ugh - Long days short nights has taken it's toll on me. Instead of viewing our shared SYS1.PARMLIB with 'V' in ISPF, I instead freed it with 'F'. Yeah I know, F V are not even on the same row on the keyboard. Now SYS1.PARMLIB is 100% used. I've allocated 'SYS1.PARMLIB.SIZE' with the original primary, 0 secondary. Would it be safe to: 1) IEBCOPY the freed SYS1.PARMLIB into the SYS1.PARMLIB.SIZE, 2) rename the freed SYS1.PARMLIB to SYS1.PARMLIB.DONT.DELETE, 3) finally rename SYS1.PARMLIB.SIZE to SYS1.PARMLIB? Searching the archives makes me think I'd be fine, what with all of the topics relating to compressing PARMLIB, but I'd rather ask outright about the whole rename/swap idea. I have system specific PARMLIBs concatenated before SYS1.PARMLIB, so any required changes could be made there if D37 issues arise before the next IPL. Thanks, and any suggestions would be helpful! Before you lose sleep over this, you might want to investigate the SETLOAD command to establish a (new) PARMLIB concatenation (with slightly different dataset names, then switch back when you have things pieced back together). Before you do that, however, you might want to be sure of your RACF (et al) situation - security folks tend to get huffy when PARMLIB shifts around on them. (Mostly they get that way when they know that auditors will be getting extra-huffy with the security folks for letting the sysprogs get too slippery.) -- Tom Schmidt Madison, WI -- 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
