VM/ESA V2.4 - TCPIP configuration questions


pjfarley3
 

On Tue, Mar 24, 2020 at 01:15 PM, pjfarley3 wrote:
On Mon, Mar 23, 2020 at 12:10 PM, George Shedlock wrote:
It has been a while since I did any of this, so this may be from a more recent vintage of tcpip.
 
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
<Snipped>
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
George, I apologize for doubting you.  Your advice was right on target.  This VM TCPIP also has a TCPIP DATA file with most of the same entries as other more current implementations.  In my second instance setup I completely forgot that I changed the VM TCPIP DATA file and did not copy those modifications from the first system to the second system.

Getting the TCPIP DATA file straightened out lets me ping any external domain as well as all my locally networked systems.

Thank you again for pointing me in the right direction.

Peter


pjfarley3
 

On Mon, Mar 23, 2020 at 12:10 PM, George Shedlock wrote:
It has been a while since I did any of this, so this may be from a more recent vintage of tcpip.
 
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
<Snipped>
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


George Shedlock <gshedlock352@...>
 

It has been a while since I did any of this, so this may be from a more recent vintage of tcpip.

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:
<Snipped>
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

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

Virus-free. www.avg.com



pjfarley3
 

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
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

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


Harold Grovesteen
 

On Fri, 2020-03-20 at 17:23 -0700, pjfarley3 wrote:
On Fri, Mar 20, 2020 at 10:00 AM, Harold Grovesteen wrote:
<Snipped>
I second Fish's recommendation.  Stick with LCS.

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.
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
 
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


pjfarley3
 

On Fri, Mar 20, 2020 at 10:00 AM, Harold Grovesteen wrote:
<Snipped>
I second Fish's recommendation.  Stick with LCS.

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.
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


Harold Grovesteen
 

On Thu, 2020-03-19 at 13:09 -0700, Fish Fish wrote:
pjfarley3 wrote:


 
stick with using LCS instead. In your particular situation (VM/ESA)
it's probably much safer and has a higher chance of actual success.
I second Fish's recommendation.  Stick with LCS.

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


pjfarley3
 

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.

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.
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
--


Fish Fish
 

pjfarley3 wrote:
Fish wrote:
[...]
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"?
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.

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!


[...]
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.
Nope. It's EITHER one: IP address -or- MAC address:

https://sdl-hercules-390.github.io/html/hercconf.html#LCS

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 IP
address instead (with the usual CTCI-WIN caveats
about how Win10 selects the "first" adapter)?
Yes. 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!).


I hope that helps.
It has, thank you again.
You're very welcome.

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
http://www.softdevlabs.com
mail: fish@...


pjfarley3
 

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
 

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.")

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.
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
it is at IP address 192.168.0.4?
> 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


Fish Fish
 

pjfarley3 wrote:

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.
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, but
is your setup for a recent MVS system or for a recent VM system?
For 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 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.
I 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:

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
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 Hercules
QETH/OSA device? I don't see a device address in your TCPIP
DEVICE statement.
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.


3. Am I presuming correctly that your host TCPIP thinks
it is at IP address 192.168.0.4?
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.


4. Am I presuming correctly that your router is at IP address
192.168.0.99?
Correct.


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
http://www.softdevlabs.com
mail: fish@...


pjfarley3
 

Thank you Martin, I have that manual and will dig into it for information.

Peter
--


pjfarley3
 

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
 

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
--


Fish Fish
 

(partial piggyback)

Grant Taylor wrote:
pjfarley3 wrote:

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

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


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.
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.


Is this by chance a nomenclature issue exacerbated by when
this functionality was created (and subsequently maintained
for backward compatibility)?
I 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
http://www.softdevlabs.com
mail: fish@...


Grant Taylor
 

On 3/14/20 12:56 PM, pjfarley3 wrote:
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.
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


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.

Regards,
Martin.

On 14 Mar 2020, at 18:56, pjfarley3 <pjfarley3@...> wrote:

Thank you Brian. I did get help on another forum and I believe that I have
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-----
From: h390-vm@groups.io <h390-vm@groups.io> On Behalf Of Brian
McCullough
Sent: Saturday, March 14, 2020 11:22 AM
To: h390-vm@groups.io
Subject: Re: [h390-vm] VM/ESA V2.4 - TCPIP configuration questions

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.
<Snipped>

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.
<Snipped>

I hope that this helps,
Brian
--




pjfarley3
 

Thank you Brian. I did get help on another forum and I believe that I have
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-----
From: h390-vm@groups.io <h390-vm@groups.io> On Behalf Of Brian
McCullough
Sent: Saturday, March 14, 2020 11:22 AM
To: h390-vm@groups.io
Subject: Re: [h390-vm] VM/ESA V2.4 - TCPIP configuration questions

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.
<Snipped>

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.
<Snipped>

I hope that this helps,
Brian
--


Brian McCullough
 

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:

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.


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?
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
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 hope that this helps,
Brian