> 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html