> And you must have a dedicated port number on z/OS to use. We use port 2023.

Sorry John - not strictly true - unless there's a consideration of which I am 
unaware which prevents use of the well-documented technique I am about to 
propose as an alternative.

The "trick" is to use "virtual IP addresses" (VIPAs) - decided on the IBMTCP-L 
list better to be described as "virtual *interface* IP addresses" - in 
combination with the BIND parameter of the relevant PORT statement list entries.

Thus you have a PORT statement list entry for the SNA-oriented TELNET server 
and you have a PORT statement list entry for the UNIX-oriented TELNET server.

Here's an example based on just how the BIND parameter works, the sample given 
in section 2.22.5, "Configuring TSO and z/OS UNIX Remote Execution servers to 
use the same port" in the z/OS Communications Server IP Configuration Guide, 
various other bits and pieces of information in the same manual and the 
Configuration Reference manual:

Definition of VIPAs:

VIPADYNAMIC
 VIPARANGE 255.255.255.255 10.1.1.1
 VIPARANGE 255.255.255.255 10.1.1.2
ENDVIPADYNAMIC

Extract of PORT statement:

PORT
 ...
 23 TCP TN3270E BIND 10.1.1.1
 23 TCP OMVS    BIND 10.1.1.2
 ...

Extract of /etc/services:

...
otelnet 23/tcp
...

Extract of inetd.conf:

...
otelnet stream tcp nowait OMVSKERN /usr/sbin/otelnetd otelnetd
...

For clients who wish to access the SNA-oriented TELNET server, ideally a name 
system entry will be available which specifies IP address 10.1.1.1 as the 
destination so that entry of the command

telnet sna.my.lovely.system.com

causes a TELNET connection to 10.1.1.1, port 23.

For clients who wish to access the UNIX-oriented TELNET server, ideally a name 
system entry will be available which specifies IP address 10.1.1.2 as the 
destination so that entry of the command

telnet unix.my.lovely.system.com

causes a TELNET connection to 10.1.1.2, port 23.

Thus neither of the TELNET servers need use a *dedicated* port number.

Note that I prefer to propose VIPARANGE dynamic VIPA with the PORT statement 
list entry BIND parameter rather than static VIPA for server applications just 
as a matter of course. The reason is that the associated "service" will be 
"advertised" using whatever dynamic routing protocol is in use *only* when the 
"service" is available.

-

Incidentally, I'd be grateful if someone with a "sandbox" and a bit of time on 
their hands could verify this sample.

-

Chris Mason

On Thu, 5 Apr 2012 09:44:39 -0500, McKown, John <john.mck...@healthmarkets.com> 
wrote:

>Using SSH is, IMO, superior. But if you are dead set on using Telnet (perhaps 
>due to lack of an SSH client - I suggest PuTTY), then you must be running the 
>INETD daemon. And you must have a dedicated port number on z/OS to use. We use 
>port 2023. In the /etc/inetd.conf file, you need a line like:
>
>2023      stream tcp nowait BPXROOT /usr/sbin/otelnetd otelnetd -l -t -D login
>
>Replace the "2023" with the port you want to use. Then, to get a UNIX shell 
>prompt, you telnet into that port number. This works for me.
>
>--
>John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Reply via email to