> 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