Kenneth
Unfortunately you snipped off the part which contained Mark's original
question and hence your post doesn't make as much sense as it could -
however specific or non-specific about terminology!
The missing question was as follows:
<quote>
So if I opened a dos window on my win-doze system and wanted to use telnet
to get into z/OS UNIX (or used a telnet client), how would it know where to
go to?
</quote>
And I explained how, namely, use the right IP address as the destination.
Perhaps you needed me to take a shot at drumming home the point that "an IP
address does not a server platform make", in other words, a server platform
can have many *interfaces* and an IP addresses is associated with an
*interface* and *not* with a *node*.
It's this fact that opens the door to having a *virtual* interface with a
*virtual* IP address (VIPA), independent of hardware and available on a one
to one basis with each server application - in the highly desirable extreme.
I think what you are trying to get over is that the term "port sharing" as
used in this thread may need some clarification. It hadn't occurred to me
nor had I seen any glimmer of confusion in the hitherto contributors over
this but I guess it's worth covering - although I still don't see how I was
obscuring the matter in my terminology.
As you rightly say, the IP logic demultiplexes arriving packets not only on
the basis of the port number but also on the basis of the destination IP
address. This point is easily overlooked because a server application will,
by default and with typically no opportunity to change the default, expect
to accept TCP connections or an UDP packet no matter what the value of the
IP address in the destination IP address field of the IP packet.
What actually happens? When the bind() call is issued over the socket API,
the referenced C structure contains a port address and an IP address. These
are the values used by the underlying IP logic to route arriving packets
with a destination IP address matching an IP address in the "HOME" list to
an application. If the IP address in the C structure has the value binary
zero, in dotted decimal, 0.0.0.0, or, as defined by the C #define,
INADDR_ANY, the actual value of the destination IP address field is
ignored - and most users either never knew or soon forgot - amongst all the
other points made during their TCP/UDP socket programming course - that the
destination IP address matters as well as the port number.
What the PORT statement entry BIND parameter does is replace the 0.0.0.0 (or
INADDR_ANY) value with a particular IP address. Note that the substitution
will happen *only* if the IP address field in the C structure contains
0.0.0.0 (or INADDR_ANY). If the application program designer had the wit to
specify that the IP address to be inserted into the C structure should be a
parameter in the same way that the port number generally is, use of such a
parameter could replace use of the PORT statement entry BIND parameter.
Note also that I do try to be careful with my terminology since the IBM
sources universally mention INADDR_ANY in this context.
It can be any type of IP address so that the type of "port sharing" we are
talking about here can be achieved by using real interface addresses. Thus
you could "share" port 23 for TN3270 and otelnetd so long as clients wanting
TN3270 always arrived on one particular interface and clients wanting
otelnetd always arrived on another particular interface[1]. This, of course,
is not generally a practical proposition and so VIPAs will nearly always be
used. Furthermore, in order to provide maximum assistance to the end-users,
a name server should convert some friendly name such as tn3270.abc.com and
otelnetd.abc.com to the appropriate VIPA.
Edward's example - and I think the example in the Communications Server
manual (which I couldn't quickly find) - indicate another point about this
"sharing" or a port. If the underlying logic performing the demultiplexing
discovers that there is a particular port number together with a particular
IP address and the same port number together with an all-zero IP address, it
will attempt to match on the particular IP address before it accepts that a
match on the port number is all that is needed.
Finally I see that there is a t to cross or an i to dot over the matter of
the association of the IP address specified by the BIND parameter of the
PORT statement entry and the application. Well, this is quite simple in that
it's the "jobname" parameter as specified in the PORT statement entry - as
the Communications Server IP Configuration Reference has it, without any
reference to the port number. Just exactly what the "jobname" parameter is
is, as they say, "beyond the scope of this document". Suffice to say that,
for UNIX System Services server applications, OMVS is often seen.
So I hope that enables the answer to be understood without reservation. On
the other hand, if it isn't, you know what to do. I'll be "listening"!
Chris Mason
[1] Or, in fact, any other interfaces - or vice versa - see my comment about
Edward's example.
----- Original Message -----
From: "Kenneth E Tomiak" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Saturday, August 04, 2007 4:25 PM
Subject: Re: OMVS
For those willing to be less specific about terminology and still want to
understand the answer-
There is no port sharing, the combination of ipaddress:port is unique to an
application. In order to share ipaddress:port the two applications vying to
receive the packets coming inbound would have to talk to each other and
resolve who should do what with them. Consider trying to share port 12345
between a web server and a tn3270 server, not going to work. But qualify it
as shown in the examples previously shown as ipaddress:port and get each to
listen for their ipaddress AND port and the perception you are sharing the
port
can be realized. If you really shared the port it would be like two jobs
reading
the same tape at the same time. They are not going to each get every record.
Some applications are designed to listen for traffic by port on all your
host's
ipaddresses so 'sharing' is not going to work as you wish.
You can run, I believe, up to eight TCP/IP stacks. They would be using
unique
ipaddress:port combinations for the applications they support.
On Sat, 4 Aug 2007 02:21:42 +0200, Chris Mason
<[EMAIL PROTECTED]> wrote:
Mark
Please see my post in reply to Edward's post which is his reply to this
post - if you can line up all the posts!
The specific answer to your question is that, in order to connect to the
traditional "TCP/IP for MVS" REXECD and RSHD services, you will use the IP
address of one of interfaces to the IP instance and , in order to connect
to
the OMVS REXECD and RSHD services, you will use the VIPA 192.168.1.129,
using the VIPA in Edward's example.
As I point out in the other post, I - and APAR PQ37421 - prefer that you
use
VIPAs as the destination for all services. Thus you would also use a VIPA
in
order to connect to the traditional "TCP/IP for MVS" REXECD and RSHD
services.
On review I see you are interested only in TELNET. You need simply to
substitute port number 23 - and the name of your TN3270 server - in one set
from Edward's example. Or you can use the example in APAR PQ37421:
23 TCP INTCLIEN BIND 9.67.113.109 ;3270 TELNET
23 TCP OMVS BIND 9.67.116.55 ;UNIX TELNET
On Fri, 3 Aug 2007 10:47:56 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:
For services we've configured more recently, we share the *same* port
number between the native z/OS server and the z/OS UNIX server by using
VIPA. For example, here's our TCPIP port definition for REXECD/RSHD:
512 TCP OMVS BIND 192.168.1.129 ; z/OS Unix REXECD
514 TCP OMVS BIND 192.168.1.129 ; z/OS Unix RSHD
512 TCP RXSERVE ; Remote Execution Server
514 TCP RXSERVE ; Remote Execution Server
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
