One last non-expert post on this topic. For the first Load of SAD after an
MVS IPL, Store Status will yield the same results whether requested
implicitly or explicitly.
For any subsequent Load, a new Store Status will capture data from the last
control program that was running. In the case described, it sounds like SAD
got far enough that a second attempt would indeed show SAD code in real
storage. Whether old (MVS) Store Status data would be of any use at that
point is questionable. In this case, Store Status might be irrelevant,
although vast amounts of real storage could still be mined for clues to the
original failure depending on far SAD got.
But another classic case of failed SAD is simply pointing to the wrong IPL
volume, one that has no IPL text on it. In that case, a second SAD attempt
might succeed because real storage has not been 'corrupted'. That's the
case where a second Store Status might mess things up by losing MVS related
data.
In other words, it's probably best practice not to set the Store Status
flag when IPLing SAD. It can hardly help in any scenario but might well
cause trouble.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
Barbara Nitz
<[EMAIL PROTECTED]
> To
Sent by: IBM [email protected]
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> Re: Stand-Alone Dump Process
09/02/2007 11:15
PM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
>So you almost always want exactly one and only Store Status for SAD
>to capture.
>In real life, many shops take advantage of HMC wizardry to define SAD load
>profile(s). These profiles must be different from regular OS load profiles
>because the IPL device for SAD is never a sysres volume and may differ
>from one LPAR to another. You have the option in an SAD load profile--
>still, I think?--to set the Store Status option.
Yes, the option is still there.
>The temptation is to set it because this is by definition a SAD profile.
>I used to do that until I was advised otherwise: if the first shot at SAD
>goes awry for some transitory and immediately correctable reason, you DO
>NOT want a second Store Status on retry. Only the first Store Status, the
>one from the OS, is of any use UNLESS you trying to debug SAD itself. BTW
>I have never once done that in my whole career.
Well, this thread comes in handy. I have just generated (and tested) sadump
for 1.8. And during testing, I clicked on the option for store status
(despite having read NOT to do it, as I was really unsure). The sadump I
then took was definitely readable and was NOT a dump of an sadump. It was
showing everything I expected it to show, including all system address
spaces that were up at the time.
I had been regenerating sadump from tape to DASD (dsntype LARGE), and my
first attempt went wrong due to operator error. I re-IPL'd sadump (without
store status, I think), and *that* was definitely a dump of a dump (sadump
even tells me so).
So I guess now I am really confused with the whole issue of store status or
not.
Regards, Barbara Nitz
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
