Re: DLIB volume for SAD

[Jesse 1 Robinson]

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 <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
> <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
> <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

Re: DLIB volume for SAD

[Anthony Thompson]

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" <edja...@phoenixsoftware.com> 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

[Peter]

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

[Ed Jaffe]

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

[Mark Jacobs - Listserv]

 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 
<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


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

[Edward Gould]

> 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

[Mark Jacobs - Listserv]

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 <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 
<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 
<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. 

Re: DLIB volume for SAD

[Mark Zelden]

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 +, 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 
>Se

Re: DLIB volume for SAD

[Mark Zelden]

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 <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

Re: DLIB volume for SAD

[Jim Mulder]

  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 <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
09/27/2017 05:11:22 PM:

> From: Jesse 1 Robinson <jesse1.robin...@sce.com>
> 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 <IBM-MAIN@LISTSERV.UA.EDU>
> 
> 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

[Jesse 1 Robinson]

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

[Steely.Mark]

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

[Jim Mulder]

  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

[Jesse 1 Robinson]

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

[Tom Marchant]

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

[Jim Mulder]

  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

[Jousma, David]

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

[Paul Gillis]

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