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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Jacobs - Listserv Sent: Thursday, September 28, 2017 9:57 AM To: [email protected] Subject: (External):Re: DLIB volume for SAD <snip> 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. <snip> Agree. That's why I always rebuilt it after every zOS maintenance cycle, cause' ya never know. Mark Jacobs > Mark Zelden <mailto:[email protected]> > 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:[email protected] 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 <[email protected]> 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:[email protected] 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 +0000, Jesse 1 Robinson > <[email protected]> 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 > >[email protected] > > > > > >-----Original Message----- > >From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Steely.Mark > >Sent: Wednesday, September 27, 2017 2:16 PM > >To: [email protected] > >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:[email protected]] > On Behalf Of Jesse 1 Robinson > >Sent: Wednesday, September 27, 2017 4:11 PM > >To: [email protected] > >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 > >[email protected] > > > > > >-----Original Message----- > >From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Jim Mulder > >Sent: Wednesday, September 27, 2017 12:42 PM > >To: [email protected] > >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. > > -- Mark Jacobs Time Customer Service Global Technology Services ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
