> For restartable wait states which are not in the WSAT,
>no AutoIPL action is taken.
>
> For nonrestartable wait states which are not in the WSAT,
>the current AutoIPL action from DIAGxx is taken.
>
> 0A2-104 is nonrestartable. So your AutoIPL action
>will be taken.
Ah. Then I misunderstood the WSAT. I thought only those with the sadump bit on
will be sadump'd. For the others, only MVS will be IPL'd. But I haven't checked
storage. I didn't understand that *any* non-restartable wait state would result
in sadump(parms) mvs(parms).
> There is spare space in the WSAT, and it is possible
>to use AMASPZAP to add additional entries if necessary.
:-)
>But I don't think we documented how to do that.
>It would be necessary, for example, if you wanted to
>use AutoIPL with a SLIP A=WAIT trap, which is a restartable
>Wait01B.
Reminds me of the customer who complained after taking an sadump for a slip
with a=wait that MVS wasn't restartable afterwards. :-)
> The AMDSADMP macro has allowed you to specify SYSC as the first
>thing in the CONSOLE list since OS/390 2.10. But you have never
>needed to specify it. You can always use the system console, whether
>you specify it in the CONSOLE list or not.
Then I must not have seen it. We had been using teh HMC ever since I took over
generating sadump here (after OS/290 2.10).
> If your specify CONSOLE=(SYSC) with no devices, the default console
>01F is automatically added. That seems undesirable (and I
>have already received one customer complaint about it), but I
>am not at liberty to incompatibly change the behavior, even
>if it doesn't make sense.
Yes, I saw the mnote in the assembly. The job ended cc=0, anyway, and I decided
that that's just default behaviour. I found it strnage, though.
Why are others at liberty for incompatible changes?!? (See the stupid health
checker thing that suddenly required a dataset - incompatible change).
> SADMP always dumps all real storage. The options apply only to
>virtual storage which is paged out.
*You* know that and *I* know that, but IBM support doesn't. You wouldn't
believe how often I am told that storage is not in the sadump. In many cases it
is a simple case of support being unable to specify the correct dataspace name
when browsing or some IPCS command / addition being unable to access the
dataspace even though it was there. *You* would know how to figure out the
virtual address from a real address. I am not sure I would - I haven't done
enough debugging to stay fluent in it.
And the other general support excuse is that their tools (not IPCS) don't work,
hence storage is not in dump. :-( It is always quite embarassing for them when
I ask why *I* can see the storage but they cannot.
> This will dump all paged out storage:
>
>DUMP=('DSP OF ASID(ALL) ALSO PAGETABLES OF DATASPACES X
>ALSO SP(ALL) IN ASID(ALL) X
>ALSO HIGH VIRTUAL IN ASID(ALL)'), X
For performance/timing reasons I had held off sadumping all paged out storage.
Anyone out there have numbers how long it takes for a - say - 8GB real lpar
with aux usage at 40% (on 12 locals of 49500 tracks each) in comparison to only
dumping paged-in pages?
(No comments on the 40%, please!)
Barbara
----------------------------------------------------------------------
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
