> When SADMP starts an IPL of MVS, it is essentially the same
>as if you did a Load Clear from the HMC. We don't know or care
>whether it is a new or old operating system.
Good to know.
But Mark has a good point, too:
>But then I realized that the next person who went to the
>HMC to IPL (that didn't use REIPL in the VARY XCF command) would end up
>IPLing from the "old" sysres address.
On the other hand, we are all supposed to use our 'IPL Sheet' for the current
load address and load parm. And I have more than once detected that the sheet
was incorrect.
> 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. 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.
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.
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).
Thanks to those who responded.
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
