> > AutoIPL processing is driven by the wait state code/reason code
> >that ends up occurring, so the question is, what would that be in
> >the situation you are describing? If the system is alive enough
> >that XCF's status update task can get dispatched and read from
> >the couple data set, then I would guess that you could end up
> >with the desired 0A2 wait state with the reason code for the
> >DUMP/REIPL options of VARY XCF,OFF. If it is not alive
> >enough to do that, and you have SFM set up to do fencing, then
> >the system should eventually get fenced because it is not
> >updating its status, and it should be able to respond to
> >being fenced by loading the 0A2-104 wait state. (It only
> >needs to be alive enough to process a machine check and
> >dispatch an SRB in *Master* for that to happen).
>
> With a tight memterm tcb loop in *master*, an SRB scheduled in
> *master* would probably get dispatched sooner than the tcb in xcfas
> (when you have only one or two cps in that lpar). So the (routed to)
> vary xcf,offline will probably not work.
The fencing would only occur if the XCFAS TCB does not get
dispatched to update its status.
>Unfortunately a wait0A2-104
> is not in the WSAT. So automatic sadump for tight tcb loops in
> address spaces at SYSTEM priority will most probably not work.
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.
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.
> As for the sadump itself, I have set it up like Mark, with
> DDSPROMPT=NO,CONSOLE=((400,3278)),
> and *that* console doesn't exist. In any case, the first one to give
> an interrupt will be used. And the instructions say to use the HMC.
> I guess I'll change the sadump program to use console=sysc. I don't
> think that option existed when I last looked at Tools&Service Aids.
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.
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.
> I had wanted the ability to specify additional options for the
> dumping in the case something is wrong that my standard dataspaces
> don't cover (now why doesn't sadump automatically dump OMVS and all
> *its* dataspaces, especially in today's clickable-is-everything
> world???? And/or ZFS? One more way for IBM to tell the customer 'the
> data is not in the dump'.) On the other hand, even I would be hard-
> pressed to get the syntax right in an emergency, so I better hope my
> standard dataspace collection
> ('CONSOLE','*MASTER*','RASP','OMVS','JES2','SMSPDSE','SMSPDSE1')
> will suffice (we don't use ZFS).
SADMP always dumps all real storage. The options apply only to
virtual storage which is paged out.
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
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
----------------------------------------------------------------------
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
