If the goal is emergency access to fix a broken TCPIP there is always the 3270 session available through the HMC.
Brian Nielsen On Thu, 17 Apr 2008 12:03:18 -0400, [EMAIL PROTECTED] wrote: >Our network went down overnight, so I couldn't connect to the mainframe >through my PC this morning. I hit the KVM switch tucked behind my >monitor and connected to the mainframe through the PC connected to the >ICC LAN. Is this a possible solution for you for emergency access? > >Peter > >-----Original Message----- >From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On >Behalf Of Alan Ackerman >Sent: April 16, 2008 19:27 >To: [email protected] >Subject: Second TCPIP stack and SSL > >We have been ordered to protect all TN3270 sessions to VM with SSL. This > >means turning on SSLSERV and disabling non-SSL. (INTERNALCLIENTPARMS >SECURECONNECTION REQUIRED, I think.) IBM level 2 has suggested that >other >shops have a second TCP/IP stack to use when there are problems with >TCPIP >or SSLSERV. (We have found several problems with SSLSERV in our >testing.) > >I'm curious whether and how other shops use a second TCP/IP stack. > >Some possibilities: > >1. Have a second TCPIP stack up all the time (userids TCPIP2 and >MPROUTE2), but with no SSL. It would run on a second IP address. (This >is >security by obscurity.) > >2. Have a second TCPIP stack up all the time, with SSL required. >(Userids >TCPIP2, MPROUTE2, SSLSERV2.) This takes 2-3 more 3390-3 packs per >system, >as well as a second IP address for each. (We have 6 first-level VM >systems, so those packs add up. There is also the administrative time to > >get new certificates, etc.) > >3. Have a second TCPIP stack, kept down, with no SSL, but brought up by >operations when we request it. It would have a second IP address. (So we > >could test without bringing down the other TCPIP stack.) > >4. Have a second TCPIP stack, kept down, with no SSL, but brought up by >operations when we request it. Assume the first stack is down and steal >the IP address. We could only test during stand-alone time. > >We do have a seond way to get into our systems, a PC-based product >called >AP View. It has been unreliable here, and in some cases we have to ask >operations to page the AP View support, either becsaue it is not working > >or because we are only allowed Read/Only access via AP View to some (the > >most important, naturally) VM systems. This slows down recovery. > >We are trying to get rid of VTAM. (Actually, we are waiting for the z/OS > >folks on this.) So that is not a good alternative. > >Alan Ackerman >Alan (dot) Ackerman (at) Bank of America (dot) com > > >The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entitie s other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability fo r the content of this e-mail or for the consequences of any actions taken o n the basis of information provided. The recipient should check this e-mai l and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
