Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
VM/ESA V2.4 - TCPIP configuration questions
|
I have a good SDL-Hercules setup for VM/ESA V2.4 now. I can start and stop
it and login to MAINT or any of the other pre-configured users and shut it down normally. All this is done with TK4- based automatic startup and shutdown scripts. I found somewhere in the VM/ESA documentation that the system supports a maximum of 2047M in main storage and a separate maximum of 2047M in expanded storage (XPNDSIZE in the Hercules configuration file). I am able to use ARCHMODE ESAME and CPUMODEL 9672 without problems so far. Now I want to configure the TCPIP setup. The preconfigured system defines two external communication devices, 448 for "VTAM SNA" as a P/390 "LAN3172" device and a pair of P/390 "LCS3172" devices at 44A-44B for TCPIP. My understanding at the moment is that Hercules does not yet support the SNA-based "LAN3172" device, is that correct? LCS3172 devices are known to me from configuring other IBM OS systems under Hercules. My Hercules configuration statement for the TCPIP devices is: 044A-044B LCS -n 192.168.1.8 -m 02-AA-BB-CC-DD-EE 192.168.1.81 Where 192.168.1.8 is my host system Win10 IP address and 192.168.1.81 will be this VM/ESA's IP address. All good so far. In the PROFILE TCPIP file under user TCPMAINT the pre-configured system defines the 44A address as a token-ring device rather than as ethernet, so the first change is to make it ethernet: ; 3172 44A/44B ETHERNET DEVICE UNITY LCS 44A LINK ETH44A ETHERNET 0 UNITY The PROFILE TCPIP file also uses a range of 9.x.x.x IP addresses which I presume I need to change to 192.168.x.x addresses, starting with the HOME address and ignoring the static route definitions for other local systems for now: HOME ; local host InterNet addresses (SYS1) 192.168.1.81 ETH44A ; (End of HOME address information) GATEWAY ; (IP) Network First Link Max. Packet Subnet Subnet ; Address Hop Name Size (MTU) Mask Value ; ----------- ------------ ------- ----------- ----------- -------- 192.168.0.0 = ETH44A 1492 0.255.240.0 0.168.0.0 DEFAULTNET 192.168.1.1 ETH44A 1492 0.255.240.0 0 ; (End of GATEWAY Static Routing information) My router is at 192.168.1.1, is the 192.168.0.0 gateway definition correct in the above change? I am especially unsure of the "Subnet Mask" and "Subnet Value" settings, are they correct for a 192.168.x.x local network? Then there is the HOSTS LOCAL file where the 9.x.x.x addresses also need to be changed and I would comment out the "other" systems for now: HOST : 192.168.1.81 : SYS1.P390.MYDOMAIN.ORG, SYS1 :::: ; ; HOST : 192.168.1.82 : SYS2.P390. MYDOMAIN.ORG, SYS2 :::: ; ; HOST : 192.168.1.83 : SYS3.P390. MYDOMAIN.ORG, SYS3 :::: ; ; HOST : 192.168.1.84 : SYS4.P390. MYDOMAIN.ORG, SYS4 :::: ; Am I missing any other changes to get TCPIP up and running? Are any of the changes I listed above incorrect? I do know I may need to update the FTP server data file(s) but I thought I should just start with basic TCPIP changes to begin with. TIA for any assistance you can offer. Peter |
|
I'm sorry, Peter. I attempted to answer this a couple of weeks ago,
but, somehow, my message never seemed to make it into the group. I'll try again. On Sat, Feb 29, 2020 at 03:11:27PM -0500, pjfarley3@... wrote: I have been waiting for someone with more direct knowledge to answer you, but I will go ahead anyway. In a network defined as 192.168.1.0/24, the subnet mask should be 255.255.255.0, the gateway will be 192.168.1.1. You should check the settings in your router, which will show these values, or something else, such as 192.168.0.0/16, with a subnet mask of 255.255.0.0. From everything else that you are showing us, it is the former. Then there is the HOSTS LOCAL file where the 9.x.x.x addresses also I hope that this helps, Brian |
|
Thank you Brian. I did get help on another forum and I believe that I have
toggle quoted message
Show quoted text
gotten basic TCPIP connectivity running. This is the essential part of the setup that I have gotten to work: DEVICE UNITY LCS 44A LINK ETH44A ETHERNET 0 UNITY HOME 192.168.1.81 ETH44A GATEWAY 192.168.1.0 = ETH44A 1492 0 DEFAULTNET 192.168.1.1 ETH44A 1492 0 TRANSLATE START UNITY I'm still not sure why I have to use zero as the subnet mask for both the gateway and defaultnet lines but it works. I can ping my local PC address and named web servers on the outside net (showing I have gotten out to my ISP's DNS servers) and I can ping the VM/ESA instance from my local PC. A tracerte to a named website from the TCPMAINT user works but eventually times out at some server or other out there, but the first 8 or 9 hops show reasonable round-trip times in the 10-30ms range. I am aware of the limitations of any tracerte attempt, so that result seems OK to me. I haven't gotten the VM POSIX environment set up yet so I can't yet try any of the *ix network utilities to see if I really do have full connectivity to the outside world, but I'll get there at some point. A private email from another member of the group requested that I post a file to the group of all of the VM files that I modified to make the TCPIP setup work for me and I will do that at some point soon. I do wish there was a "cookbook" for VM/ESA from IBM about all the steps to set up all the important server machines, but the only ones available on the net seem to just be for z/VM, which has some large and important differences from VM/ESA. I wonder if there was ever a concise cookbook for VM ADCD systems (pre-zPDT setups) like they produced in a Redbook for OS/390 and early z/OS (SG24-6204). I have searched around on the Redbooks site and elsewhere on the net, but there aren't many pertinent books or papers listed for a VM/ESA search argument. Most results seem to be for z/VM, which I guess is to be expected. Thanks again for your help. Regards, Peter -----Original Message-----<Snipped> values, or something else, such as 192.168.0.0/16, with a subnet mask of 255.255.0.0.<Snipped> -- |
|
Martin Taylor
There is a TCP manual (VM/ESA: TCP/IP Function Level 320 Planning and Customization, SC24-5847) that may provide the required answers. There is also a VM/ESA planning and Administration manual which contains a lot of the basic system setup stuff and it was an appendix in that that points the TCP manual.
toggle quoted message
Show quoted text
Regards, Martin. On 14 Mar 2020, at 18:56, pjfarley3 <pjfarley3@...> wrote: |
|
On 3/14/20 12:56 PM, pjfarley3 wrote:
This is the essential part of the setup that I have gotten to work:Is this by chance a nomenclature issue exacerbated by when this functionality was created (and subsequently maintained for backward compatibility)? As in is the "subnet mask" really a true "/sub/-network mask" where the "net mask" is derived from the class of the IP address and the "/sub/net mask" is additional bits used to create a /sub/network? 192.168.1.0 = netmask of 24 & sub-network mask of 0 for 192.168.1.0/24 172.16.0.0 = netmask of 16 & sub-network mask of 8 for a 172.16.0.0/24 10.0.0.0 = netmask of 8 & sub-network mask of 16 for 10.0.0.0/24 I can ping my local PC address and named web servers on the outside net (showing I have gotten out to my ISP's DNS servers) and I can ping the VM/ESA instance from my local PC.Can you correctly ping, or at least (trace)route to, 192.168.0.255 & 192.168.2.0? I would expect that they would both route through your default, 192.168.1.1. (Even if those IPs don't respond.) A tracerte to a named website from the TCPMAINT user works but eventually times out at some server or other out there, but the first 8 or 9 hops show reasonable round-trip times in the 10-30ms range. I am aware of the limitations of any tracerte attempt, so that result seems OK to me.This sounds like a typical traceroute where the far end is filtering things. -- Grant. . . . unix || die |
|
(partial piggyback)
Grant Taylor wrote: pjfarley3 wrote:This is the essential part of the setup that I have My profile (for QETH/OSA)(*) looks like this: DEVICE PORTA MPCIPA LINK ETH1 IPAQENET PORTA HOME 192.168.0.4 ETH1 BEGINRoutes ; Destination SubnetMask FirstHop LinkName Size ROUTE 192.168.0.0 255.255.0.0 = ETH1 MTU 1492 ROUTE DEFAULT 192.168.0.99 ETH1 MTU 1492 ENDRoutes Me neither. As I've shown above, I personally use BEGINRoutes/ENDRoutes which apparently requires(?) a subnet mask to go along with the specified destination.I'm still not sure why I have to use zero as the subnet mask Is this by chance a nomenclature issue exacerbated by whenI have no idea, but what you say makes sense I guess. <shrug> <snip rest> -------------------------------- (*) I personally stopped using LCS and switched over to using OSA devices instead several years ago. Works great. Haven't had a lick of trouble. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
Fish,
First, apologies for a delayed reply.? Once again for some reason I did not get your or Grant's replies in my email (and not in local junk folder or in my ISP's virus-quarantine folder either), so I'm writing this from the web interface. Second, thanks for showing me your setup as an example, but is your setup for a recent MVS system or for a recent VM system?? The TCPIP in the VM version that I am working with is ancient and still uses the (deprecated in more recent TCPIP implementations) GATEWAY configuration statement. The VM version I am working with does however support BeginRoutes / EndRoutes, so I can try out your example to see if it improves my situation. I am also not positive that the TCPIP implementation I am using supports an OSA device, but but it well might, so I can try that out as well.? We are talking about a circa-1999 TCPIP code base written in Pascal/VS. Four questions: 1. What does your Hercules device statement look like for the OSA device? ??? E.G., for the 44A device address in my example, would the QETH statement look like: ??? 44A-44B QETH CHPID F0 IPADDR 192.168.1.81/24 MTU 1492 2. How does your TCPIP DEVICE statement tie into the Hercules QETH/OSA device?? I don't see a device address in your TCPIP DEVICE statement. 3. Am I presuming correctly that your host TCPIP thinks it is at IP address 192.168.0.4? 4. Am I presuming correctly that your router is at IP address 192.168.0.99? Again, thanks for your help in? curing my immense ignorance. Peter -- |
|
Hi Grant,
First, as I said to Fish, my apologies for the delayed reply.? Something about the email behavior of this forum and/or my ISP is not letting me see responses to my emailed messages. Second, I do not yet know the answer to your nomenclature question.? I will have to dig into the TCPIP documentation for this version to see what I can find out about it. Third,? I have not tried pinging to non-existing local IP addresses as you suggest, but I will try it out and see what it does. My thanks to you also for helping to cure my ignorance in this arena. Peter -- |
|
pjfarley3 wrote:
Fish,Weird. That should NOT be! Are you 100% certain you have your groups.io profile settings configured correctly? For the "Subscription" setting (left column of screen), I have the "(@) Individual Messages" bullet item selected ("You will receive each message in an individual email.") At the bottom of that same screen (below the "Signature" section), there should be a link labeled "Advanced Preferences". Clicking that (to expand that section), I have the "(@) All Messages" bullet item selected. Then click the "Save" button at the bottom of the screen to save your new preferences of course. If that still doesn't allow you to receive ALL posts by *everyone* (including yourself), then something is obviously broken somewhere. Either something in groups.io (unlikely in my opinion) or something at Earthlink (more likely), or else something in between the two (equally likely). Second, thanks for showing me your setup as an example, butFor a "recent MVS system". For my "recent VM systems", I don't know how VM's TCPIP is configured. I've never had to mess with it. For "recent VM systems" the decision regarding how you want your TCP/IP configured is made during installation. The install exec (I forget its name) asks you what type of device you want to use for networking, LCS or OSA and what your IP address should be, etc. It then automatically configures everything according to the values you tell it. And as I said this is done during INSTALLATION, so once the system has been installed, there's nothing further I need to do. I never have to make any changes or tweaks or anything from then on. I never have to mess with TCPIP at all. It just works. But that's for "recent VM systems". For "recent MVS systems", I can easily change my configuration at any time by just updating my TCPIP PROFILE, etc. That's what I showed you. My settings that I showed you were from my "recent MVS system's" profile. Sorry for the confusion. [...] I am also not positive that the TCPIP implementation I amI have no idea if VM/ESA supports OSA or not. I don't have VM/ESA. I only have one "modern VM" system. To be safe, I would recommend IGNORING what I wrote previously (about OSA) and stick with using LCS instead. In your particular situation (VM/ESA) it's probably much safer and has a higher chance of actual success. Four questions:For Windows, you need to specify which host adapter you want Hercules (CTCI-WIN actually) to use. This is specified by the "iface" option. You also need 3 devices, not two. So your statement should be: 44A.3 QETH IFACE 192.168.1.8 CHPID F0 IPADDR 192.168.1.81/24 But again, I suggest sticking with LCS since we know for certain VM/ESA supports it. OSA/QETH we're not so sure about, and trying to use it could well be just a waste of time. Maybe. I don't know. It's up to you whether or not you want to risk giving it a try. (I myself wouldn't. I myself would stick with LCS for older VM systems.) 2. How does your TCPIP DEVICE statement tie into the HerculesWhen I originally replied, I was replying with my "modern MVS system's" settings. I apologize. I fear I've only confused matters. My apologies. For the record however, in mumble-mumble-oh-ess (i.e. "recent MVS systems"), there is a VTAM member you need to also configure which defines the association between the "device" you specify in TCPIP PROFILE and the actual device addresses of the actual device. For VM systems (recent or older), I have no idea how that's done. Sorry. 3. Am I presuming correctly that your host TCPIP thinksUm, "host TCPIP"? Not sure what you mean by that. In the example I gave, 192.168.0.4 is the IP address of the Hercules GUEST system, i.e. the IP address of mumble-mumble-oh-ess. 4. Am I presuming correctly that your router is at IP addressCorrect. Again, thanks for your help in curing my immense ignorance.It's not that hard really. The golden rule (at least on Windows) is, and always has been, to configure your Hercules guest system -- whether it's z/OS or z/VM or any other mainframe system -- as if it was a real system physically connected to your real local network. You would assign it its own unique IP address, you would use the same default gateway, the same subnet mask. The only extra out-of-the-ordinary thing you need to do is tell Hercules which HOST ADAPTER you want Hercules to use for its emulation. That's what the "iface" option is on your OSA/QETH device statement, or what the "-n" option is on your LCS device statement. That's the only "extra" thing you need to do. Everything else is just normal networking configuration. I hope that helps. And once again, I apologize sincerely for the confusion. I'm usually pretty careful in my replies when it comes to paying attention to details, but I dropped the ball this time. I replied with my "recent MVS" system's configuration instead of paying attention to the fact that you were trying to configure your VM/ESA system. My apologies for unintentionally creating confusion. :( -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
On Thu, Mar 19, 2020 at 04:09 PM, Fish Fish wrote:
For the "Subscription" setting (left column of screen), I have the "(@) Individual Messages" bullet item selected ("You will receive each message in an individual email.")Well what do you know - if you highlight the beginning of a reply you want to paste into a new reply it seems to "automatically" copy the highlighted text, without a manual paste.? We'll see how long that lasts. Yes, I have that Individual Messages button clicked, and the Advanced All Messages button too.? I did not have "Follow all Replies" checked, so I am trying that one to see if it makes a difference. And the rest of the quotes below had to be manually copiid and pasted. > For Windows, you need to specify which host adapter you want Hercules (CTCI-WIN actually) to use. This is specified by the "iface" option. You also need 3 devices, not two. So your statement should be: > 44A.3 QETH IFACE 192.168.1.8 CHPID F0 IPADDR 192.168.1.81/24 Yes, but in my case 192.168.1.8 is my Windows system IP address, how is that an "interface"?? Shouldn't that be the Router address (in my case 192.168.1.1)? > But again, I suggest sticking with LCS since we know for certain VM/ESA supports it. Agreed, I'll try that last of all.? Too many variables introduced otherwise. > When I originally replied, I was replying with my "modern MVS system's" settings. I apologize. I fear I've only confused matters. My apologies. > For the record however, in mumble-mumble-oh-ess (i.e. "recent MVS systems"), there is a VTAM member you need to also configure which defines the association between the "device" you specify in TCPIP PROFILE and the actual device addresses of the actual device. > For VM systems (recent or older), I have no idea how that's done. Sorry. No problem.? This ancient VM has a VTAM component as well that I am leaving out of consideration for now. 3. Am I presuming correctly that your host TCPIP thinks> Um, "host TCPIP"? Not sure what you mean by that. < In the example I gave, 192.168.0.4 is the IP address of the Hercules GUEST system, i.e. the IP address of mumble-mumble-oh-ess. Yes, that is what I meant.? I should have written that more clearly as "Hercules guest OS TCPIP". > The only extra out-of-the-ordinary thing you need to do is tell Hercules which HOST ADAPTER you want Hercules to use for its emulation. That's what the "iface" option is on your OSA/QETH device statement, or what the "-n" option is on your LCS device statement. That's the only "extra" thing you need to do. Everything else is just normal networking configuration. Hmm-m-m.? I thought the "-n" option on LCS was only for the host system's MAC address.? Does that mean you can specify the host PC's IP address instead (with the usual CTCI-WIN caveats about how Win10 selects the "first" adapter)? > I hope that helps. It has, thank you again. Peter |
|
I wrote:
> Hmm-m-m.? I thought the "-n" option on LCS was only for the host system's MAC address.? Does that mean you can specify the host PC's IP address instead (with the usual CTCI-WIN caveats about how Win10 selects the "first" adapter)? Ignore that comment please.? I looked again at my LCS adapter device line in the Hercules CNF file and indeed I had my PC's IP address specified there. I'm going to change that to the actual MAC address of my ethernet adapter (wired) and see if that improves anything. Thanks again for your help. Peter |
|
pjfarley3 wrote:
Fish wrote:[...] Well, perhaps "interface" isn't the best choice of words, but by "interface" (i.e. "iface") we mean the host adapter/interface/device that Hercules (i.e. CTCI-WIN) should use to inject packets onto, and pull packets from, your local network.44A.3 QETH IFACE 192.168.1.8 CHPID F0 IPADDR 192.168.1.81/24Yes, but in my case 192.168.1.8 is my Windows system IP address, Shouldn't that be the Router address (in my case 192.168.1.1)?No. It should be your Windows adapter (usually identified by IP address, but which may optionally be identified by MAC address instead, e.g. "iface 11-22-33-44-55-66"). It is your REAL Windows adapter that provides YOU -- the Hercules "host" -- with *real* network access. Since Hercules (via CTCI-WIN) needs to be able to access your REAL local network (in order to inject your Hercules guest's packets ONTO your local network, and to be able to GRAB response packets destined for your guest FROM your local network), it needs access to a device that is able to physically read/write packets to/from your REAL local network. That device is your REAL Windows adapter. This the "iface" parameter of your Hercules OSA/QETH device statement needs to specify your REAL Windows adapter's IP address (or, optionally, MAC address). Your network router (192.168.1.1) is simply the DEFAULT GATEWAY for your local network. That is the value that *should* be specified in your Windows adapter for its default gateway, and it is the SAME default gateway that you should specify in or your GUEST'S network configuration (i.e. your VM/ESA's networking configuration should specify the same default gateway too). Your default gateway (your router) knows how to route packets for your local network. When it receives a packet that's NOT for your local network, it knows it needs to send it out on the internet. When it receives the response from the internet, it then sends it back to where it came from: either your Windows system or your Hercules guest. When it "sends the response back to your Hercules guest", what it's actually doing is truly WRITING the packet onto your REAL PHYSICAL LOCAL NETWORK. Since your Window system has a REAL network adapter physically connected to your local network (and since CTCI-WIN, as part of its initialization, sets your Windows host adapter into "promiscuous" mode), it "sees" that packet (that your router wants to return back to your Hercules guest), which CTCI-WIN (with the help of the WinPCap device driver) "grabs" the packet from the adapter's input queue and passes it on to Hercules (which then passes it back to your VM/ESA guest). Voila! [...] Nope. It's EITHER one: IP address -or- MAC address:The only extra out-of-the-ordinary thing you need to doHmm-m-m. I thought the "-n" option on LCS was only for the The LCS '-n' option identifies which host adapter you want Hercules to use for network access. You specify which adapter via the '-n' option, where the value you specify can be EITHER your Windows host adapter's IP address -OR- its MAC address. Either way it doesn't matter. Both serve to identify exactly what real physical Windows adapter you want Hercules to use. Maybe you were confusing the '-m' option with the '-n' option? The '-m' option assigns a MAC address to your GUEST'S "adapter", which has NOTHING to do with the '-n' option. They're completely different things. Refer to the above URL. Does that mean you can specify the host PC's IPYes. Correct. One way or the other you need to tell Hercules which host adapter you want it to use. For LCS devices that is done via the '-n' option. For OSA/QETH devices it is specified via the "iface" option. But either one -- either the '-n' option for LCS devices or the "iface" option for OSA/QETH devices -- may identify the Windows host adapter via IP address -or- MAC address. Both options support both. Both options support specifying their value as either an IP address -or- as a MAC address (since, after all, BOTH end up identifying *exactly* what adapter you want to use! Which is the whole point of the option!). You're very welcome.I hope that helps.It has, thank you again. I hope I haven't confused you too much and apologize in advance if I have. If there's anything unclear or confusing, let me know and I'll TRY to explain it better. But I hope I've explained things well enough. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
On Fri, Mar 20, 2020 at 12:01 AM, Fish Fish wrote:
I hope I haven't confused you too much and apologize in advance if I have.Not at all.? It is much clearer now, thank you again. Now if I can figure out why one copy of my VM system seems to be able to use my router's DNS function for resolving named IP addresses and another copy (*supposedly* configured the same way with the same parameters) does not, I'll be a little further along the road. That little problem just HAS to be a TCPIP configuration difference somewhere in the system but I'm still hunting that down. Regards, Peter -- |
|
On Thu, 2020-03-19 at 13:09 -0700, Fish Fish wrote:
pjfarley3 wrote:I second Fish's recommendation. ?Stick with LCS.stick with using LCS instead. In your particular situation (VM/ESA) Regardless of how Hercules communicates with the host operating system, an OSA device requires the Hercules guest software to implement certain channel commands and know how to handle the queues established for use by the OSA device. ?I strongly doubt that your version of VM knows how to do that. ?Nor does it know how to pass such data to your virtual machine in which TCPIP resides. While my memory can be faulty, an OSA device requires a certain type of channel that did not exist when VM/ESA was released. Harold Grovesteen |
|
On Fri, Mar 20, 2020 at 10:00 AM, Harold Grovesteen wrote:
<Snipped> I second Fish's recommendation. ?Stick with LCS.And yet, the V2.4.0-era manuals include one entitled "Open Systems Adapter Support Facility User¡¯s Guide For OSA-2", SC28-1992-03. where the Fourth Edition (June 1999) notes specifically say: "This edition, SC28-1992-03, applies to Virtual Machine/Enterprise Systems Architecture (VM/ESA), Version 2 Release 2.4, program number 5654-030, and to all subsequent releases and modifications until otherwise indicated in new editions." So there must have been *some* OSA hardware available then, and it seems to me that V2.4.0 must include capabilities available at V2.2.4, at least based on the above-quoted note. Nevertheless, sticking with LCS for now since I know that device type actually works.? Might experiment later if time and energy permit. Thanks for your advice and help. Peter |
|
On Fri, 2020-03-20 at 17:23 -0700, pjfarley3 wrote:
On Fri, Mar 20, 2020 at 10:00 AM, Harold Grovesteen wrote:Let's not get hung up on the term "OSA". ?OSA is a marketing term by a vendor. To what I was referring specifically was QDIO. ?The "OSA" device configured by Hercules assumes support for QDIO. ?It only supports QDIO. ?QDIO is a more recent mode of communication. ?At least I do not remember QDIO being available in 1999 when I was a network architect for a global organization. ?The first mention I see of QDIO is in the zSeries 900 technical guide, copyrighted in September 2002, with regards to the OSA Express as opposed to the OSA-2 to which you referred. The OSA-2 uses some other networking protocol. ?If supported by Hercules, it would not be configured in Hercules as an "OSA" device, namely a QETH device configuration statement. ?It would be defined using some other Hercules device configuration statement that supports networking. ?Likely in fact a LCS which is of ESA/390 vintage. ?But some research may be required. Harold Grovesteen |
|
On Mon, Mar 23, 2020 at 10:05 AM, Harold Grovesteen wrote:
<Snipped> Let's not get hung up on the term "OSA". ?OSA is a marketing term by a That makes sense.? I will stick with LCS. Now if I can just figure out what I did to make one instance of this VM able to use DNS and another that cannot, I'll be a little further along the way. There is a file in the VM TCPIP system named ADDRESS TCPIP.? Do you know what component uses that file, and perhaps where its use may be documented?? I have searched the TCPIP manuals in vain for any reference to it. It's not a complex file, just a network mask and a default route address plus a bunch of "system" and "client" statements with associated IP addresses, like this: SUBNET MASK: 0.255.255.0 DEFAULT ROUTER: 192.168.1.1 SYS1 192.168.1.81 SYS2 192.168.1.82 SYS3 192.168.1.83 . . . . . . CLIENT-10 192.168.1.96 CLIENT-11 192.168.1.97 CLIENT-12 192.168.1.98 If you have any idea what this file is used for I'd appreciate any pointer to documentation about it. Peter |
|
George Shedlock
¿ªÔÆÌåÓýIt has been a while since I did any of
this, so this may be from a more recent vintage of tcpip.
IBM knowledge page at
has the information you are looking
for. In TCPIP.DATA there is a NSINTERADDR or NAMESEVER statement
that points to your nameserver for name resolution.
George
On 3/23/2020 12:01 PM, pjfarley3 wrote:
On Mon, Mar 23, 2020 at 10:05 AM, Harold Grovesteen wrote:
|
|
On Mon, Mar 23, 2020 at 12:10 PM, George Shedlock wrote:
Thanks George, I do already have the NSINTERADDR set in the TCPIP PROFILE file in VM (TCPIP.DATA is specific to z/OS, the VM TCPIP implementation uses different file name conventions native to VM).? My question was about the VM file ADDRESS TCPIP and whether its use is documented anywhere. Peter |
to navigate to use esc to dismiss