Janus Telnet Server

Janus Telnet support allows you to set up one or more Telnet servers within a Model 204 Online. JANUS commands are used to define and start a TCP/IP for each Janus Telnet Server. The Janus Telnet Server supports only the tn3270 subset of the Telnet protocol. That is, it will only serve clients that provide 3270 emulation via Telnet. Janus Telnet servers can be accessed with Telnet, or more specifically a tn3270 client of your choice, to gain 3270 access to Model 204. A tn3270 client will typically be running on an end-user's workstation.

Nowadays, almost all access to mainframe applications is via tn3270. Typically, clients connect to a tn3270 server provided by the TCP/IP stack for the operating system. While most of these stacks are now provided by IBM, there are still a few third-party stacks available, most of which provide their own Telnet servers. For Model 204 access, most tn3270 clients first connect to a service such as VTAM or CMS, which then provides access to Model 204.

Using the Janus Telnet Server has some advantages over using the Telnet server provided by the TCP/IP stack:

• It eliminates the extra layer between TCP/IP and Model 204 — either VTAM or CMS. This reduces complexity and, possibly, CPU overhead. For end-users, the extra step of connecting to Model 204 after connecting to VTAM or logging on to CMS is eliminated — the user is connected directly to Model 204.
• It makes it much easier to determine the IP address of a 3270 user. When tn3270 access is via VTAM, Model 204 only sees the VTAM LU of the terminal. Mapping this to an IP address can be difficult. Maintaining a fixed IP address to LU name mapping in TCP/IP makes this more feasible, but it is a maintenance headache.
• It reduces the number of thread types required in an Online. Since Telnet Server threads run in daemon threads, no special 3270 threads are required for 3270 access. In fact, since CMS and TSO both provide tn3270 clients, no special thread type is required for full screen access from CMS or TSO, either.
• The configuration of a Janus Telnet Server is simpler and more dynamic than the Telnet server provided by the TCP/IP stack. Janus Telnet Server ports can be started and stopped at will with the JANUS START and JANUS FORCE commands. In addition, the simple JANUS DEFINE command structure makes it easy to set things like BINDADDR or TCPKEEPALIVE that are difficult, if not impossible, to set via the TCP/IP stack Telnet server.
• For Janus Network Security customers, the Janus Telnet Server can be trivially configured to use SSL.
• The Janus tracing facilities may be used to trace 3270 datastreams. While obviously a somewhat esoteric capability, it can be quite useful on occasion. When tracing 3270 datastreams using JANUS TRACE, one should be aware that the 3270 datastreams are wrapped in Telnet/tn3270 datastreams, so they will contain extra "stuff." The Telnet layer is described by RFC 854, and tn3270 is described by RFC 1576.

These are disadvantages of using a Janus Telnet Server:

• The Janus Telnet Server currently provides no facility comparable to the VTAM transfer facility available for VTAM terminals.
• If display of data in SirScan is limited by IODEV type (that is, IODEV15), the display will also pick up Janus Telnet Server connections, which might not be desirable. Of course, this is easily corrected by specifying JAN: followed by the port name, instead of using IODEV15 to limit SirScan display. For example, JAN:WEB would limit display to connections on port WEB.

Note: To use Janus Telnet Server, you must have licensed Janus TCP/IP Base and Janus Sockets.

Configuring a Janus Telnet Server

These are the configuaration steps:

1. Set User 0 parameters:
   • Even though Janus Telnet Server runs full screen requests on daemon threads (IODEV number set by the SDAEMDEV system parameter), Model 204 typically considers an IODEV's type to be either line-mode or full-screen. So the daemon threads that run Telnet requests will dynamically switch to a different IODEV number while there is a connection. Like SDAEMDEV, you must indicate in the User 0 CCAIN parameters the IODEV number to be used for Telnet requests. The TNDEV parameter indicates the Telnet IODEV number. Since IODEV 21 is currently unused, add TNDEV=21 to the User 0 parameters to enable Telnet support.
   • If you want support for arbitrary-geometry Telnet clients, specify SIRTERM=1 in the User 0 parameters, if SIRTERM is not already set there.
2. Using a JANUS DEFINE command, define a Janus port that will provide Telnet service: The following is a typical command for a Telnet server port:

   JANUS DEFINE TNSERV 777 TNSERV 10 WSFQUERY

   • Specifying the WSFQUERY parameter is recommended to provide support for non-standard terminal screen geometries. A JANUS START for the port will then start the port and make direct Telnet access to Model 204 available.
   • As with any other port type, if a port number below 1024 is to be used, the port might need to be reserved for the Online in the TCP/IP configuration. The standard port number for Telnet is 23. This port number will almost certainly be in-use on any mainframe on which Model 204 will be running. On a multi-homed mainframe, however, it might be possible to use port 23 on a specific host IP address for Janus. The BINDADDR parameter is required to provide service on a specific IP address:

     JANUS DEFINE TNSERV 23 TNSERV 10 WSFQUERY BINDADDR 198.242.244.13

   • TCPKEEPALIVE is an additional JANUS DEFINE parameter worth setting in your TNSERV port definition, since this port is likely to be held open for relatively long periods of time.
   • AUTOSYS is a JANUS DEFINE parameter you can use in your TNSERV port definition to specify a subsystem to be invoked after a login on the Telnet Server.

See also

• Janus Sockets User Language coding considerations
• Sample Janus Sockets programs
• Socket-level interfaces:
  • $functions
  • Socket class
• Higher-level interfaces:
  • Email class
  • HTTP Helper classes
  • LDAP class
  • Janus FTP Server
  • Janus Telnet Server