Or, what about an arbitrary parameter the operator could pass on the SAPL screen (alongside CONS=xxx etc) that one could query, e.g; IPLREASON=xxxx. Because: maintaining an extra SYSTEM CONFIG is often forgotten.
2007/10/3, Thomas Kern <[EMAIL PROTECTED]>: > > This is where it would be nice to be able to set (via SYSTEM CONFIG) an > arbitrary name with an arbitrary value and be able to query it from any > virtual machine. But without that we have to usurp other functions. I use > > the GATEWAY value, setting it in the system config based on which CPU I i > pl > on. Perhaps even the PRODUCT enable/disable statements could be used to a > dd > our own pseudo-PRODUCTs and enable then in our home system config, but > disable in our DR system config. Then once things get straight at DR, > manually issue the PRODUCT enable commands and xautolog the appropriate g > uests. > > /Tom Kern > > > On Wed, 3 Oct 2007 18:28:54 +0200, Kris Buelens <[EMAIL PROTECTED]> > wrote: > > >Our disaster backup process stores a control file on AUTOLOG1 191 when t > he > >backup of that minidisk is taken (a very short while) and it is erased > >afterwards. The PROFILE EXEC of AUTOLOG1 checks for the presence of thi > s > >file, if found; it prompts the operator to ask if it is really an IPL af > ter > >a disaster; it will not continue until the operator sends an SMSG YES or > > >NO. This prompt is required as there is a -small- chance that VM dies w > hile > >AUTOLGO1 is being backed up on the disaster tapes. If the operator repl > ies > >YES, AUTOLOG1 and AUTOLGO2 will take very different actions, so that onl > y > >VMBACKUP & co will be started as to enable restoring the VMBACKUP ta > pes. > > > >Testing the CPUID is only good when after a disaster you IPL on another > >CPU. But, what if you have fatal disk problems (or someone whiping out > your > >resident). > -- Kris Buelens, IBM Belgium, VM customer support
