Re: PDS/E and LNKLST concat
In [EMAIL PROTECTED], on 09/19/2008 at 02:58 PM, Patrick O'Keefe [EMAIL PROTECTED] said: I'm missing the distinction you are trying to oint out, An overlay structure is a single load module; when you load a segment you are doing an I/O to the same member as when the module was initially loaded. If the library is compressed between those I/O's the results are different from the results of calling a different load module, and generally more interesting. -- 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: PDS/E and LNKLST concat
Patrick O'Keefe wrote: I'm missing the distinction you are trying to oint out, but I sure The OP used comprised of as though it meant consisted of but the meaning is closer to contained in. Proper usage for consists of is comprises. Gerhard Postpischil Bradford, VT -- 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: PDS/E and LNKLST concat
On Thu, 18 Sep 2008 10:25:58 -0500, Tom Marchant m42tom- [EMAIL PROTECTED] wrote: You're right, he didn't say where the apply job was run. Perhaps I misunderstood. Maybe so, but it's still a *really bad* idea to apply maintenance to a running system. I vaguely remember when IEBCOPY was comprised of more than one load module, and compressing the live LINKLIB was not a good thing... somehow, this smells hauntingly familiar... Art Gutowski Ford Motor Company ITI -- 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: PDS/E and LNKLST concat
Arthur Gutowski wrote: I vaguely remember when IEBCOPY was comprised of more than one load module, and compressing the live LINKLIB was not a good thing... somehow, this smells hauntingly familiar... While it is of course possible that some installations linked IEBCOPY with their own programs, thus producing multiple load modules that included IEBCOPY, I think you meant to say that IEBCOPY comprised more than one load module, which is wrong, unless you count the appendage. The problem you remember was due to a number of utilities shipped to execute in a small (64K or so) region (MVT) or partition (MFT), using overlay. However, on a LINKLIB compress, the symptoms would have been the same. Gerhard Postpischil Bradford, VT -- 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: PDS/E and LNKLST concat
On Fri, 19 Sep 2008 12:35:35 -0500, Arthur Gutowski [EMAIL PROTECTED] wrote: On Thu, 18 Sep 2008 10:25:58 -0500, Tom Marchant m42tom- [EMAIL PROTECTED] wrote: You're right, he didn't say where the apply job was run. Perhaps I misunderstood. Maybe so, but it's still a *really bad* idea to apply maintenance to a running system. Yes. I think everyone agrees. But never say never... It may be a bad idea to apply maintenance to a running system, but it's even a worse idea to IPL a production system and have an outage when it can be avoided. Why do you think so many changes can be made dynamically on z/OS (more and more all the time). Do you think IBM would have spent all the time an effort to get something like dynamic activation of service in z/OS UNIX (F OMVS,ACTIVATE=SERVICE) if everyone could always afford an IPL to get a fix in? Rolling IPLs may not work. Even in the most sysplex enabled shops I've been at there are always some applications that live on particular LPARs and need an outage to move or maybe can't even be moved. Do you really want to IPL for an annoying ISPF bug that only affects TSO/ISPF users? Or maybe just an LLA UPDATE or dynamic LPA load and avoid the outage and make a bunch of people happy. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ 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: PDS/E and LNKLST concat
On Fri, 19 Sep 2008 14:25:45 -0400, Gerhard Postpischil [EMAIL PROTECTED] wrote: Arthur Gutowski wrote: Arthur Gutowski wrote: I vaguely remember when IEBCOPY was comprised of more than one load module, and compressing the live LINKLIB was not a good thing... somehow, this smells hauntingly familiar... ... I think you meant to say that IEBCOPY comprised more than one load module, which is wrong, unless you count the appendage. The problem you remember was due to a number of utilities shipped to execute in a small (64K or so) region (MVT) or partition (MFT), using overlay. ... I'm missing the distinction you are trying to oint out, but I sure remember the problem, and it existed in either VS1 or MVS into the mid '80s. We had a helpfull operator that decided to compress SYS1.LINKLIB. The compress worked fine until it got to one of the IEBCOPY overlay modules (I assume). IEBCOPY crashed. We probably had a hard wait at that point, but I don't remember for sure. I'm pretty sure the SYS1.LINKLIB directory was clobbered. Pat O'Keefe we had an unusable SYS1.LINKLIB at that point. -- 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: PDS/E and LNKLST concat
The ptf's that were being applied were going to update a PDSE dataset in the LNKLST. It's rarely safe to apply maintenance to a live system. So I cancelled the job - created an alternate RES pack and applied the maintenance to the alternate RES. Better (safer) choice (IMO). Are the new SMSPDSE and SMSPDSE1 address spaces preventing this type of update or is there a command to allow this type of update to occur. These address spaces sometimes 'trip' over contention issues, rarely is there a problem. But, I think you were fortunate. It made you convert to, what I think, is a better practice. But, it's not my shop. - Too busy driving to stop for gas! -- 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: PDS/E and LNKLST concat
It was a test system and if it crashed the only person it would of affected was me. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Thursday, September 18, 2008 9:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PDS/E and LNKLST concat The ptf's that were being applied were going to update a PDSE dataset in the LNKLST. It's rarely safe to apply maintenance to a live system. So I cancelled the job - created an alternate RES pack and applied the maintenance to the alternate RES. Better (safer) choice (IMO). Are the new SMSPDSE and SMSPDSE1 address spaces preventing this type of update or is there a command to allow this type of update to occur. These address spaces sometimes 'trip' over contention issues, rarely is there a problem. But, I think you were fortunate. It made you convert to, what I think, is a better practice. But, it's not my shop. - Too busy driving to stop for gas! -- 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: PDS/E and LNKLST concat
It was a test system and if it crashed the only person it would of affected was me. Then what other system was in contentioin for the library? - Too busy driving to stop for gas! -- 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: PDS/E and LNKLST concat
On Thu, 18 Sep 2008 09:17:06 -0500, Mark Steely [EMAIL PROTECTED] wrote: We are z/OS V1R9. I was applying some maintenance to our test system which was live. The fist set of PTF's applied successfully. During the apply of the second set of PTF's the job went into a detected wait state. During the detected wait several messages stating a problem with PDSE were occurring. IGW038A Possible PDSE Problem(s) (SMSPDSE1) Recommend issuing V SMS,PDSE1,ANALYSIS The command produced the following output: IGW031I PDSE ANALYSIS Start of Report(SMSPDSE1) 293 ++ Unable to latch ASRBULCH:7F5D2180 Latch:7F5D2198 Holder(0019:00AFF5E8) Holding Started Task:LLA ++ no exceptional data set conditions detected PDSE ANALYSIS End of Report(SMSPDSE1) The ptf's that were being applied were going to update a PDSE dataset in the LNKLST. So I cancelled the job - created an alternate RES pack and applied the maintenance to the alternate RES. Are the new SMSPDSE and SMSPDSE1 address spaces preventing this type of update or is there a command to allow this type of update to occur. Any help would be appreciated. Test or sandbox? If it is a sandbox and you really don't care if you accidentally break something, then I guess it's ok to apply the maintenance to a live system. Maybe it has something to do with the library taking an extent? Even though PDSE can reuse space, this won't happen for an open data set in the LNKLST. Just a swag, this could be WAD or a bug... it's not like there have never been any bugs with PDSE or LLA. :-) If this was some sort of emergency and you needed to do this to a production system without taking an outage, I would first remove the library from LLA control (with F LLA,UPDATE=xx to bring the other thread into this) and then try again. Then add the library back to LLA control. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ 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: PDS/E and LNKLST concat
On Thu, 18 Sep 2008 09:17:06 -0500, Mark Steely wrote: We are z/OS V1R9. I was applying some maintenance to our test system which was live. You shouldn't do that. The fist set of PTF's applied successfully. During the apply of the second set of PTF's the job went into a detected wait state. During the detected wait several messages stating a problem with PDSE were occurring. ... The ptf's that were being applied were going to update a PDSE dataset in the LNKLST. You didn't say whether the two systems are in the same sysplex. If not, you *really* shouldn't do that. -- Tom Marchant -- 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: PDS/E and LNKLST concat
This system is standalone - not sysplex at all. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Thursday, September 18, 2008 9:41 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PDS/E and LNKLST concat On Thu, 18 Sep 2008 09:17:06 -0500, Mark Steely wrote: We are z/OS V1R9. I was applying some maintenance to our test system which was live. You shouldn't do that. The fist set of PTF's applied successfully. During the apply of the second set of PTF's the job went into a detected wait state. During the detected wait several messages stating a problem with PDSE were occurring. ... The ptf's that were being applied were going to update a PDSE dataset in the LNKLST. You didn't say whether the two systems are in the same sysplex. If not, you *really* shouldn't do that. -- Tom Marchant -- 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: PDS/E and LNKLST concat
On Thu, 18 Sep 2008 09:46:55 -0500, Mark Steely wrote: This system is standalone - not sysplex at all. Search the archives. You should never share a PDSE outside of a sysplex. -- Tom Marchant -- 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: PDS/E and LNKLST concat
On Thu, 18 Sep 2008 09:40:40 -0500, Tom Marchant [EMAIL PROTECTED] wrote: You didn't say whether the two systems are in the same sysplex. If not, you *really* shouldn't do that. 2nd reference I saw to 2 systems in replies to the OP. I see mention of 2 set of APPLYs, but not 2 systems. Or did I read the OP wrong? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ 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: PDS/E and LNKLST concat
On Thu, 18 Sep 2008 09:59:07 -0500, Tom Marchant [EMAIL PROTECTED] wrote: On Thu, 18 Sep 2008 09:46:55 -0500, Mark Steely wrote: This system is standalone - not sysplex at all. Search the archives. You should never share a PDSE outside of a sysplex. Also not clear from the OP. To me it sounded like the apply job was running on the system that the OP had the latch issue with. So there may have not been any sharing of that PDSE outside the sysplex. If the apply was from a different system, then yes... all bets are off. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ 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: PDS/E and LNKLST concat
I don't see where he is sharing anything? As I see it there is only one system involved. Yes, applying maintenance to a running system can be hazardous, but if it isn't sharing and he doesn't care... Tom Marchant [EMAIL PROTECTED] 9/18/2008 10:59 AM On Thu, 18 Sep 2008 09:46:55 -0500, Mark Steely wrote: This system is standalone - not sysplex at all. Search the archives. You should never share a PDSE outside of a sysplex. -- Tom Marchant -- 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 Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: PDS/E and LNKLST concat
On Thu, 18 Sep 2008 10:07:42 -0500, Mark Zelden wrote: On Thu, 18 Sep 2008 09:40:40 -0500, Tom Marchant wrote: You didn't say whether the two systems are in the same sysplex. If not, you *really* shouldn't do that. 2nd reference I saw to 2 systems in replies to the OP. I see mention of 2 set of APPLYs, but not 2 systems. Or did I read the OP wrong? You're right, he didn't say where the apply job was run. Perhaps I misunderstood. -- Tom Marchant -- 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: PDS/E and LNKLST concat
But what about corruption that occurs but does not show up until you go to production? I'd suggest that you were darned lucky that the issue made itself it known so early in the game. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Steely Sent: Thursday, September 18, 2008 9:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PDS/E and LNKLST concat It was a test system and if it crashed the only person it would of affected was me. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Thursday, September 18, 2008 9:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PDS/E and LNKLST concat The ptf's that were being applied were going to update a PDSE dataset in the LNKLST. It's rarely safe to apply maintenance to a live system. So I cancelled the job - created an alternate RES pack and applied the maintenance to the alternate RES. Better (safer) choice (IMO). Are the new SMSPDSE and SMSPDSE1 address spaces preventing this type of update or is there a command to allow this type of update to occur. These address spaces sometimes 'trip' over contention issues, rarely is there a problem. But, I think you were fortunate. It made you convert to, what I think, is a better practice. But, it's not my shop. - Too busy driving to stop for gas! -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
