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 <m...@mzelden.com> 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 +0000, Jesse 1 Robinson <jesse1.robin...@sce.com> >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
