Alan Altmark wrote:
> Amen to that. VM TCP/IP doesn't get any more of a free pass than any
> other guest and gets all the benefits VSWITCH can provide.
>
> The only question you need to be able to answer is: What is your
alternate
> logon path if VM TCP/IP OR the VSWITCH is down? You need to have
> emergency automation, OSA-ICC or HMC 3270.
> WARNING: THE OSAs ARE NOW IN THE POSESSION OF VM TCP/IP
> ONLY TELNET IS AVAILABLE. ACCESS IS RESTRICTED TO
> MAINT, OPERATOR, AND SUPER-SECRET USERID CHUCKIE.
> YOU HAVE -- 15 -- MINUTES UNTIL SYSTEM SHUTDOWN.
> STOP SHUTDOWN MY SUCCESSFULLY LOGGING ON AND
> ISSUING "SMSG MOTHER CANCEL".
>
Well, my legacy systems still run VTAM (with redundant OSAs and FICON CTC
paths to the z/OS CMC's), and I also interconnect them all with PVM. If
either VTAM or TCPIP is alive on any system, I can probably get to any
other.
On my Linux-hosting systems, I have both a TCPIP and a TCPIP2 stack. TCPIP
has a VSWITCH connection, and redundant FICON CTCs (through different
directors) connected to the IFL and z/OS LPARs on a CEC in our other
datacenter, as well as hipersocket connections to z/OS systems on the same
CEC (BTW, the OSAs on the z/OS systems need to be defined as PRIROUTERs if
they're going to provide a path to your IFLs if everything else is down).
Need to run MPROUTE here, of course, and setting appropriate COST0 factors
can get tricky.
TCPIP2 is my trusty "back door", and can be set up with a hipersocket, CTC,
VSWITCH, or OSA connection (whichever suits your configuration the best).
Nothing fancy. You just want it to work WHEN YOU REALLY NEED IT, like when
you need to work on the primary stack machine, or in spite of all your
fancy configuration efforts the darn thing goes down anyway. :-( I run
limitted services on it - just telnet and FTP. And OSASF, again just in
case.
True story: Our z/OS systems TCPIP's are configured with two OSAs
(different than the OSAs used by the IFL's) and use VIPA for high
availability. They were upgraded to z/OS 1.7 a while back and there was a
bug (a combination of software and microcode problems, IIRC) that caused
BOTH OSA connections to drop (and could not be restarted). For two days no
one noticed! Why? Because OSPF had dutifully rerouted traffic to the z/OS
system through the IFL's VSWITCH and across the hipersocket link. And if
that VM system had been down, the z/OS traffic would have been routed to
the VSWITCH of the IFL in the other datacenter and across the FICON CTC
link. Cool, no? We continued to run that way until the following weekend,
when the z/OS folks could schedule a planned outage to fix their problem.
<sarcasm>
And that's another reason why we're killing our IFLs. (:{
</sarcasm>
Mark Wheeler, 3M Company
