How To
Summary
Before the Internet Protocol's rise in popularity, large organizations established their own Systems Network Architecture (SNA®) networks. These SNA® networks were used to communicate between remote users and the centralized mainframe. The display management protocol used to facilitate this communication within an SNA® environment was called the 3270 data stream. At the user's, location in an SNA® network was a device referred to as a 3270 terminal. Supporting these networks was the Virtual Telecommunications Access Method (VTAM®) which is still in use today. A 3270 terminal was a non-programmable (sometimes called "dumb") workstation. The basic display screen was capable of 24 rows of text by 80 columns also came with a keyboard attached. There were also displays capable of various combinations of columns and rows as well as color displays. The display unit was attached to a control unit via coaxial cable. The character set of these display systems is the EBCDIC character set rather than the ASCII set.
As the world went to TCPIP-based networks, a need to continue communicating to large-scale systems emerged. TN3270E provides end-to-end 3270 data stream emulation capability. It is the client’s responsibility to perform any necessary conversion between ASCII and EBCDIC character sets.
Objective
Environment
The original basic telnet protocol was defined in RFC (Request for Comments) 854. This RFC effectively defined all that was needed to support the 3270 data stream, since the 3270 data stream is just part of the telnet data payload.
In other words, the 3270 portions were implemented outside of (above) the telnet protocol. Specific options could be negotiated (beyond basic telnet) that uses the telnet option standard of RFC 855. Option negotiation in turn allowed for device type negotiations (later formally defined in RFC 1091) to be completed as part of the telnet session setup.
Initially, there was no formal standard for TN3270 (the E came along later), but it was clarified in an early RFC titled "TN3270 Current Practices" (RFC 1576). TN3270 itself took shape more formally with RFCs 1646 and 1647. RFC 1647 was a significant RFC because it was the first formalization of the TN3270 Enhanced protocol, known as TN3270E.
TN3270E improved upon the TN3270 protocol to include control of LU name selection, as well as full support of Attention Identifier such as SYSREQ (to talk directly to VTAM) and the attention key.
LU stands for logical unit. An LU is the SNA entity that represents an endpoint of communication for a session. For example, an LU can represent an application endpoint (for example, TSO® on the mainframe) or a user endpoint (a user at a workstation). The user endpoint LU is referred to as the terminal LU.
In addition, if an SNA application wants to send data to a printer, forms a session between the application and an LU that represents the printer.
TN3270E is a VTAM® application and requires that VTAM® be available to carry internal communications traffic. It also implies that all of the standard support definitions are in place to define the remote user LU, including, log modes and VTAM® LU definitions.
TN3270E allows the terminal session LU to identify implicitly the printer session LU that should be used. This is done by using the ASSOCIATE command during the TN3270E printer connection setup. If an ASSOCIATE command is sent, then the TN3270E server selects a printer LU based on the terminal LU to which the client is already connected. Obviously, the TN3270E server must be set up with a one-to-one mapping of terminal LUs-to-printer LUs.
TN3270E description
A TN3270E client uses the TN3270E protocol to access the resources on a TN3270E server. However, the TN3270E client cannot complete the connection all the way to the target application because the TN3270E client communicates according to the TN3270E protocol, while the target application expects communication to be SNA protocol.
Often, the term TN3270 is used synonymously with TN3270E, since from a user perspective it can be difficult to tell the difference. However most TN3270 clients, run TN3270E, even though users might think they are using the TN3270 protocol. TN3270E is defined in RFC 2355.
Additional TN3270E functions supported in z/OS
z/OS ® Communications Server supports Transport Layer Security (TLS), multiple ports, and mapping an IP address to an LU name (IP filtering). While TLS is supported in the profile, AT-TLS is the preferred security method.
Application Transparent Transport Layer Security (AT-TLS)
z/OS ® Communications Server supports AT-TLS (and its older sibling, Secure Sockets Layer, SSL). TLS provides secure data transmission between the TN3270E Server and a TLS-capable client. In a TLS session, any data on a secure port is protected by using one of several optional cipher suites. Note that since TN3270E protocol ends at the TN3270E server, data traveling over the SNA session is not protected. Native or application-specific TLS is supported by definitions in the TN3270 profile but AT-TLS is preferred. Client authentication and SAF level checks are supported.
SUPPORT FOR MULTIPLE PORTS
The TN3270E server can listen on multiple ports. In addition, more than one instance of the TN3270E server can run concurrently. Finally, within a single TN3270E server, or among separate TN3270E servers, listening can be controlled so that it is only active on one specific IP address. Through these functions you can define different security levels (basic or secure) or different configuration parameters, or both, for each port and IP address combination.
Mapping an IP Adress to an LU name (IP Filtering)
This function provides the ability to select both an LU name and an application name for incoming TN3270E sessions. The selection is made by a specific IP address, a group of IP addresses, a subnet, or the link name used to connect to the z/OS host. The function makes the LU name and the application name predictable and controllable.
In addition, z/OS ® Communications Server supports selections based on an IP host name or group of names, as well as an IP address. With the increasing use of dynamic IP (a given client is not tied to a specific IP address), it is beneficial in maintaining control over the mapping. More detail on this in a following section
TN3270E printing
The TN3270E server has more than just 3270 terminal display capabilities. It can also support the SNA print data stream. Substituting "printer LU" for "terminal LU" through some SNA session-initiation differences, a print data stream can be emulated by the TN3270E server.
This means that an SNA application can direct a print data stream to an SNA printer LU as it always has. If that printer LU is a TN3270E-owned printer LU, then the TN3270E server accepts the print data stream from the application and forwards it to the TN3270E client running on the workstation. The workstation can then print the data using normal workstation printer facilities.
Steps
z/OS ® Communications Server Parameters for TN3270E
Telnet configuration statements are processed during the initialization of the TN3270E Telnet server or when you issue the VARY TCPIP,tnproc,OBEYFILE command to update the Telnet configuration data set. (For information about using the VARY TCPIP,tnproc,OBEYFILE command to update the Telnet configuration data set, see Using the VARY TCPIP,tnproc,OBEYFILE command to update Telnet configuration). The Telnet configuration statements enable the following definition and session setup:
- Define Telnet server characteristics
- Define connection characteristics
- Define LU names to represent Telnet clients
- Facilitate session setup with MVS® host VTAM® applications
The sample profile in SEZAINST(TNPROF) contains additional statements that are included as comments. These statements provide examples of advanced functions. Many of these statements are installation-specific; modify these statements to suit a specific installation.
Sample TN3270 configuration
; TN3270 Server Profile for stand-alone Task =======
; SSL security. No Sysplex Distribution in the stack. –
; TELNETGLOBALS TCPIPJOBNAME TCPIPB
; -------------------------------------------------------------------- ; These default device type settings will be used by all ports if no ; TELNETPARMS or PARMSGROUP is used to override the settings.
; They are logmode names shipped in ISTINCDT with the latest level of ; VTAM.
; --------------------------------------------------------------------
TELNETDEVICE IBM-3277 SNX32702,SNX32702
TELNETDEVICE IBM-3278-2-E SNX32702,SNX32702
TELNETDEVICE IBM-3278-2 SNX32702,SNX32702
TELNETDEVICE IBM-3279-2-E SNX32702,SNX32702
TELNETDEVICE IBM-3279-2 SNX32702,SNX32702
TELNETDEVICE IBM-3278-3-E SNX32703,SNX32703
TELNETDEVICE IBM-3278-3 SNX32703,SNX32703
TELNETDEVICE IBM-3279-3-E SNX32703,SNX32703
TELNETDEVICE IBM-3279-3 SNX32703,SNX32703
TELNETDEVICE IBM-3278-4-E SNX32704,SNX32704
TELNETDEVICE IBM-3278-4 SNX32704,SNX32704
TELNETDEVICE IBM-3279-4-E SNX32704,SNX32704
TELNETDEVICE IBM-3279-4 SNX32704,SNX32704
TELNETDEVICE IBM-3278-5-E SNX32705,SNX32705
TELNETDEVICE IBM-3278-5 SNX32705,SNX32705
TELNETDEVICE IBM-3279-5-E SNX32705,SNX32705
TELNETDEVICE IBM-3279-5 SNX32705,SNX32705
;
ENDTELNETGLOBALS
;
TELNETPARMS
PORT 23
INACTIVE 0
TIMEMARK 600
SCANINTERVAL 120
FULLDATATRACE
SMFINIT 0 SMFINIT NOTYPE119
SMFTERM 0 SMFTERM TYPE119
SNAEXT
MSG07
LUSESSIONPEND
ENDTELNETPARMS
;
BEGINVTAM
PORT 23
DEFAULTLUS SC30BB01..SC30BB99
ENDDEFAULTLUS
DEFAULTAPPL TSO ; All users go to TSO
ALLOWAPPL SC30N* ; ALLOWAPPL NVAS* QSESSION
; session mngr queues back upon CLSDST
ALLOWAPPL TSO* DISCONNECTABLE ; Allow all users access to TSO ALLOWAPPL * ; Allow all applications that have not been
; previously specified to be accessed.
ENDVTAM
;
TELNETPARMS
SECUREPORT 992 ;Port 992 will support SSL KEY RING HFS
; /etc/sc30b.key ring.kdb
;key ring used by all secure
INACTIVE 0
TIMEMARK 600
SCANINTERVAL 120
FULLDATATRACE
SMFINIT 0 SMFINIT NOTYPE119
SMFTERM 0 SMFTERM TYPE119 SNAEXT
MSG07
ENDTELNETPARMS
;
BEGINVTAM
PORT 992
DEFAULTLUS SC30BS01..SC30BS99
ENDDEFAULTLUS
;
; --------------------------------------------------------------------; This NOSSL group is mapped to use no SSL security.
; NOLUSESSIONPEND = Terminate connection upon a logoff
; --------------------------------------------------------------------PARMSGROUP NOSSL
NOLUSESSIONPEND
CONNTYPE BASIC ; support non-secure, overrides telnetparms
ENDPARMSGROUP
;
; --------------------------------------------------------------------; The SSLPLAIN group is mapped to use SSL security
; with no Client Authentication required
; LUSESSIONPEND = Force a requeue back to the UNIX System Services table upon logoff
; --------------------------------------------------------------------
PARMSGROUP SSLPLAIN
LUSESSIONPEND
CONNTYPE SECURE ; plain SSL, no client auth req’d
ENDPARMSGROUP ; and negotiate all available encryption algorithms
; --------------------------------------------------------------------; The SSLCERTS group is mapped to use SSL security
; and to require Client Authentication (certificates)
; NOLUSESSIONPEND = Terminate connection upon a logoff from the appl ; --------------------------------------------------------------------PARMSGROUP SSLCERTS
NOLUSESSIONPEND
CONNTYPE SECURE ; Support SSL CLIENTAUTH SSLCERT
; Client Certificate required
ENCRYPT SSL_DES_SHA ; use these only, do not consider any others SSL_3DES_SHA
ENDENCRYPT
ENDPARMSGROUP
;
DESTIPGROUP GENERALUSER 10.20.10.21 ENDDESTIPGROUP
DESTIPGROUP ADMIN 10.20.10.22 ENDDESTIPGROUP
DESTIPGROUP PAYROLL 10.20.10.23 ENDDESTIPGROUP
DESTIPGROUP SHIPPING 10.20.1.230 ENDDESTIPGROUP
DESTIPGROUP ANY1ELSE 255.0.0.0:10.0.0.0 ENDDESTIPGROUP
;
PARMSMAP NOSSL DESTIPGRP,GENERALUSER
DEFAULTAPPL TSO DESTIPGRP,GENERALUSER
;
PARMSMAP SSLPLAIN DESTIPGRP,ADMIN
USSTCP USSTEST1 DESTIPGRP,ADMIN
;
PARMSMAP SSLCERTS DESTIPGRP,PAYROLL DEFAULTAPPL CICSCLP0 DESTIPGRP,PAYROLL
;
PARMSMAP NOSSL DESTIPGRP,ANY1ELSE
;
;------------------------------------------------------------------
; There is no DEFAULTAPPL nor USSTCB coded as a default catch all
; So, if any user connects using any other IP address than the
; four defined by the DESTIPGROUPs above, the Network Solicitor
; prompt panel will be displayed to that user.
;------------------------------------------------------------------ ALLOWAPPL SC30N* ;
ALLOWAPPL NVAS* QSESSION ; session mngr queues back upon CLSDST ALLOWAPPL TSO* DISCONNECTABLE ; Allow all users access to TSO ALLOWAPPL * ; Allow all applications that have not been
; previously specified to be accessed.
ENDVTAM
STARTING THE TN3270 SERVER
The following sample JCL can be used as a guide to start the TN3270 Server:
/TN3270B PROC PARMS='TRC=TN',
// PROFILE=TELNB&SYSCLONE.,TCPDATA=DATAB&SYSCLONE.
//*
//* TRC=TN indicates to use CTRACE(CTIEZBTN) PARMLIB control mem
//*
//TN3270B EXEC PGM=EZBTNINI,REGION=0M,PARM='&PARMS'
//STEPLIB DD DISP=SHR,DSN=SYS1.LOCAL.VTAMLIB
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //PROFILE DD DISP=SHR,DSN=TCPIPB.TCPPARMS(&PROFILE.)
//SYSTCPD DD DISP=SHR,DSN=TCPIPB.TCPPARMS(&TCPDATA.)
From the system console, the command: S TCPIPB,PROFILE=PROFB30A would be issued to start this server.
LU MAPPING
Processing the connection between a 3270 VTAM® session and telnet session requires a number of events to occur. The processing can be described thus:
TN3270 connections perform complete lookup only after all information is known. LU lookup is not done during connection negotiation. Telnet will either send a solicitor (or USSMSG10) screen to the client or will perform complete lookup using the application name known through the LUMAP-DEFAPPL or DEFAULTAPPL statement as defined in the TN3270 parms. If complete lookup is successful, Telnet will begin session initiation. If not successful, the solicitor (or USSMSG07) screen is sent to the client without an LU being assigned to the connection or the connection is dropped. The LU is not assigned until the application name is valid. If the application name is a RESTRICTAPPL, the LU is not assigned until a user ID is specified. Application-based LU mappings have a very good chance of success due to the late LU mapping aspect of TN3270 connections. When SIMCLIENTLU is coded, Generic TN3270E connections have this same characteristic.
complete lookup: An application name is required for complete lookup. The application name is obtained from one of three sources in the order specified:
- Input from the USER or VTAM® (CLSDST with OPTCD=PASS)
- DEFAPPL parameter on the LUMAP statement
- DEFAULTAPPL statement
Use the application name to perform complete lookup. Possible lookup results are:
- The application is not valid
- The application is valid but an LU is not found
- The application is valid (return code OK) and an LU is found
- The application LU map does not match the Client Identifier LU map
If the application is not valid, no LU is assigned to the connection and an error message is sent to the client. If the application is valid, continue the LU lookup in the following order:
- Check for LUMAP matches considering application-based LU lookup results
- Only Generic LUMAPs are searched
- If the application lookup return code is OK, then perform LU lookup
- If no LUMAP statements were used, check for application-based LU mappings. If the application lookup return code is OK and LUs are defined on the application statement, perform LU lookup
- If no LUMAP or application-based LU mapping statements were used, use the DEFAULTLUS pool considering application lookup results. If the application lookup return code is OK, then perform LU lookup
Note: see the sample Telnet parameters to see how the DEFAULTLUS pool is constructed.
TN3270E LU Coordination in a Sysplex
SNA architecture requires every LU in a VTAM® network to have a unique name. Multiple Telnet servers create added administrative effort to ensure that LU names are unique among the servers. In an environment using multiple Telnet servers running on a single system or in a sysplex, one Telnet server can be designated to be the LU name server (LUNS). The LUNS manages LU name assignments from LU groups among the group of Telnet servers, each known as an LU name requester (LUNR).
Shared LU groups are defined at each LUNR and sent to the LUNS. Shared LU group definitions can be the same or different at each LUNR. The LUNS allocates an LU name to a particular LUNR only if that LUNR defined the LU in a shared LU group. The LUNS manages LU names by ensuring that only one LUNR at a time is using a particular LU name. Load balancing is used to distribute Telnet client connections across several LUNR Telnet servers that have identical shared LU name configurations.
A single Telnet server can support both shared and unshared LU groups. Existing unshared LU group definitions continue to be managed at the local Telnet level.
A Telnet server can be configured to be only a LUNS, or a Telnet server can be a LUNS and also function as a regular Telnet server. Running Telnet as only a LUNS in its own address space has the following advantages:
- Telnet port server functions will not compete with the LUNS for resources within the address space.
- Telnet roles can be separated, which makes problem diagnosis easier
- The Telnet LUNS can be stopped and restarted without stopping the Telnet ports
- Telnet port servers can be stopped and restarted without stopping the Telnet LUNS
- The Telnet LUNS priority can be set to a different priority than that of Telnet port servers
Telnet uses XCF local group services to define the set of Telnet servers that participate in a shared LU name management group. By specifying or omitting the XCFGROUP block determines the level of participation of a particular Telnet server with shared LU name management.
Additional Information
TN3270E CLIENTS
A Mac or PC uses the Internet to communicate with the mainframe host. The Internet Engineering Task Force (IETF) defines this special version of the Telnet protocol, called Telnet 3270, or TN3270E for short (RFC's 1041, 1576, 1646, 1647, 2355, 2561, 2562, 3049). TN3270E is an enhanced version of TN3270. Any method used to connect the PC to the Internet may thus be used to access mainframe hosts/servers also connected to the Internet. There are several ways that the terminal emulation software can be implemented.
-
- The 3270 terminal emulation software can be a separate PC or Mac application
- The 3270 terminal emulation software can be a "plug-in" to a standard web browser
- This has the advantage that the emulation software can be automatically installed into the browser under the control of the server
IBM® has a TN3270E browser plug-in called Host-On-Demand (HOD) ®. IBM's® stand-alone access software is called IBM Personal Communications (PCOM) ®. There are many third-party sources for 3270 emulation software. Prices range from $25 to $250. Trial downloads and shareware are common to provide a low or no cost solution. Support for the "IND$FILE" feature is a desirable function and is implemented in many of the solutions (but not all). This facilitates transferring source code and data files between the Mac or PC and the mainframe. The ability to emulate a 3287 printer can also be a useful feature.
There are also a number of open source options available. There is a combination of x3270 (a Linux-based terminal emulator), and Cygwin (a .dll file and related software, which create a "substantial" Linux API within the Microsoft Windows environment) or Cygwin/X (Cygwin + XFree86 X Window v11 (also known as X11R6)).
Other commercial sources:
- Rocket Software’s Rocket Terminal Emulator (Formerly Rocket BlueZone)
- MochaSoft provides Telnet 3270 terminal emulation
- Tom Brennan Software Vista tn3270 for Windows
Related Information
Document Location
Worldwide
Product Synonym
IBM Z;Communications Server;Telnet;TN3270
Was this topic helpful?
Document Information
Modified date:
10 August 2022
UID
ibm16453635