Beauty indeed - one more beautiful aspect to the VIPA!
APAR PQ37421, "SUPPORT TO ALLOW MULTIPLE DISSIMILAR SERVERS TO USE THE SAME
TCPPORT", "closed" date 2000-04-26, introduces the function and provides an
example - the example being - wouldn't you know it? - port 23 and TELNET:
<quote>
This new function APAR adds the BIND keyword to the PORT statement. The BIND
keyword followed by the IP address causes the TCP/IP stack to substitute the
specified IP address in the bind when an application binds to the reserved
port with an address of INADDR_ANY. Multiple PORT statements for the same
TCP port using different server jobnames and specifying BIND with different
IP addresses can allow multiple servers to bind to the same port on the same
stack without changing the servers.
This function can allow the TN3270 server and OS/390 Unix telnet to both
listen on port 23. The IP address following the BIND keyword can be a real
address or a virtual IP address (VIPA). Static and dynamic VIPAs are
supported. For example,
23 TCP INTCLIEN BIND 9.67.113.109 ;3270 TELNET
23 TCP OMVS BIND 9.67.116.55 ;UNIX TELNET
...
</quote>
Note that, rather than use just one VIPA, the example uses a VIPA for both
server instances. This is much to be encouraged since, in a way, it implies
that VIPAs are already in use in order to profit from their undoubted
benefits. Thus the example may be regarded as an extension of the wise use
of VIPAs. It differs from - and I would say is superior to - the REXECD and
RSHD example in Edward's earlier post.
Note that, if the invocation of the server program has parameters which
allow a specific IP address to be specified - typically in addition to the
usual option to allow a non-standard port number to be specified - this can
be an alternative to the use of the PORT statement BIND parameter. If both
are specified the invocation parameter will take precedence since the PORT
statement BIND parameter will only substitute an IP address in the BIND
structure in place of INADDR_ANY (or, in effect, 0.0.0.0).
Here is an extract from an article with the concatenated headers "NCP and
3745/46 Today | Summer 2001, OS/390, z/OS, TCP/IP, Parallel Sysplex, Section
II: Network Technology, OS/390 and z/OS TCP/IP in the Parallel Sysplex
Environment - Blurring the Boundaries", which covers the topic of so-called
"Server Bind Control" with a quite detailed outline!
<quote>
Server Bind Control
Server Bind Control actually addresses two different requirements. The first
requirement concerns different and incompatible server application instances
identified by the same well-known port number, when no such server instance
can be configured to use a specific IP address. One example would be OTELNET
and TN3270, both of which use well-known port 23 and accept requests from
any IP address (binding to INADDR_ANY in socket terms), but which use
different application protocols. If the servers use the same application
protocol, normal port-sharing functions would allow the server instances to
coexist on the same TCP/IP stack.
However, the stack balances connections between server instances sharing the
same port, and has no way to know that a client needs to use one particular
server over another. Before Server Bind Control, this requirement was
addressed through the use of different TCP/IP stack instances, associating
one server instance type with one stack, and the other server instance type
with the other stack, such that DNS/WLM returns only addresses appropriate
for the name of the particular server type. Note that if the server
instances themselves could bind to different IP addresses, there would be no
problem running both server instances on a single stack, because the
destination IP address would uniquely identify the type of server, and the
DNS could be configured to supply the correct IP address for each server
type.
Server Bind Control allows the OS/390 TCP/IP stack to be configured to
address this. A modification to the PORT configuration statement allows an
IP address to be specified and associated with a particular job name. If the
server job binds its listening socket to a particular IP address, nothing
new occurs. However, if the server job binds its listening socket to
INADDR_ANY, OS/390 TCP/IP converts the bind to use only the specified IP
address. In the example above, OTELNET would be configured for one IP
address, and TN3270 would be configured for a different address, with an
appropriate DNS name to IP address configuration. Both servers can now run
on the same TCP/IP stack using the same well-known port, and clients are
automatically directed to the required server instance.
Note that this also addresses the concern identified above with some UDP
server applications. If such a server application is configured to the
TCP/IP stack to be bound to a specific IP address, the problem of SOURCEVIPA
causing a response to use a source address that is different from the one
specified on the corresponding previous request goes away, because the
socket is bound solely to the designated address.
The specified address can also be a Dynamic VIPA, and need not already be
active on the stack at the time that the application establishes its
listening socket. In other words, applications that bind to INADDR_ANY can
now use application-initiated Dynamic VIPAs, with all the benefits of such
use, including the ability to restart the application on another OS/390
image (with an appropriate TCP/IP configuration already in place) and have
the Dynamic VIPA move with the application. This configuration is available
for both TCP and UDP applications, because the PORT statement differentiates
between the two.
</quote>
Normally if I see someone either in IBM-MAIN or IBMTCP-L - obviously only
the threads which catch or retain my attention - suffering under the
delusion that they are obliged to pluck a non-standard port number out of
the aether in order to run one of two server applications in order to
connect with which the client will default to trying to use the same port
number, I endeavour to encourage the use of VIPAs and the PORT statement
entry BIND parameter so kindly introduced by IBM with APAR PQ37421 - so long
ago. One more time won't hurt!
Chris Mason
----- Original Message -----
From: "Edward Jaffe" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Saturday, August 04, 2007 12:38 AM
Subject: Re: OMVS
Mark Zelden wrote:
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?
Which server you get depends on entirely which host IP address you use
when you connect. That's the beauty of it.
--
Edward E Jaffe
----------------------------------------------------------------------
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
