Re: Creating a Second IP Stack
Brilliant feedback - thanks - it's good to see that this has blossomed in to something that is at-least potentially useful to more folk than just myse lf. Just to update my personal progress, I've successfully built the second stack and then, because I was able to now access the system through the second stack, I've been able to configure a VSWITCH using what was the primary stack's OSA interface and get the primary stack running through t he VSWITCH. Happiness. I didn't know about the OSA's internal stack - sounds like a useful capability but not something that I'm personally in a position to current ly take advantage of. The same goes for SYSG access - not feasible on my current administrative setup but I'm glad that it's been mentioned. Dumb question: If one logs on to the OSA's internal stack, what does the SCP actually see? Is it a local 3270 at some predefined address? I'd certain ly be interested in learning a little more about this capability - could you maybe point me at the, 'proper' documentation? I have a small puzzlement in that I can't ping either of my stacks from t he other ... I guess that I'm going to be learning a little more about the intricacies of TCP/IP and subnetting in order to get to the bottom of why THAT is the case - but not today, the sun is shining and the dogs are telling me that it's a good day for a walk :-) Again, thanks for all the input. Jeff
Re: Creating a Second IP Stack
An OSAICC present itself to the outside world as a 3270 TELNET server. To the host it looks as LOCAL 3270's, with indeed 4-digt addresses like D000-D0CF The customisation defines with what address a TELNET client is present to the host. In PCOMM, the TELNET end-user one defines as part of its connection defintions not only the IP address of the OSA ICC, but also a LUNAME There are two choises - a LU Name can correspond to a single 4 digit address. If a client is already connected, others must select an other LUname - a LU Name can correspond to a list of addresses (then termed POOL Name), Often one predefines some single address LU names, to connect operator consoles etc. So soem workstations present themselves to the host at well-known 4-digits addresses. At least one pool is then defined for everyone else. Another practice I often see is that one changes the PORT number of the OSA ICC from 23 for example 1000 or 3270, or ... So it is a bit hidden from the public, only the intimates can then use the (limited number of) sessions an OSA ICC provides. This defintion all happens via the HCM, you select the channels of the CPC and then channel Advanced facilities. 2011/3/9 Jeff Gribbin jeff.grib...@gmail.com Brilliant feedback - thanks - it's good to see that this has blossomed into something that is at-least potentially useful to more folk than just myself. Just to update my personal progress, I've successfully built the second stack and then, because I was able to now access the system through the second stack, I've been able to configure a VSWITCH using what was the primary stack's OSA interface and get the primary stack running through the VSWITCH. Happiness. I didn't know about the OSA's internal stack - sounds like a useful capability but not something that I'm personally in a position to currently take advantage of. The same goes for SYSG access - not feasible on my current administrative setup but I'm glad that it's been mentioned. Dumb question: If one logs on to the OSA's internal stack, what does the SCP actually see? Is it a local 3270 at some predefined address? I'd certainly be interested in learning a little more about this capability - could you maybe point me at the, 'proper' documentation? I have a small puzzlement in that I can't ping either of my stacks from the other ... I guess that I'm going to be learning a little more about the intricacies of TCP/IP and subnetting in order to get to the bottom of why THAT is the case - but not today, the sun is shining and the dogs are telling me that it's a good day for a walk :-) Again, thanks for all the input. Jeff -- Kris Buelens, IBM Belgium, VM customer support
Re: Creating a Second IP Stack
On Tuesday, 03/08/2011 at 02:51 EST, Kris Buelens kris.buel...@gmail.com wrote: An OSA ICC is great, but costs real money: the price of that OSA card, it will be dedicated to its OSA ICC function. To clarify, except for 10 Gb ethernet, all OSA cards have two chpids. You assign ICC on a per-chpid basis. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Creating a Second IP Stack
Thanks Alan, I should have mentioned that too. 2011/3/8 Alan Altmark alan_altm...@us.ibm.com On Tuesday, 03/08/2011 at 02:51 EST, Kris Buelens kris.buel...@gmail.com wrote: An OSA ICC is great, but costs real money: the price of that OSA card, it will be dedicated to its OSA ICC function. To clarify, except for 10 Gb ethernet, all OSA cards have two chpids. You assign ICC on a per-chpid basis. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: Creating a Second IP Stack
Also risking the wrath of Chuckie, I can tell you what the person on IBMLink told me when I opened an ETR for this same request: I added my second stack to SYSTEM DTCPARMS: :nick.TCPIP2 :type.server :class.stack :attach.0C00-0C01 I created a TCPIP2 TCPIP file, which only does TN3270. It only has port 23 open and it has its own DEVICE and LINK for the non-QDIO port pair C00-C01 from our OSA-E, its own HOME address, but same mask and gateway handed down from the mount by the Network Gods. I created a TCPIP2 DATA file on 592 with the TCPIPUSERID set to TCPIP2. And its been running that way for a couple of years. I do use the TCP TCPIP2 option on NETSTAT commands. IIRC, the TCPIP person who led me through this was musing that they really should document how to do this in the manuals, since so many people ask the same question. I have not gone to look at the recent books. Ron On Sat, Mar 5, 2011 at 10:07 AM, Jeff Gribbin jeff.grib...@gmail.com wrote: 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
Re: Creating a Second IP Stack
On 3/8/11 1:27 PM, Ron Schmiedge ron.schmie...@gmail.com wrote: IIRC, the TCPIP person who led me through this was musing that they really should document how to do this in the manuals, since so many people ask the same question. I have not gone to look at the recent books. Would be a nice redbook-like thing -- something like A Practical Cookbook of Networking Tasks for VM TCPIP. Adding things like getting a caching DNS server running, setting up FTP servers with RACF and other ESMs, configuring SMTP to forward all outgoing mail to a corporate gateway, etc, etc. I'll see if we can write something up. -- db
Re: Creating a Second IP Stack
On Tuesday, 03/08/2011 at 01:27 EST, Ron Schmiedge ron.schmie...@gmail.com wrote: Also risking the wrath of Chuckie, I can tell you what the person on IBMLink told me when I opened an ETR for this same request: I added my second stack to SYSTEM DTCPARMS: :nick.TCPIP2 :type.server :class.stack :attach.0C00-0C01 Good. I created a TCPIP2 TCPIP file, which only does TN3270. It only has port 23 open and it has its own DEVICE and LINK for the non-QDIO port pair C00-C01 from our OSA-E, its own HOME address, but same mask and gateway handed down from the mount by the Network Gods. Good. I created a TCPIP2 DATA file on 592 with the TCPIPUSERID set to TCPIP2. OK, but it's just taking up space since there is nothing to tell the socket functions to read TCPIP2 DATA. Perhaps your TCPRUNXT is copying TCPIP DATA to the A-disk, overriding values with information from TCPIP2 DATA? And its been running that way for a couple of years. I do use the TCP TCPIP2 option on NETSTAT commands. The TCP operand overrides what is found in TCPIP DATA. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Creating a Second IP Stack
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 Gribbinjeff.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
Re: Creating a Second IP Stack
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 Gribbinjeff.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
Re: Creating a Second IP Stack
1. You are wise in your fear. 2. You are correct in all your suppositions. When I set up an alternate stack, I use TCPRUNXT or the :exit. tag to copy TCPIP DATA from 198 to the 191 with appropriate changes. Regards, Alan Altmark IBM Lab Services - Sent from my BlackBerry Handheld.
Re: Creating a Second IP Stack
:-) (Exits I shall leave as an exercise for another day)
