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
