We have an ancient (soon top be replaced) OS/390 guest that comes up at each z/VM system IPL via and AUTOLOG command in AUTOLOG2.
It runs completely disconnected, and VM:Operator (could be PROP) responds to OS/390 prompts with appropriate replies to get it fully up (no human operator actions) with some rexx code (stripped to its bare essentials below):
/* */ address COMMAND
parse upper arg parms 1 operands '(' options ')' parmrest
svmname='OSGUEST'
If parms='?' | parms='' then Signal Explain
parse var parms w1 rest
If w1='CP'
then 'CP SEND CP' svmname rest /* Pass CP command */
else 'CP SEND CP' svmname 'VINPUT VMSG' parms /* Pass MVS cmd */
IIRC, the trick to getting all that to work was AUTOLOGing the guest and causing the IPL to begin on the default virtual 3215 console. All bets are off if you logon to the guest an IPL with a virtual 3270 (as in TERM CONMODE 3270).
Our CONSOLE statement in the CP directory for that guest is:
CONSOLE 0700 3215 C OPERATOR
(in this case: 0700) defined to OS/390 as a 3215, and having the guest SCIF'ed to "OPERATOR" (as also defined in the CONSOLE statement).
Because the console is SCIFed to OPERATOR, as long as OPERATOR is logged on, the guest is not subject to the time in the "SYSTEM CONFIG"s "FEATURES DISCONNECT_TIMEOUT nn".
I do recall some posts on the tricky subject of SCIF vs "DISCONNECT_TIMEOUT". Things get fuzzy very quickly.
BTW, if you logon an IPL from "TERM CONMODE 3270" and the z/OS guest enters a disabled wait state, the messages are cleared before you can read them. Unlike z/VM, a z/OS system will actually come up on a 3215, allowing you after the failure to enter: TERM CONMODE 3215, then IPL again. Now all the messages remain on the virtual 3215 screen, even after a Disabled Wait State, until you clear them. Very nice. I can hardly believe that I said "very nice" about something on z/OS. Good thing it's Friday; I need a drink! %-}~
We are fortunate that the particular z/VM system can be IPled every Sunday evening. The OS guest comes up every week without any problems.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
| "Tom Pajak" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <[email protected]> 09/28/2006 04:42 PM
|
|
It has been a couple of years since I worked on this stuff, but - We ran
all
of our OS guests with disconnected consoles. In fact they usually were
brought up disconnected. Most likely the way they are disconnected has an
effect on whether they disappear after the 15 minute point. We never chan
ged
the 15 minute criteria. I recall that the command SET RUN ON was require
d
also. Then to disconnect, you had to be sure you were talking to CP
properly. I think we would do a #cp disc whenever we had to bring a guest
OS
up and then disconnect it. After that we would use a dial command from an
available terminal to use as an OS console. That however was not required
, I
do not believe.
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
