Lindy You may be right. It depends on the installation.
Normally an installation is set up in such a way that a particular port number corresponds to a particular "server" application but it doesn't have to be. Normally TELNET can be found when you connect to port 23 (not 25[1]) from your TELNET "client" and normally RLOGIND can be found when you connect to port 513 - and you use transport protocol TCP (not UDP[2]) from your RLOGIN client. However it is common for both a "client" and a "server" for a particular application protocol to allow another port number to be used. This is where there may be a dependency on the installation. As a "client", you need to know which port number to specify if the installation you are contacting doesn't use the "well-known" port number. Why allow a "non-standard" port number? When testing a new "server" program perhaps. A related topic which can also "bite" you is the following: It is the intention of the "services" file, C:\WINNT\SYSTEM32\devices\etc\Services on my NT system, that a "server" will, by default, also not assume a port number - but will assume a character string to represent the application service as a "service name". Thus when the "server" uses the calls getservbyname() call specifying the "service name" and also the appropriate transport protocol, normally "tcp" or "udp", a port number is returned. You can imagine how it is done if I show you the two relevant entries from my "Services" file. Note that "Services" files are, in principle, identical on all systems supporting the sockets API. telnet 23/tcp login 513/tcp I expect that any "server" program which doesn't receive a port number from a parameter when it is started will not assume a port number but use the getservbyname() call in order to discover the port number. Clearly an alternative to using, typically, a PORT parameter - or some UNIXy -p or -P parameter probably - is sneakily to slip the change into the "Services" file - not recommended in general but available if the author of the "server" program "forgot" to allow for a PORT parameter, Of course, if the author "forgot" to allow for a PORT parameter he/she may also have "forgotten" to bother with the getservbyname() call. <g> Why am I bothering to tell you all this? Well, there's still a problem to solve. I thought actually that what I am about to describe was what you were asking about here; it's not - but it is related. There are 2 flavours of TELNET "server" available in Communications Server IP: 1. The old TELNET "server" used to map to an SNA session either as a pretend 3767 (a typewriter device, almost forgotten now) secondary logical unit (SLU) or as a pretend 3270 display device SLU. This is now - just a trifle misleadingly - called the TN3270 "server" in the manuals. 2. A "truer" TELNET "server" where the line-by-line behaviour is more like what you experience with the TELNET service on other platforms. This includes also a sort-of "full screen" behaviour which (I believe) mimics the ASCII devices which use the de facto standard VT100 data stream for "full screen" applications. This "server" is the OTELNETD program. Traditionally TCP/IP for MVS through to Communications Server IP have assigned port number 23 to the TN3270 "server". However, with the availability of the OTENETD program, it may be argued that it actually makes more sense to assign port number 23 to the OTELNETD "server". As indicated perhaps a trifle mistakenly in the posts from Mark Zelden and Ramiro Camposagrado, they mention using port number 23 for the TN3270 "server" and port number 623 for the OTELNETD "server" and Mark even mentions using the port numbers the other way round. Now I can't remember ever actually using the RLOGIN protocol so I thought I'd better do just a little research. I found, the 4th hit with >rlogind login 513<, http://www.tcpipguide.com/free/t_BerkeleyRemoteLoginrlogin.htm which seemed to deal with the topic adequately enough, sufficiently for me to be clear that TELNET in general and OTELNETD in particular were not the same as RLOGIN. This is where I think both Mark and Ramiro have managed to get slightly confused. Mark and Ramiro were discussing the two flavours of TELNET "server" and not RLOGIN. Let's see how we can deal with this problem of two "server" programs competing to use the same port number. First we'll examine what happens in the "server" when it has managed to work out what port number it is going to use. The port number is stored in a structure (control block). There are two other fields in this structure that need to be "filled in". One is the addressing/protocol family, essentially identifying IP, and the other is an IP address - more later. The "server" program has already obtained a socket, a reference number for calls to the underlying IP transport logic which is tied to a transport service, "stream" (TCP) or "datagram" (UDP) (or "raw" meaning bypass TCP or UDP). The socket, the internal number, is now to be associated with a port number, a number visible externally. The association is achieved using a bind() call. The bind() call references the structure mentioned above. Because the structure has an IP address field we are obliged to provide an IP address. You might think that the significance of the port number and the IP address in the structure is that. once the "binding" has occurred, IP packets which specify that port and IP address in the destination fields of the IP header will be passed to the "server" program's "input" calls, such as recv(). This is true in the case of the port number but the requirement on the IP address is described differently. The requirement is that the IP packet *must* have actually *arrived* at the node on the interface with the specified IP address.[3] (It's important, yet again, to reflect that an IP address does *not* identify an IP node but only (one of) the interface(s) connecting that node to some part of the IP network.) But what if we want the "server" program to provide its service to *all* arriving IP packets no matter on which interface they happened to arrive - as we normally would? The answer is to use a special "all zeros" IP address, called, using the C #define name, INADDR_ANY. In effect, INADDR_ANY is IP address 0.0.0.0. With the INADDR_ANY address, the test for the arriving interface is bypassed. It is no surprise then to discover that "server" programs will, unless there are some very special and obscure reasons to do otherwise, specify INADDR_ANY as the IP address in that structure used for the bind() call. In case there are some very special and obscure reasons requiring the specification of a specific IP address, a "server" program *may* provide a parameter which allows the IP address to be specified - just as it probably has for the port number. However, providing for the specification of an IP address parameter is very unlikely and such a parameter will generally not be available. So now we have a port number representing the "service" to be offered and we specify INADDR_ANY as the IP address. How does this help use with our objective which is - in case this description has been so fascinating you have forgotten what the objective is - "How we can deal with the problem of two "server" programs competing to use the same port number?" With an APAR[4] to OS/390 V2R8 CS IP, a function called "Server Bind Control" was introduced. This APAR makes a BIND parameter available for PORT statement entries. With this BIND parameter, in case the "server" program does not allow the specification of an IP address as a parameter, the IP address in that structure can be specified as other than INADDR_ANY. Recall that, in the PORT statement entry, the identification of the "server" program is by means of the so-called "job name" although it is very often a started task procedure name. But you've just explained why specifying a specific IP address is a bad idea - I hear you say - so why go to all this trouble in order of compensate for the lack of a parameter for the IP address in the "server" program? Well, I'm glad you asked that question, The reason is that you can specify a "virtual IP address" (VIPA) in the PORT statement entry BIND parameter. Yes - you say - in a tone which implies the question "How does this help?" Well, if the "client" of the "server" specifies the VIPA (directly or indirectly by means of name servers) as the destination IP address, the IP packet is considered to have come from the virtual interface identified by the VIPA. Now we can be thankful for VIPAs which have the property not to tie an IP address to an interface but to tie an IP address to an IP node or, even better as in fact here, to tie an IP address to a particular application on an IP node. In fact, using VIPAs we no longer need a port number in order to locate a "server" application. This, however, is not possible because the underlying IP demultiplexing logic insists on processing a port number. Because we can use an IP address, specifically a VIPA, in order to identify a "server" application, we also have the possibility to associate a name for use in a name server which can map a VIPA directly to an application and not, as was strictly what logically we did before VIPAs came to our rescue, to an interface to an IP node. So much better oriented to the needs of "clients" that they should use a name which corresponds to the "server" application they want to use rather than to use the name of this obscure entity, at least as far as the "client" end-users are concerned, an "interface name". What is that when it's at home? you can hear them enquire. In case you didn't notice it, what we have now done is resolve the problem of using port 23 for two different types of TELNET service. Now we can use two application names, tn3270.my.hosts.name.com and otelnet.my.hosts.name.com, mapping to VIPAs in order to access either of the TELNET applications and, for both applications, use port 23. Something I skipped above might now be worth mentioning. In order to become a "server", a TCP program has to use the listen() call. This call is made after the bind() call and it changes the status of the socket from "active" to "passive". Once the socket is, as it is said, "listening", connection requests from a "client" will be queued pending an accept() call for that connection being made by the "server" program. Using the appropriate NETSTAT command all "listening" sockets can be listed. Conceptually, an UDP socket can be considered to be "listening" simply if it has an "input" request outstanding and an UDP socket can also be shown as a "listening" socket. The "listening" list shows both the port number and the IP address which may have been set using the PORT statement entry BIND parameter. With the PORT statement BIND parameter and VIPAs either - There is absolutely no need to have our poor befuddled end users use strange port numbers in order to access their beloved TELNET when accessing these excessively user-unfriendly mainframes! or - There is absolutely no need to have our poor befuddled end users change the port number they have grown accustomed to use in order to access their old 3270 applications just because, as they hear, a new set of users has come along who insist that port 23 belongs to them! and that has been the situation for more than 6 years.[4] Section 1.4.2, "Port assignments" in z/OS V1R8.0 Communications Server IP Configuration Reference is the "official" explanation of this topic. There is also a description of "Bind Server Control" in http://www-03.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130026.pdf which, because this is already rather a long post, I may as well insert the relevant section here and avoid you having to download the ",pdf" file. <quote> 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, both of which accept requests to any IP address (binding to INADDR_ANY in socket terms), and 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 only returns 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, since 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 desired 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 different source address than was specified on the corresponding previous request goes away, because the socket is bound solely to the designated address. The specified address may 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, since the PORT statement differentiates between the two. </quote> Finally, I should say I am grateful to Shmuel for pointing out that, just because the TELNET service you are using is the TN3270 "server" you are not forced into using TSO. You could log onto CICS or NetView or a session manager program. And, indeed - one of Shmuel's favourite topics - USS in this context could refer to VTAM's Unformatted System Services rather than UNIX System Services to which is what RLOGIND provides access. Shmuel's point is that it is possible so to configure the TN3270 "server" that it uses a load module created by assembling and linkage editing VTAM-supplied Unformatted System Services macros and thereby gives something of the same end-user experience for control of application establishment (and a rather poorer version of, typically emergency, application termination) as is available when the end-user device is under direct VTAM control. I'm afraid Shmuel's post is just designed to confuse you. However I suspect that, very strictly, he is right. If you use this URL http://www-03.ibm.com/servers/eserver/zseries/zose/bkserv/zeshelves8.html go right to the bottom, select "Search text" under "z/OS V1R8.0 UNIX System Services - 11 books" and enter "USS", you will find the character string in only 4 of the 11 manuals and the total number of hits is 11. These are made up of parameters or program names or text in comments where perhaps the guard of the author was down and he/she had forgotten that he/she should not use USS. There is also a slipup in 3 messages. So few hits in the set of 11 manuals indicates strongly that the standard was *not* to use the abbreviation "USS" for Unix System Services. [1] Port 25 is normally associated with the Simple Mail Transfer Program (SMTP). [2] The combination of port 513 and UDP corresponds to a "who" protocol service. [3] I was sure that was what I remembered but I started to have doubts so I checked. The reference is section 3.1.9.2, "bind()", in the z/OS V1R7.0-V1R8.0 Communications Server IP Sockets API Guide and Reference manual, specifically the following sentence: <quote> By leaving the address unspecified, the server can accept all UDP packets and TCP connection requests made of its port, regardless of the network interface on which the requests arrived. </quote> Nevertheless I wonder whether or not the original author of the text in the bind() call description has got it wrong and I have been deceived by this text for the last 15 or so years. Simply matching the port and IP address in the IP packet header with the bind structure values seems so much simpler than bothering about the interface on which the packet happened to arrive. A description on these lines fits so much more easily with the use of VIPAs. I hope someone who really knows has had the patience still to be reading this post. [4] APAR PQ37421 http://www-1.ibm.com/support/docview.wss?uid=isg1PQ37421 <quote> Error Description NEW FUNCTION This APAR will provide new function which will allow multiple dissimilar servers to use the same TCP port.For instance, both TN3270 telnet and Unix telnet can use port 23. Closed date 2000-04-26 </quote> Chris Mason ----- Original Message ----- From: "Lindy Mayfield" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Thursday, 02 November, 2006 9:43 PM Subject: Re: Java Error > Correct me, please, if I am wrong, but if you telnet to port 25 you get to TSO, but if you rlogin to port 513 you get to USS. No? > > Lindy ----- Original Message ----- From: "Mark Zelden" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Thursday, 02 November, 2006 9:55 PM Subject: Re: Java Error > 23 is TSO (usually) and whatever you want for z/OS Unix. I have used > 623 most of the time but that has varried at different shops I have > been at. I've also been at a shop that set up 23 for Unix and > something else for TSO. And then there is sercure telnet... but > I digress.... > > So if I wanted to use win-doze my telnet client to IP into z/OS Unix, > I do this from a command prompt: > > telnet host_name 623 > > Mark > -- > Mark Zelden ----- Original Message ----- From: "Ramiro Camposagrado" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Thursday, 02 November, 2006 10:03 PM Subject: Re: Java Error > I use 23 for "standard telnet" and port 623 for my RLOGINs (OTELNET) > Here are the entries in /etc/services: > > telnet 23/tcp > otelnet 623/tcp ---------------------------------------------------------------------- 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
