An OSA ICC is great, but costs real money: the price of that OSA card, it will be dedicated to its OSA ICC function.
An other backdoor, that costs you nothing, is using the "Integrated 3270 Console", found on the HMC. And if you setup remote access to the HMC, you can use it from anywhere (like I do for example from Belgium to a z/VM system in Switserland in emergency cases). An "Integrated 3270 Console" has its limitations though: no filetransfer, no graphics, not the "classsic" PCOMM keyboard. But for basic VM work it is perfectly OK: FILELIST, XEDIT, SAPL, all work perfectly well. 2011/3/7 Tom Duerbusch <duerbus...@stlouiscity.com> > Where there are many reasons why you might want a second IP stack, if the > only reason is to have a back door TN3270 session, then try using the ICC > port. (An OSA port configured for ICC.) These are always up and you can > TN3270 into them, get a VM logo (in the VM world), and fix what ever > problems that messed up the stack. > > An OSA port configured for ICC, has its own IP stack running in firmware. > You can't touch it. You can only configure it. Once configured, it's hard > to mess up. Certainly, you will never mess it up by changing the > configuration on you IP stack (unless you try to assign the same IP address > <G>. But even if you do configure the same IP address, the first one up > (the ICC) wins.) > > Tom Duerbusch > THD Consulting > > >>> Jeff Gribbin<jeff.grib...@gmail.com> 3/5/2011 10:07 AM >>> > Greetings, > I may be a, 'VM-Oldie' but I'm most certainly a, 'TCP/IP Newbie' and, true > to form, I'm already wishing to push the envelope a little ... > > I'm helping to maintain a not-very-busy z/VM system which is pretty-much > starting from scratch and currently has no asociated SLA's or the such to > worry about. It's not quite a sandpit, but pretty close. I access the > system via TN3270 and, in order to allow me to perform surgery on the main > TCP/IP stack (bog-standard vanilla configuration, straight out of the box), > I'm looking to place a second IP stack alongside the primary stack that > will > give me at-least a TN3270, 'back door' into the system. > > My, 'problem' is TCPIP DATA, which appears to be a unique filename. > 'TCP/IP > Planning and Customization' states quite categorically that TCPIP DATA > defines parameters used by TCPIP -client- applications. If this is truly > the case then it would seem that all I need in order to implement a second > stack purely for TN3270 purposes is to create appropriate '<userid> > DTCPARMS' and '<userid> TCPIP' files on TCPMAINT's 0198 and I'm away. > > Would I be correct in thinking that TCPIP DATA is, 'merely' read by the, > 'client' commands in order (e.g.) to locate the servers that they need to > interact with. If this is so, would it be acceptable practise (that is, > behaviour that would not bring the Wrath of Chuckie upon me) to keep a > second copy of TCPIP DATA, configured according to the userid(s) of the > second stack, on a separate minidisk and access that minidisk in front of > TCPMAINT's 592 when wishing to, 'converse' with the second stack? (For > example, in order to issue a NETSTAT command without needing to specify > the, > 'TCP' option every time.) > > I can, of course, discover most of this empirically for myself - and will > indeed be experimenting a little (what else to do on a wet Saturday > afternoon?) - but if for no other reason that the Fear of Chuckie I would > be > reassured if somebody with more experience were willing to sanity-check my > hypothesis and proposed, 'solution'. > > Thanks > Jeff > -- Kris Buelens, IBM Belgium, VM customer support
