Re: DLIB volume for SAD
I agree that SAD should be rebuilt after every upgrade. The question is whether to maintain older levels to match every system in the enterprise and associate them without manual intervention. My earlier point was that we are configured to take SAD to the latest SAD version even though it might be a release (or more) higher than the failing system. We run two separate data centers connected via DWDM. I'm not thrilled at the idea of writing a Mod-54's worth of data to a device 100+ kilometers away, especially as re-IPL of a failed system is waiting with drumming fingers for SAD to finish. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs - Listserv Sent: Thursday, September 28, 2017 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD Mr. Murphy taught me a very long time ago that I should always ensure I have a working SADUMP that matches the OS level requiring it. Agree. That's why I always rebuilt it after every zOS maintenance cycle, cause' ya never know. Mark Jacobs > Mark Zelden <mailto:m...@mzelden.com> > September 28, 2017 at 12:27 PM > I didn't respond to the "last time you took an SAD". It has been > probably 1.5 years at least since a prod / dev LPAR crashed and took > an SAD via AUTOIPL, but it does happen every few years it seems. > > The other 2 times were more recent and involved sandbox LPARs. One was > just a week ago when someone had removed a data set from LPA involving > CICS VR because the sandbox LPAR did not run CICS. The LPAR hadn't > been IPLed in over a month and the person who removed it didn't think > that was the reason for the wait state at IPL time. I was able to look > at the SADUMP and figure it out. IBM supplies SYS1.SDWWDLPA with a > dummy CICSVR module that NIP looks for at IPL time and I had to add > that back into LPA. > > Mr. Murphy taught me a very long time ago that I should always ensure > I have a working SADUMP that matches the OS level requiring it. > > Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL > v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: > http://www.mzelden.com/mvsutil.html > <http://www.mzelden.com/mvsutil.html> > Systems Programming expert at > http://search390.techtarget.com/ateExperts/ > <http://search390.techtarget.com/ateExperts/> > > > > > On Thu, 28 Sep 2017 11:16:47 -0500, Mark Zelden wrote: > > >I always put SADUMP for each OS release on the 2nd volume of my > maintenance > >sysres for each OS release (still using 3390-9s). I create an HMC > >profile on each CPC for SADUMP at that time. If I was using a mod-27 > or anything > >large enough where I didn't have a multi-volume sysres set, I would > just put it on > >the dlib volume instead (this is what I did years ago). > > > >Part of my migration / cut over plan for after a "GO" decision when > migrating > >releases is to update the HMC SADUMP profile for that LPAR and to > >verify AUTOIPL SADMP has been updated in DIAGxx to point to that > >proper volume as well (this is staged already in a "migration parmlib" > concatenated ahead > >of the normal parmlib concatenation. So at any given time during OS > upgrade > >migration, some LPARs are pointing to one level of SADUMP and other > >LPARs pointing to another level. It always matches the SADUMP for the > >OS > version. > > > >Regards, > > > >Mark > >-- > >Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL > >v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: > >http://www.mzelden.com/mvsutil.html > <http://www.mzelden.com/mvsutil.html> > >Systems Programming expert at > http://search390.techtarget.com/ateExperts/ > <http://search390.techtarget.com/ateExperts/> > > > > > > > > > > > >== > > > >On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson > wrote: > > > >Invitation for early Friday war stories. > > > >When implementing (OS-moniker-du-jour) 1.6, we had several > catastrophic failures that required back out to previous level. We > took some SADs during that stormy period. > > > >When implementing z/OS 1.13, we had several instances of running > clean out of real storage! System hit a w
Re: DLIB volume for SAD
Your question implies confusion. It is the Stand-Alone Dump program that scans and saves a broken LPAR's memory, which you IPL on top of a broken LPAR. I imagine you can scan a broken LPAR's memory using HMC/SE facilities, but I doubt many people can "PEEK/POKE" a busted-arse LPAR to fix it on the fly successfully. Generally you want the system back up as soon as possible (take SAD and re-boot). The fact that you SAD program has been installed on the volume that contains your DLIB's is irrelevant. There are no DLIB's or programs from DLIB's involved in the process of a stand-alone dump. It is the installation of the SAD program that generates all the necessary components, on whatever tape or DASD volume you specify (excluding any DASD sysres volumes of course, you don't want to overwrite the IPL text stored in cyl 0,0 that brings up your system). Refer to the MVS Diagnosis and Service Aids manual for whichever version of z/OS you are using. Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Sent: Friday, 29 September 2017 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DLIB volume for SAD Is there a scanning mechanism within Distribution library dataset to scan the memory of frozen Lpar ? On 29-Sep-2017 7:11 AM, "Ed Jaffe" wrote: > On 9/27/2017 2:16 PM, Steely.Mark wrote: > >> A little off topic - when is the last time anyone had to perform a >> SAD ? I haven’t done one in 20+ years. >> > > We take a SAD every time any of our systems go south. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
Is there a scanning mechanism within Distribution library dataset to scan the memory of frozen Lpar ? On 29-Sep-2017 7:11 AM, "Ed Jaffe" wrote: > On 9/27/2017 2:16 PM, Steely.Mark wrote: > >> A little off topic - when is the last time anyone had to perform a SAD >> ? I haven’t done one in 20+ years. >> > > We take a SAD every time any of our systems go south. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
On 9/27/2017 2:16 PM, Steely.Mark wrote: A little off topic - when is the last time anyone had to perform a SAD ? I haven’t done one in 20+ years. We take a SAD every time any of our systems go south. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
>pointing to another level. It always matches the SADUMP for the OS version. > >Regards, > >Mark >-- >Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS >ITIL v3 Foundation Certified >mailto:m...@mzelden.com >Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html <http://www.mzelden.com/mvsutil.html> >Systems Programming expert at http://search390.techtarget.com/ateExperts/ <http://search390.techtarget.com/ateExperts/> > > > > > >== > >On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson wrote: > >Invitation for early Friday war stories. > >When implementing (OS-moniker-du-jour) 1.6, we had several catastrophic failures that required back out to previous level. We took some SADs during that stormy period. > >When implementing z/OS 1.13, we had several instances of running clean out of real storage! System hit a wait state, took SAD automatically, then re-IPLed itself. That was entertaining. > >We more recently (under 2.1) took SAD and re-IPLed a hung system that would probably have recovered if we had held off a bit longer. Heck, Game of Thrones was on. How long were we supposed to wait? ;-) > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ⇐=== NEW >robin...@sce.com > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steely.Mark >Sent: Wednesday, September 27, 2017 2:16 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: DLIB volume for SAD > >A little off topic - when is the last time anyone had to perform a SAD ? I haven’t done one in 20+ years. > >Thanks > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson >Sent: Wednesday, September 27, 2017 4:11 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DLIB volume for SAD > >My comment was meant more for z/OS release upgrades. In some of our sysplexes, we run both old and new releases for some period before full migration. I guess it's somewhat risky, but we generally rebuild SAD when the first member gets upgraded. If we were shot at, we were missed. ;-) > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ⇐=== NEW >robin...@sce.com > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder >Sent: Wednesday, September 27, 2017 12:42 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: DLIB volume for SAD > > I don't know of any SADMP PTFs that were not downward compatible within the same release of z/OS, and we would certainly try to avoid creating that scenario. > >Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >Poughkeepsie NY > >> In addition the SAD IPL volume should in principle be compatible with >> the level of z/OS that might use it. Periodically changes are made to >> SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could >> conceivably happen that an older level of z/OS might have trouble with >> a higher level SAD IPL volume, but I've never seen it. > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Please be alert for any emails that may ask you for login information or directs you to login via a link. If you believe this message is a phish or aren't sure whether this message is trustworthy, please send the original message as an attachment to 'phish...@timeinc.com'. -- Mark Jacobs Time Customer Service Global Technology Services The standard you walk past is the standard you accept. Lt. Gen. David Morrison -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
> On Sep 28, 2017, at 11:56 AM, Mark Jacobs - Listserv > wrote: > > > > Mr. Murphy taught me a very long time ago that I should always ensure I have > a working SADUMP that matches the OS level requiring it. > > > > Agree. That's why I always rebuilt it after every zOS maintenance cycle, > cause' ya never know. > > Mark Jacobs Mark, I guess I am different and trust IBM more than you do. If there isn’t a ++HOLD for recreation of the SA dump, then I don’t do so. The only exception is if I am bringing up a new system, then its always done. By new system, I mean a complete system received from IBM. I have never run into an instance where doing a lot of maintenance there isn’t a ++HOLD for a new SADUMP. The worst number of years of maintenance was 5 (don’t ask). Its been 25+ years since I have gotten a complete system build from IBM, so my memory might be faulty. Essentially anytime I have to do a system load From IBM, I have always done one as stuff like that will bite you in your a** if you don’t. A few years ago I was doing some work as a true contractor and I was amazed that the people who were to maintain the system after I left did not do a SADUMP redo. I told the manager as I was leaving that he should get some experienced MVS people as the ones he had were not all that competent. He looked at me like I was trying to stay and I repeated to him that he needed to hire a experienced person that knew what they were doing. He said something like my people are experienced. I looked at him and said then you need to hire better people to make sure their manager doesn’t get bitten. Sure enough, I found out that they did not do a rebuild and it messed up the dump. I created a phony yahoo ID and emailed him and told him one last time that he needed to hire someone competent. I found out he finally hired a good person. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
Mr. Murphy taught me a very long time ago that I should always ensure I have a working SADUMP that matches the OS level requiring it. Agree. That's why I always rebuilt it after every zOS maintenance cycle, cause' ya never know. Mark Jacobs Mark Zelden <mailto:m...@mzelden.com> September 28, 2017 at 12:27 PM I didn't respond to the "last time you took an SAD". It has been probably 1.5 years at least since a prod / dev LPAR crashed and took an SAD via AUTOIPL, but it does happen every few years it seems. The other 2 times were more recent and involved sandbox LPARs. One was just a week ago when someone had removed a data set from LPA involving CICS VR because the sandbox LPAR did not run CICS. The LPAR hadn't been IPLed in over a month and the person who removed it didn't think that was the reason for the wait state at IPL time. I was able to look at the SADUMP and figure it out. IBM supplies SYS1.SDWWDLPA with a dummy CICSVR module that NIP looks for at IPL time and I had to add that back into LPA. Mr. Murphy taught me a very long time ago that I should always ensure I have a working SADUMP that matches the OS level requiring it. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html <http://www.mzelden.com/mvsutil.html> Systems Programming expert at http://search390.techtarget.com/ateExperts/ <http://search390.techtarget.com/ateExperts/> On Thu, 28 Sep 2017 11:16:47 -0500, Mark Zelden wrote: >I always put SADUMP for each OS release on the 2nd volume of my maintenance >sysres for each OS release (still using 3390-9s). I create an HMC >profile on each CPC for SADUMP at that time. If I was using a mod-27 or anything >large enough where I didn't have a multi-volume sysres set, I would just put it on >the dlib volume instead (this is what I did years ago). > >Part of my migration / cut over plan for after a "GO" decision when migrating >releases is to update the HMC SADUMP profile for that LPAR and to verify >AUTOIPL SADMP has been updated in DIAGxx to point to that proper >volume as well (this is staged already in a "migration parmlib" concatenated ahead >of the normal parmlib concatenation. So at any given time during OS upgrade >migration, some LPARs are pointing to one level of SADUMP and other LPARs >pointing to another level. It always matches the SADUMP for the OS version. > >Regards, > >Mark >-- >Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS >ITIL v3 Foundation Certified >mailto:m...@mzelden.com >Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html <http://www.mzelden.com/mvsutil.html> >Systems Programming expert at http://search390.techtarget.com/ateExperts/ <http://search390.techtarget.com/ateExperts/> > > > > > >== > >On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson wrote: > >Invitation for early Friday war stories. > >When implementing (OS-moniker-du-jour) 1.6, we had several catastrophic failures that required back out to previous level. We took some SADs during that stormy period. > >When implementing z/OS 1.13, we had several instances of running clean out of real storage! System hit a wait state, took SAD automatically, then re-IPLed itself. That was entertaining. > >We more recently (under 2.1) took SAD and re-IPLed a hung system that would probably have recovered if we had held off a bit longer. Heck, Game of Thrones was on. How long were we supposed to wait? ;-) > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ⇐=== NEW >robin...@sce.com > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steely.Mark >Sent: Wednesday, September 27, 2017 2:16 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: DLIB volume for SAD > >A little off topic - when is the last time anyone had to perform a SAD ? I haven’t done one in 20+ years. > >Thanks > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson >Sent: Wednesday, September 27, 2017 4:11 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DLIB volume for SAD > >My comment was meant more for z/OS release upgrades. In some of our sysplexes, we run both old and new releases for some period before full migration. I guess it's somewhat risky, but we generally rebuild SAD when the first member gets upgraded. If we were
Re: DLIB volume for SAD
I didn't respond to the "last time you took an SAD". It has been probably 1.5 years at least since a prod / dev LPAR crashed and took an SAD via AUTOIPL, but it does happen every few years it seems. The other 2 times were more recent and involved sandbox LPARs. One was just a week ago when someone had removed a data set from LPA involving CICS VR because the sandbox LPAR did not run CICS. The LPAR hadn't been IPLed in over a month and the person who removed it didn't think that was the reason for the wait state at IPL time. I was able to look at the SADUMP and figure it out. IBM supplies SYS1.SDWWDLPA with a dummy CICSVR module that NIP looks for at IPL time and I had to add that back into LPA. Mr. Murphy taught me a very long time ago that I should always ensure I have a working SADUMP that matches the OS level requiring it. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Thu, 28 Sep 2017 11:16:47 -0500, Mark Zelden wrote: >I always put SADUMP for each OS release on the 2nd volume of my maintenance >sysres for each OS release (still using 3390-9s). I create an HMC >profile on each CPC for SADUMP at that time. If I was using a mod-27 or >anything >large enough where I didn't have a multi-volume sysres set, I would just put >it on >the dlib volume instead (this is what I did years ago). > >Part of my migration / cut over plan for after a "GO" decision when migrating >releases is to update the HMC SADUMP profile for that LPAR and to verify >AUTOIPL SADMP has been updated in DIAGxx to point to that proper >volume as well (this is staged already in a "migration parmlib" concatenated >ahead >of the normal parmlib concatenation. So at any given time during OS upgrade >migration, some LPARs are pointing to one level of SADUMP and other LPARs >pointing to another level. It always matches the SADUMP for the OS version. > >Regards, > >Mark >-- >Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS >ITIL v3 Foundation Certified >mailto:m...@mzelden.com >Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html >Systems Programming expert at http://search390.techtarget.com/ateExperts/ > > > > > >== > >On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson >wrote: > >Invitation for early Friday war stories. > >When implementing (OS-moniker-du-jour) 1.6, we had several catastrophic >failures that required back out to previous level. We took some SADs during >that stormy period. > >When implementing z/OS 1.13, we had several instances of running clean out of >real storage! System hit a wait state, took SAD automatically, then re-IPLed >itself. That was entertaining. > >We more recently (under 2.1) took SAD and re-IPLed a hung system that would >probably have recovered if we had held off a bit longer. Heck, Game of Thrones >was on. How long were we supposed to wait? ;-) > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ⇐=== NEW >robin...@sce.com > > >-----Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Steely.Mark >Sent: Wednesday, September 27, 2017 2:16 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: DLIB volume for SAD > >A little off topic - when is the last time anyone had to perform a SAD ? I >haven’t done one in 20+ years. > >Thanks > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Jesse 1 Robinson >Sent: Wednesday, September 27, 2017 4:11 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DLIB volume for SAD > >My comment was meant more for z/OS release upgrades. In some of our sysplexes, >we run both old and new releases for some period before full migration. I >guess it's somewhat risky, but we generally rebuild SAD when the first member >gets upgraded. If we were shot at, we were missed. ;-) > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ⇐=== NEW >robin...@sce.com > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Jim Mulder >Sent: Wednesday
Re: DLIB volume for SAD
I always put SADUMP for each OS release on the 2nd volume of my maintenance sysres for each OS release (still using 3390-9s). I create an HMC profile on each CPC for SADUMP at that time. If I was using a mod-27 or anything large enough where I didn't have a multi-volume sysres set, I would just put it on the dlib volume instead (this is what I did years ago). Part of my migration / cut over plan for after a "GO" decision when migrating releases is to update the HMC SADUMP profile for that LPAR and to verify AUTOIPL SADMP has been updated in DIAGxx to point to that proper volume as well (this is staged already in a "migration parmlib" concatenated ahead of the normal parmlib concatenation. So at any given time during OS upgrade migration, some LPARs are pointing to one level of SADUMP and other LPARs pointing to another level. It always matches the SADUMP for the OS version. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ == On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson wrote: Invitation for early Friday war stories. When implementing (OS-moniker-du-jour) 1.6, we had several catastrophic failures that required back out to previous level. We took some SADs during that stormy period. When implementing z/OS 1.13, we had several instances of running clean out of real storage! System hit a wait state, took SAD automatically, then re-IPLed itself. That was entertaining. We more recently (under 2.1) took SAD and re-IPLed a hung system that would probably have recovered if we had held off a bit longer. Heck, Game of Thrones was on. How long were we supposed to wait? ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steely.Mark Sent: Wednesday, September 27, 2017 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD A little off topic - when is the last time anyone had to perform a SAD ? I haven’t done one in 20+ years. Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Wednesday, September 27, 2017 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DLIB volume for SAD My comment was meant more for z/OS release upgrades. In some of our sysplexes, we run both old and new releases for some period before full migration. I guess it's somewhat risky, but we generally rebuild SAD when the first member gets upgraded. If we were shot at, we were missed. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Wednesday, September 27, 2017 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD I don't know of any SADMP PTFs that were not downward compatible within the same release of z/OS, and we would certainly try to avoid creating that scenario. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > In addition the SAD IPL volume should in principle be compatible with > the level of z/OS that might use it. Periodically changes are made to > SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could > conceivably happen that an older level of z/OS might have trouble with > a higher level SAD IPL volume, but I've never seen it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
In that case, you are taking a risk. We don't try to make SADMP upward or downward compatible across releases, so whether or not that happens to work depends mainly on what changes were made in the Real Storage Manager component. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List wrote on 09/27/2017 05:11:22 PM: > From: Jesse 1 Robinson > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/27/2017 11:08 PM > Subject: Re: DLIB volume for SAD > Sent by: IBM Mainframe Discussion List > > My comment was meant more for z/OS release upgrades. In some of our > sysplexes, we run both old and new releases for some period before > full migration. I guess it's somewhat risky, but we generally > rebuild SAD when the first member gets upgraded. If we were shot at, > we were missed. ;-) > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Jim Mulder > Sent: Wednesday, September 27, 2017 12:42 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: DLIB volume for SAD > > I don't know of any SADMP PTFs that were not downward compatible > within the same release of z/OS, and we would certainly try to avoid > creating that scenario. > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY > > > In addition the SAD IPL volume should in principle be compatible with > > the level of z/OS that might use it. Periodically changes are made to > > SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could > > conceivably happen that an older level of z/OS might have trouble with > > a higher level SAD IPL volume, but I've never seen it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
Invitation for early Friday war stories. When implementing (OS-moniker-du-jour) 1.6, we had several catastrophic failures that required back out to previous level. We took some SADs during that stormy period. When implementing z/OS 1.13, we had several instances of running clean out of real storage! System hit a wait state, took SAD automatically, then re-IPLed itself. That was entertaining. We more recently (under 2.1) took SAD and re-IPLed a hung system that would probably have recovered if we had held off a bit longer. Heck, Game of Thrones was on. How long were we supposed to wait? ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steely.Mark Sent: Wednesday, September 27, 2017 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD A little off topic - when is the last time anyone had to perform a SAD ? I haven’t done one in 20+ years. Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Wednesday, September 27, 2017 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DLIB volume for SAD My comment was meant more for z/OS release upgrades. In some of our sysplexes, we run both old and new releases for some period before full migration. I guess it's somewhat risky, but we generally rebuild SAD when the first member gets upgraded. If we were shot at, we were missed. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Wednesday, September 27, 2017 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD I don't know of any SADMP PTFs that were not downward compatible within the same release of z/OS, and we would certainly try to avoid creating that scenario. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > In addition the SAD IPL volume should in principle be compatible with > the level of z/OS that might use it. Periodically changes are made to > SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could > conceivably happen that an older level of z/OS might have trouble with > a higher level SAD IPL volume, but I've never seen it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
A little off topic - when is the last time anyone had to perform a SAD ? I haven’t done one in 20+ years. Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Wednesday, September 27, 2017 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DLIB volume for SAD My comment was meant more for z/OS release upgrades. In some of our sysplexes, we run both old and new releases for some period before full migration. I guess it's somewhat risky, but we generally rebuild SAD when the first member gets upgraded. If we were shot at, we were missed. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Wednesday, September 27, 2017 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD I don't know of any SADMP PTFs that were not downward compatible within the same release of z/OS, and we would certainly try to avoid creating that scenario. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > In addition the SAD IPL volume should in principle be compatible with > the level of z/OS that might use it. Periodically changes are made to > SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could > conceivably happen that an older level of z/OS might have trouble with > a higher level SAD IPL volume, but I've never seen it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
My comment was meant more for z/OS release upgrades. In some of our sysplexes, we run both old and new releases for some period before full migration. I guess it's somewhat risky, but we generally rebuild SAD when the first member gets upgraded. If we were shot at, we were missed. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Wednesday, September 27, 2017 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD I don't know of any SADMP PTFs that were not downward compatible within the same release of z/OS, and we would certainly try to avoid creating that scenario. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > In addition the SAD IPL volume should in principle be compatible with > the level of z/OS that might use it. Periodically changes are made to > SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could > conceivably happen that an older level of z/OS might have trouble with > a higher level SAD IPL volume, but I've never seen it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
I don't know of any SADMP PTFs that were not downward compatible within the same release of z/OS, and we would certainly try to avoid creating that scenario. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > In addition the SAD IPL volume should in principle be compatible > with the level of z/OS that might use it. Periodically changes are > made to SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It > could conceivably happen that an older level of z/OS might have > trouble with a higher level SAD IPL volume, but I've never seen it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
When I was doing zOS work, sigh, I always rebuilt the SAD environment on &SYSR2 every time I rebuilt my sysres set after maintenance activities. Mark Jacobs Jesse 1 Robinson <mailto:jesse1.robin...@sce.com> September 27, 2017 at 2:13 PM As a practical matter, the SAD IPL volume needs enough space to contain the SYS1.PAGEDUMP.Vxx data set, which seems to be 92 tracks at z/OS 2.1. Furthermore, the volume needs to be reachable--not necessarily online--from every MVS image that might conceivably need to take SAD. Depending on your configuration, you may need more than one SAD IPL volume. In addition the SAD IPL volume should in principle be compatible with the level of z/OS that might use it. Periodically changes are made to SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could conceivably happen that an older level of z/OS might have trouble with a higher level SAD IPL volume, but I've never seen it. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Wednesday, September 27, 2017 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD The only restrictions on the SAD IPL device is that it must not contain a page data set for the system being dumped, and it must not be used as an output device for this dump. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Please be alert for any emails that may ask you for login information or directs you to login via a link. If you believe this message is a phish or aren't sure whether this message is trustworthy, please send the original message as an attachment to 'phish...@timeinc.com'. -- Mark Jacobs Time Customer Service Global Technology Services The standard you walk past is the standard you accept. Lt. Gen. David Morrison -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
As a practical matter, the SAD IPL volume needs enough space to contain the SYS1.PAGEDUMP.Vxx data set, which seems to be 92 tracks at z/OS 2.1. Furthermore, the volume needs to be reachable--not necessarily online--from every MVS image that might conceivably need to take SAD. Depending on your configuration, you may need more than one SAD IPL volume. In addition the SAD IPL volume should in principle be compatible with the level of z/OS that might use it. Periodically changes are made to SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could conceivably happen that an older level of z/OS might have trouble with a higher level SAD IPL volume, but I've never seen it. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Wednesday, September 27, 2017 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DLIB volume for SAD The only restrictions on the SAD IPL device is that it must not contain a page data set for the system being dumped, and it must not be used as an output device for this dump. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > This is general question. > > For the SAD(Standalone dump) IPL, why do we chose DLIB volume UCB ? > How does DLIB volume helps in SAD process ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
On Wed, 27 Sep 2017 22:18:56 +0530, Peter wrote: >For the SAD(Standalone dump) IPL, why do we chose DLIB volume UCB ? How >does DLIB volume helps in SAD process ? One advantage of writing the standalone dump to a DLIB volume is that you (presumably) have a DLIB zone for every target zone. When you apply maintenance that requires that the SAD IPLTEXT be rebuilt, you can maintain multiple SAD IPL volumes that correspond to the multiple MVS IPL volumes. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
The only restrictions on the SAD IPL device is that it must not contain a page data set for the system being dumped, and it must not be used as an output device for this dump. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > This is general question. > > For the SAD(Standalone dump) IPL, why do we chose DLIB volume UCB ? How > does DLIB volume helps in SAD process ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
I don’t know what you mean by dlib volume. I'm assuming you mean SMP DLIB volume. It really doesn’t matter what volume you use to IPL SAD. In our shop, we write SAD ipl code to a few environment specific volumes, that direct SAD to write to a mod-54(s). _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Sent: Wednesday, September 27, 2017 12:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DLIB volume for SAD **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Hi This is general question. For the SAD(Standalone dump) IPL, why do we chose DLIB volume UCB ? How does DLIB volume helps in SAD process ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
If that is where you IPL SAD from, then there is no major issue as the space required is small. You may have to rebuild your SAS IPL text after maintenance or OS upgrade but if you do that after every IPL then there is no issue where the SAD IPL text lives. If that is where your SYS1.SADMP dataset resides, then it may be too small, unless it is spread over multiple volumes. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nathan Astle Sent: Monday, 2 November 2015 6:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DLIB volume for SAD Hi Apology for asking a dummy question. Why do we use Distribution library volume dataset while taking a SAD for a z/OS ? Nathan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN