Ivica may "have it". We may have a similar situation. One of our z/VM systems was designed to be IPLed at the same datacenter where the processor lives. It's "consoles" are actually on a "mainframe LAN", and the "consoles" are actually PComm sessions connected to z/VM through a 2074 controller so that they appear to PComm as locally attached 3270's. That way, when the system is IPLed, or (God forbid) fails, there is no TCPIP stack requirement for messages to appear on the console.
But one day Console Operations added a Console Operations Center in the other (3+ miles away) "remote data center. There have been no terminals connected via a 2074 controller to that z/VM system. So Console Operations, unaware that they are using the z/VM TCPIP stack to logon to OPERATOR from that data center. When they enter: SHUTDOWN REIPL, they only see a few (if any) of the shutdown messages before the "TCPIP" userid/service machine shuts down. They they have to wait a few minutes for the SHUTDOWN REIPL to complete. To get OPERATOR started quickly on that system, the "PROFILE EXEC" for "OPERATOR" includes "CP TERMINAL MORE 0 0 HOLD OFF", and the "PROFILE EXEC" for "AUTOLOG1" contains "CP XAUTOLOG TCPIP". Console Operations waits a couple minutes and then starts repetitively clicking on PComm's "Communications>Disconnect", and then "Communications>Connect". After a few minutes, once the TCPIP stack has initialized, the session pops up and they can "LOGON OPERATOR HERE" and also logon sundry other userids from that data center. When it won't reconnect after a few minutes, they call the original data center for someone to look at the OPERATOR console to see what went wrong, or someone has to drive to that data center to take a look. Why not just IPL from that Data Center? Let's not go there... Is that "best practices"? Absolutely not! But then, no one consulted with us sysprogs before creating the Operations Center in that data center and splitting the Console Operations staff between the two data centers. It's been like that for a few years. I've repeatedly begged and groveled for some 2074-connected terminal sessions between the "remote" data center and that z/VM system. Just last week a renewed session of begging and groveling paid off... some should be defined this weekend. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Ivica Brodaric" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <[email protected]> 07/27/2008 11:45 AM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: z/VM IPL What did you put in Operator_consoles in SYSTEM CONFIG? That defines where will you get the first messages after the IPL. You have to give us a bit more than "it doesn't come up". There are many things in VM that may or may not come up depending on how you configure it. When you say "remotely" I assume you mean that you are accessing VM through TCPIP and you are not getting a signon screen. Did you put 'XAUTOLOG TCPIP' in PROFILE EXEC of AUTOLOG1 user? If you didn't, TCPIP stack will not come up. That's just one thing that may not come up. Which reader files were you going through? How can you possibly go through reader files if the system didn't come up? Ivica 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. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
