Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.1 - Configuring the TN3270 Server

Table Of Contents

Configuring the TN3270 Server

Overview of the TN3270 Server

Benefits of Using the Latest Release of the TN3270 Server

TN3270 Server Environments

SNA Functions

Telnet Server Functions

TN3270 Server Architecture

Supported PU Types

Direct PUs

DLUR PUs

Supported LU Types

LU Names in the TN3270 Server

LU Allocation

Formation of LU Model Type and Number

Static LU Allocation

Dynamic LU Allocation

LU Nailing

LU Pooling and ASSOCIATE Requests

Pooled LU Allocation

Session Termination

LU Termination

LU Deletion

Session Termination Scenarios

Response-Time Collection

Sliding-Window Average Response Times

Response-Time Buckets

Preparing to Configure the TN3270 Server

Hardware and Software Requirements

Router Requirements

Mainframe Requirements

TN3270 Client Requirements

Design Considerations

Handling Large Configurations

Configuring Host Connections

VTAM Host Configuration Considerations

TN3270 Server Configuration Modes

TN3270 Server Configuration Mode

Listen-Point Configuration Mode

Listen-Point PU Configuration Mode

DLUR Configuration Mode

DLUR PU Configuration Mode

DLUR SAP Configuration Mode

Response-Time Configuration Mode

PU Configuration Mode

Moving Between Configuration Modes

Configuring the TN3270 Server

Configuring TN3270 Siftdown Commands

Configuring the TN3270 Server Options

Configuring a Generic Pool of LUs

Configuring Idle-Time

Configuring IP Precedence

Configuring IP TOS

Configuring Keepalive

Configuring LU Allocation and LU Nailing

Configuring LU Deletion

Configuring LU Termination

Configuring the Maximum Number of Sessions Supported by the Server

Configuring the Maximum Number of Sessions That Can be Obtained by a Single Client

Configuring the TCP Port

Configuring Timing Marks

Configuring the Unbind Action

Configuring the TN3270 Server with LU Pooling

Guidelines for Configuring LU Pooling

Task List for TN3270 Server Configuration with LU Pooling in an APPN Environment Using DLUR

Configuring the TN3270 Server and Defining a Pool

Configuring DLUR

Configuring SAPs Under DLUR

Configuring a Listen Point and Nailing Clients to Pools

Configuring a Listen-Point PU to Define DLUR PUs and Allocate LUs

Task List for TN3270 Server Configuration with LU Pooling in a Non-APPN Environment

Configuring the TN3270 Server and Defining a Pool

Configuring a Listen Point and Nailing Clients to Pools

Configuring a Listen-Point PU to Define Direct PUs and Allocate LUs

Migrating from Legacy TN3270 Server Configuration Methods

Methods of Configuring Direct PUs

Methods of Configuring DLUR PUs

Methods of LU Nailing

Verifying the TN3270 Server Configuration

Configuring the TN3270 Server for Response-Time Monitoring

Verifying Response-Time Configuration

Monitoring and Maintaining the TN3270 Server

Managing DLUR Links

Converting a Dynamic Link to a Static Link

Removing a Dynamic Link

Shutting Down the TN3270 Server and TN3270 Server Entities

Configuration Examples

Basic Configuration Example

Listen-Point Direct PU Configuration Example

Listen-Point DLUR PU Configuration Example

LU Pooling Configuration Example

TN3270 Server Configuration Without LU Pooling Example

TN3270 DLUR Configuration with CMPC Host Connection Example

Removing LU Nailing Definitions Example

TN3270 Server DLUR Using CMPC Example

Configuring the TN3270 Server

The implementation of TN3270 Server on a channel-attached router using the CIP or CPA provides an effective method of removing the processing of TN3270 sessions from valuable mainframe cycles to a faster and more efficient router. This chapter provides information about configuring TN3270 Server support on the CIP and CPA types of CMCC adapters on a Cisco router.

This information is described in the following sections:

•Overview of the TN3270 Server

•Preparing to Configure the TN3270 Server

•Configuring the TN3270 Server

•Configuring the TN3270 Server for Response-Time Monitoring

•Monitoring and Maintaining the TN3270 Server

•Configuration Examples

For general information about configuring CMCC adapters, refer to the "Configuring Cisco Mainframe Channel Connection Adapters" chapter in this publication.

For a complete description of the TN3270 server commands in this chapter, refer to the "TN3270 Server Commands" chapter of the Cisco IOS Bridging and IBM Networking Command Reference, Volume II. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Overview of the TN3270 Server

This section provides a brief introduction to the environments where the TN3270 server feature is used and describes some of the primary benefits and functions of the TN3270 server.

The following sections in this topic provide background information about the TN3270 Server:

•Benefits of Using the Latest Release of the TN3270 Server

•TN3270 Server Environments

•TN3270 Server Architecture

•Supported PU Types

•Supported LU Types

•LU Allocation

•Session Termination

•Response-Time Collection

Additional details about the TN3270 Server implementation can be found in the TN3270 Design and Implementation Guide available on CCO.

Benefits of Using the Latest Release of the TN3270 Server

The latest release of the TN3270 Server feature on the CMCC implements RFC 2355, TN3270 Enhancements and RFC 2562, Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB).

The TN3270 server provides the following benefits:

•Supports clients using the ASSOCIATE request.

•Maintains knowledge of printer and terminal relationships when an association is defined between LU resources.

•Enables clients to acquire a terminal LU and its associated printer without desktop configuration to specific LUs by grouping LUs in clusters.

•Enables you to capture response-time statistics for individual sessions and clients or for groups of sessions and clients.

•Supports specification of LU names for dynamic definition of dependent LUs (DDDLUs).

•Controls how keepalives are generated and keepalive responses are handled by the CMCC adapter.

•Prevents VTAM security problems when the UNBIND request is used with CICS.

•Supports deletion of LUs automatically on session termination.

TN3270 Server Environments

TN3270 communications in a TCP/IP network consist of the following basic elements:

•TN3270 client—Emulates a 3270 display device for communication with a mainframe application through a TN3270 server over an IP network. The client can support the standard TN3270 functions (as defined by RFC 1576) or the enhanced functionality provided by TN3270E (defined in RFC 2355). TN3270 clients are available on a variety of operating system platforms.

•TN3270 server—Converts the client TN3270 data stream to SNA 3270 and transfers the data to and from the mainframe.

•Mainframe—Provides the application for the TN3270 client and communicates with the TN3270 server using Virtual Telecommunications Access Method (VTAM).

The TN3270 server feature offers an attractive solution when the following conditions need to be supported in an SNA environment:

•Maintaining an IP backbone while providing support for SNA 3270-type clients.

•Offloading mainframe CPU cycles when using a TN3270 host TCP/IP stack with a TN3270 server.

•Providing support for high session density or high transactions per second.

The TN3270 server feature on a CMCC adapter card provides mapping between an SNA 3270 host and a TN3270 client connected to a TCP/IP network as shown in Figure 294. Functionally, it is useful to view the TN3270 server from two different perspectives:

•SNA Functions

•Telnet Server Functions

Figure 294 TN3270 Implementation

SNA Functions

From the perspective of an SNA 3270 host connected to the CMCC adapter, the TN3270 server is an SNA device that supports multiple PUs, with each PU supporting up to 255 logical units (LUs). The LU can be Type 1, 2, or 3. The SNA host is unaware of the existence of the TCP/IP extension on the implementation of these LUs.

The LUs implemented by the TN3270 server are dependent LUs. To route these dependent LU sessions to multiple VTAM hosts connected to the TN3270 server in the CMCC adapter card, rather than routing in the VTAM hosts, the TN3270 server implements a SNA session switch with end node (EN) dependent LU requester (DLUR) function. SNA session switching allows you to eliminate SNA subarea routing between hosts of TN3270 traffic by establishing Advanced Peer-to-Peer Networking (APPN) links with the primary LU hosts directly.

Using the DLUR function is optional so that the TN3270 server can be used with VTAM versions prior to version 4.2, which provide no APPN support. In these non-APPN environments, access to multiple hosts is accomplished using direct PU configuration in the TN3270 server.

Telnet Server Functions

From the perspective of a TN3270 client, the TN3270 server is a high-performance Telnet server that supports Telnet connections, negotiation and data format. The server on the CMCC adapter card supports Telnet connection negotiation and data format as specified in RFC 1576 (referred to as Traditional TN3270) and RFC 2355 (referred to as TN3270 Enhancements).

Unless the TN3270 server uses a Token Ring connection to a front-end processor (FEP), or other LLC connectivity to the mainframe host, it will require CSNA or CMPC support. For more information about configuring CSNA or CMPC support, see the "Configuring CSNA and CMPC" chapter in this publication.

TN3270 Server Architecture

The Cisco TN3270 server can be placed on a channel-attached router or a remote router. If the router is directly connected to the host, the TN3270 server resides on a CIP or CPA that is connected to the mainframe using Enterprise Systems Connection (ESCON) or bus-and-tag channel attachment.

Alternatively, you can use the TN3270 server on a remote router as an intermediate step toward using the CIP or CPA as a direct host connection. In this case, the TN3270 server resides on a router that is connected to the mainframe using a channel connection device, such as the FEP or a CIP or CPA.

The TN3270 server feature is implemented on the following CMCC adapters:

•CIP—Installed in a Cisco 7000 with RSP7000 or 7500 series router. Each CIP has up to two ESCON or two bus-and-tag (parallel) interfaces and a single virtual interface. The TN3270 server is installed on the virtual interface. Therefore, each CIP can have a single TN3270 server.

•CPA—ECPA or PCPA installed in a Cisco 7200 series router. Each CPA combines the function of an ESCON interface and a virtual interface on a single interface. As with the CIP, a single TN3270 server can be installed on each CPA.

Because a router can accommodate more than one CIP or CPA, each router can support multiple TN3270 servers.

Supported PU Types

The TN3270 server supports two types of PUs:

•Direct PUs—Used in subarea SNA

•DLUR PUs—Used with APPN

Direct PUs and DLUR PUs can coexist on the same CIP or CPA. Both types of PUs support either static or dynamic LUs. However, the LU type is defined only in VTAM and is not explicitly defined in the TN3270 server.

Direct PUs

The TN3270 server supports direct PUs when you want to configure a PU entity that has a direct link to a host. Direct PUs are used in non-APPN environments.

The definition of each direct PU within the router requires that you define a local service access point (SAP). Each PU on the TN3270 server must have a unique local/remote media access control (MAC)/SAP quadruple. If you want to connect PUs on the same adapter to the same remote MAC (RMAC) and remote SAP (RSAP), then you must configure each PU with a different link SAP (LSAP).

With direct PUs, the LU names in the TN3270 server do not necessarily match the LU names defined in VTAM. However, there are a couple of ways to accomplish matching LU names for direct PUs:

•LU seed configuration—To ensure that the LU seed configurations in the router and VTAM match for direct PUs, you need to define the value for the lu-seed parameter in the pu (TN3270) or pu (listen-point) command in the router, the same as the LUSEED value in the VTAM PU definition.

•INCLUD0E function available as of VTAM version 4.4—To allow the XCA to provide the LU name in the ACTLU message, use the INCLUD0E function. The TN3270 server then uses the LU name provided by the ACTLU.

DLUR PUs

When the SNA network uses APPN and the TN3270 server can reach multiple hosts, the DLUR function of the TN3270 server is recommended. Note that by using the DLUR function of the TN3270 server, all of the LUs in the server can be defined and owned by a controlling VTAM. When a client requests an application residing on a different VTAM host, the controlling VTAM will issue the request to the target host which will send a BIND directly to the client. All LU-LU data will then flow directly between the target host and the client without needing to go through the controlling VTAM.

DLUR allows the routing of TN3270 LUs to be performed in the CMCC adapter card using SNA session switching to multiple VTAM hosts rather than routing the sessions on the VTAM hosts. This feature is especially important with the multi-CPU CMOS mainframe, which comprises up to 16 CPUs that appear as separate VTAMs.

The implementation of TN3270 server LUs under DLUR also allows the server to learn about the LU names from VTAM in the ACTLU message, which greatly simplifies the configuration to support specifically requestable LUs such as printers.

Supported LU Types

The TN3270 server supports two types of LUs:

•Static LUs—Defined explicitly within VTAM. Allocation of static LUs requires a client to specify the PU and LU name. LU name requests are only supported by TN3270E clients.

•Dynamic LUs—Use the DDDLU feature of VTAM. Allocation of dynamic LUs requires a client to specify only a terminal type. LU name requests to be fulfilled by DDDLUs for PUs configured with the generic-pool deny command are supported.

The type of LU that is allocated is defined only in the VTAM switched major node. The TN3270 server does not specify the LU type.

LU Names in the TN3270 Server

Where SNA session switching is configured using DLUR PUs, the TN3270 server learns the LU names (static or dynamic) from VTAM in the ACTLU message. Direct PUs can also learn names from VTAM in the ACTLU message if the INCLUD0E parameter (available in VTAM version 4.4) is used in the switched major node definition.

However, for direct PUs, the TN3270 server can also specify a naming convention that it will use for any dynamic LUs that are allocated. For direct PUs a "seed" name can be configured on the PU in the TN3270 server configuration by using the lu-seed argument of the pu (TN3270) or pu (listen-point) command. The LU seed name defines a prefix for the LU name. The TN3270 server uses the LU seed name in conjunction with the LOCADDR to generate the name by which the TN3270 server recognizes that LU. It is important to note that VTAM also generates LU names using its own LUSEED parameter.

When using the lu-seed parameter in the TN3270 server configuration, it is best to use the same naming convention as the host to prevent situations where the LU name that the TN3270 server recognizes differs from the corresponding LU name assigned in VTAM.

Several factors determine how LUs are assigned and named. For more information about the different factors that influence LU naming, see the TN3270 Design and Implementation Guide available on CCO.

LU Allocation

This section provides information about the following aspects of LU allocation:

•Formation of LU Model Type and Number

•Static LU Allocation

•Dynamic LU Allocation

•LU Nailing

•LU Pooling and ASSOCIATE Requests

•Pooled LU Allocation

Formation of LU Model Type and Number

VTAM requires a model type and number in the Reply PSID NMVT from the TN3270 server to find an appropriate LU template in the LUGROUP major node. The model type is a four character string and the model number is a two or three character string.

The TN3270 server translates the following formats of terminal type string from a client:

•IBM-<XXXX>-<Y>[-E]: Specifies "XXXX0Y"or "XXXX0YE" in the model type and number field of the Reply PSID NMVT.

Note The "E" in the model string refers to 3270 Extended Datastream. It has no association with the "E" in "TN3270E."

•IBM-DYNAMIC: Specifies "DYNAMIC" in the model type and number field of the Reply PSID NMVT. The VTAM configuration also must have "DYNAMIC" defined as a template in the LUGROUP.

All other terminal strings that do not match the above syntax examples are forwarded as is to VTAM. For example, a string of "IBM-ZZ..Z," where "ZZ..Z" does not match the preceding syntax, is forwarded as "ZZ..Z."

In all cases, the string is translated from ASCII to EBCDIC and truncated at seven characters.

Clients that do not support TN3270E typically require a 3270 datastream on the System Services Control Point (SSCP)-LU flow. Clients that are TN3270E compliant typically use the SNA Character Set (SCS) on the SSCP-LU session. In order to accommodate these two classes of clients, the TN3270 server directs them to different LUGROUP entries at the host. To make this as easy as possible, the SCS requirement is also encoded into the model string sent to the host. Following the previously described terminal type string formats accepted by the server, this additional condition is applied:

If the client has negotiated TN3270E support, the character "S" is overlaid on the fifth character of the string, or appended if the string is less than five characters as shown in Table 17.

Table 17 Examples of Model String Mapping

String from Client (ASCII)

BIND-IMAGE Requested?

String to Host (EBCDIC)

IBM-3278-4

No

327804

IBM-3279-5E

No

327905E

IBM-3279-3-E

Yes

3279S5E

IBM-DYNAMIC

Yes

DYNASIC

ABC

Yes

ABCS

ABCDEFGH

Yes

ABCDSFG

Static LU Allocation

A TN3270E client can request a specific LU name by using the TN3270E command CONNECT as documented in RFC 2355. The name requested must match the name by which the TN3270 server knows the LU and the host must have activated the LU with an ACTLU.

TN3270 clients can also use static LUs if client nailing is configured on the TN3270 server.

Dynamic LU Allocation

Dynamic LU allocation, using VTAM's DDDLU feature, is the most common form of request from TN3270 clients emulating a TN3270 terminal. The user typically requests connection as a particular terminal type and normally is not interested in what LOCADDR or LU name is allocated by the host, as long as a network solicitor logon menu is presented. In fact, only TN3270E clients can request specific LUs by name.

The TN3270 server performs the following functions with this type of session request:

•Forms an EBCDIC string based on the model type and number requested by the client (see "Formation of LU Model Type and Number" on the algorithm used). This string is used as a field in a Reply product set ID (PSID) network management vector transport (NMVT).

•Allocates a LOCADDR from the next available LU in the generic LU pool. This LOCADDR is used in the NMVT.

•Sends the formatted Reply PSID NMVT to VTAM.

To support DDDLU, the PUs used by the TN3270 server have to be defined in VTAM with LUSEED and LUGROUP parameters. When VTAM receives the NMVT it uses the EBCDIC model type and number string to look up an LU template under the LUGROUP. For example, the string "327802E" finds a match in the sample VTAM configuration shown in Figure 298 in the "VTAM Host Configuration Considerations" section. An ACTLU is sent and a terminal session with the model and type requested by the client is established.

LU name requests to be fulfilled by DDDLUs for PUs configured with the generic-pool deny command are supported.

For more information about defining the LUSEED and LUGROUP parameters in VTAM, see the "VTAM Host Configuration Considerations" section.

LU Nailing

The TN3270 server allows a client IP address to be mapped or "nailed" to one or more LU local addresses on one or more physical units (PUs) by means of router configuration commands. LU nailing allows you to control the relationship between the TN3270 client and the LU.

Using LU nailing, clients from traditional TN3270 (non-TN3270E) devices can connect to specific LUs, which overcomes a limitation of TN3270 devices that cannot specify a "CONNECT LU." LU nailing is useful for TN3270E clients because it provides central control of your configuration at the router rather than at the client.

The "model matching" feature of Cisco's TN3270 server is designed for efficient use of dynamic LUs. Each TN3270E client specifies a terminal model type at connection. When a non-nailed client connects and does not request a specific LU, the LU allocation algorithm attempts to allocate an LU that operated with that terminal model the last time it was used. If no such model is available, the next choice is an LU that has not been used since the PU was last activated. Failing that, any available LU is used; however, for dynamic LUs only, there is a short delay in connecting the session.

When a client or set of clients is nailed to a set of more than one LU, the same logic applies. If the configured LU nailing maps a screen client to a set of LUs, the LU nailing algorithm attempts to match the client to a previously used LU that was most recently used with the same terminal model type as requested by the client for this connection. If a match is found, then that LU is used. If a match is not found, any LU in the set that is not currently in use is chosen. If there is no available LU in the set, the connection is rejected.

For example, the following LUs are nailed to clients at address 192.195.80.40, and LUs BAGE1004 and BAGE1005, which were connected but are now disconnected.
lu    name   client-ip:tcp       nail state    model   frames in out    idle for
1   BAGE1001 192.195.80.40:3822   Y   P-BIND   327904E  4       4       0:22:35
2   BAGE1002 192.195.80.40:3867   Y   ACT/SESS 327904E  8       7       0:21:20
3   BAGE1003 192.195.80.40:3981   Y   ACT/SESS 327803E  13      14      0:10:13
4   BAGE1004 192.195.80.40:3991   Y   ACT/NA   327803E  8       9       0:0:7
5   BAGE1005 192.195.80.40:3997   Y   ACT/NA   327805   8       9       0:7:8
If a client at IP address 192.195.80.40 requests a terminal model of type IBM-3278-5, LU BAGE1005 will be selected over BAGE1004.
lu    name   client-ip:tcp       nail state    model   frames in out    idle for
1   BAGE1001 192.195.80.40:3822   Y   P-BIND   327904E  4       4       0:23:29
2   BAGE1002 192.195.80.40:3867   Y   ACT/SESS 327904E  8       7       0:22:14
3   BAGE1003 192.195.80.40:3981   Y   ACT/SESS 327803E  13      14      0:11:7
4   BAGE1004 192.195.80.40:3991   Y   ACT/NA   327803E  8       9       0:1:1
5   BAGE1005 192.195.80.40:4052   Y   ACT/SESS 327805   13      14      0:0:16
LU Pooling and ASSOCIATE Requests

The TN3270 server enhancements introduced in Cisco IOS Release 12.0(5)T add support for the ASSOCIATE request through LU pooling. The LU pooling feature enables the TN3270 server to identify the relationships between screen and printer LUs.

The LU pool configuration is an option to the LU nailing feature that allows clients to be nailed to LUs. The LU pooling feature allows you to configure clients in the router and nail clients into groups of LUs. These groups of LUs are called clusters. Each cluster is given a unique pool name. An LU pool consists of one or more LU clusters that are related to each other. This allows logically related clients to connect to LUs that have the same logical relationship with the host. A cluster can contain screen LUs and their associated printer LUs. The pool name can be used instead of a device name on a CONNECT request. LU nailing is supported for LU pools.

The pool name can be used instead of a device name on a CONNECT request. The pool name must be eight characters or less in length and must comply with VTAM naming rules, which allow the following characters (alphabetic characters are not case sensitive):

•1st character—Alphabetic (A-Z) and national characters `@', `#', and `$'

•2nd-8th characters—Alphabetic (A-Z), numeric (0-9), and national characters `@', `#', and `$'

These naming rules are enforced by the TN3270 server when configuring a pool name and when processing the name received on a CONNECT request from the client. The TN3270 server rejects an invalid name and truncates the name received in the CONNECT request from the client to eight characters or at an invalid character (whichever comes first) when processing the CONNECT request.

Figure 295 provides an overview of clusters configured within PUs.

Figure 295 LU Pooling

Support for the ASSOCIATE request enables you to define a partner printer in the TN3270 server for a given terminal LU pool or single terminal. As a result, the TN3270 server maintains a knowledge of printer and terminal relationships. The client does not need to know the LU name of the partner printer in advance. Typically, a client can request a pool name, a specific LU, or a resource without citing a pool name or LU name.

If the client sends an ASSOCIATE request for a resource name to the TN3270 server, the server provides the client with a resource LU name.

In Figure 296, the client requests an LU from unixpool and is granted an LU from the specified pool. The client then initiates a new process by requesting the printer device associated with the given resource LU name.

The client requests a printer LU associated with termabc and the server grants the printer LU associated with termabc. Based on the configuration in the router that specifies the clusters of printer and screen LUs for pools, the TN3270 server assigns and allows the client to use the printer LU associated with its terminal LU.

Figure 296 Client Request for LU from a Specific Pool and Printer LU Association

Figure 297 shows the client request for a specific LU termxyz and then a request for a printer LU associated with the LU termxyz. The TN3270 server grants the screen LU and connects the printer associated with termxyz.

Figure 297 Client Request for a Specific LU and Printer LU Association

Pooled LU Allocation

When configured, the pool becomes one of several criteria used by the TN3270 server to assign an LU to a client. When a client requests a connection, the TN3270 server determines the authorized capabilities of the client. For example, the TN3270 server attempts to determine whether LU nailing definitions exist for the client.

When the client criteria is processed, the TN3270 server assigns the first available LU in the group to the client. If an appropriate LU is not found, the TN3270 connection is closed.

Screen and printer LUs for a cluster in a pool are allocated according to the following connection scenarios in the TN3270 server:

•The first client with an IP address that is nailed to a pool connects to the TN3270 server—A cluster is reserved for that client IP address. The first appropriate LU in the cluster that satisfies the client connection request is assigned.

•A client, with the same nailed IP address as a currently connected client, connects to the TN3270 server.

–Depending on the type of LU requested by the client (screen or printer LU), the first available screen or printer LU within a cluster that is reserved for that nailed IP address is allocated.

–If there is not an available screen or printer LU in an assigned cluster for the client connection, a new cluster is reserved for clients with that IP address. Then, the first appropriate LU in the cluster that satisfies the client connection request is assigned.

•A client, with a new IP address that is nailed to the same pool as other clients, connects to the TN3270 server—The next available cluster is reserved for that client IP address.

•A client requests a specific pool when connecting to the TN3270 server, but the client IP address is not nailed to the pool—The first available LU in the generic pool is allocated to the client.

For a detailed example of these LU allocation scenarios for a TN3270 server configuration using LU pooling, see the "LU Pooling Configuration Example" section.

Session Termination

The TN3270 server supports two configuration options that determine how the server responds when a client turns off the device or disconnects:

•LU Termination

•LU Deletion

LU Termination

In Cisco IOS Release 12.0(5)T and later, the TN3270 server supports LU termination options for sending either an UNBIND or a TERMSELF RU when a client turns off the device or disconnects from the server.

The termself keyword for the lu termination command orders termination of all sessions and session requests associated with an LU when a user turns off the device or disconnects from the server. This is an important feature for applications such as IBM's Customer Information Control System (CICS).

If you use an UNBIND request for session termination with CICS, Virtual Telecommunication Access Method (VTAM) security problems can arise. When CICS terminates a session from an UNBIND request, the application may reestablish a previous user's session with a new user, who is now assigned to the same freed LU.

LU Deletion

In Cisco IOS Release 12.0(5)T and later, the TN3270 server adds support for LU deletion options.

The lu deletion command specifies whether the TN3270 server sends a REPLY-PSID poweroff request to VTAM when a client disconnects. This command is recommended in host environments running VTAM version 4.4.1. Previous versions of VTAM are not compatible with Network Management Vector Transport (NMVT) REPLY-PSID.

Session Termination Scenarios

Sessions are terminated in the following conditions:

•The client logs off the LU-LU session and the LU is configured to disconnect on UNBIND.

•The client disconnects at the TCP layer.

•The client is idle too long or will not respond to a DO TIMING MARK message.

Any of the above conditions cause the server to do one of the following, depending upon how the lu termination command is configured:

•Unbind is configured—The TN3270 server sends an UNBIND followed by a NOTIFY (Secondary LU (SLU) DISABLED) message to the host. If the lu deletion command is configured to send a REPLY-PSID poweroff request, then the TN3270 server sends the request upon receipt of the NOTIFY response from the host.

•Termself is configured—The TN3270 server sends a NOTIFY (SLU DISABLED) to the host. Upon receipt of the NOTIFY response from the host, the TN3270 server sends a TERMSELF request to the host. If the lu deletion command is configured to send a REPLY-PSID poweroff request, then the TN3270 server sends the request upon receipt of the TERMSELF response.

Response-Time Collection

Response-time MIB support enables you to capture response-time statistics on the router for either individual sessions and clients or for groups of sessions and clients.

If SNMP is enabled on the router, a network management system (NMS) or users can use well-known and router-configured client group names to obtain response-time statistics. Response-time data collection is always enabled for all in-session clients, excluding printer clients. Table 17 shows the types of client groups that are monitored:

Table 18 Client Group Types and Names

Client Group Type

Description

Client Group Name

Client Subnet

All clients belonging to one or more IP subnets, where the IP subnets and client group name are configured on the router.

User defined

Other

All clients not belonging to an IP subnet configured for a Client Subnet-type group.

CLIENT SUBNET OTHER

Global

All in-session clients.

CLIENT GLOBAL

Application

All clients in session with a specific VTAM APPL ID.

APPL VTAM-application-name

Host Link

All clients using a specific host link in use by a PU configured on the router.

DIRECT LINK pu-name

DLUR LINK link-name

Listening Point

All clients connected to a specific listening point configured on the router.

LP ip-address: tcp-port

The names and IP subnets for the "client subnet" type of response-time group are user-defined. All other client groups are established dynamically by the TN3270 server as clients enter and exit applications. These client groups are named according to the format shown in the column labeled Client Group Name in Table 17.

In Cisco IOS Release 12.1, traps are not generated by the MIB.

Response-time data is collected using the following methods:

•Sliding-Window Average Response Times

•Response-Time Buckets

Sliding-Window Average Response Times

The sliding-window response-time method uses a moving average. It reflects the most recent response time and discounts the old response times. When there is no activity, this method preserves the old response times. The algorithm used for the sliding-window method is similar to the moving-average method. For detailed information about sliding-window average times, refer to the TN3270E-RT-MIB.

Response-Time Buckets

Response-time buckets contain counts of transactions with total response times that fall into a set of specified ranges. Response-time data gathered into a set of five buckets is suitable for verifying service-level agreements or for identifying performance problems through a network management application. The total response times collected in the buckets is governed by whether IP network transit times are included in the totals.

In Figure 298, four bucket boundaries are specified for a response-time collection, which results in five buckets.

Figure 298 Response-Time Boundaries

The first response-time bucket counts transactions with total response times that are less than or equal to boundary 1 (B-1), the second bucket counts transactions with response times greater than B-1 but less than or equal to B-2, and so on. The fifth bucket is unbounded, and it counts all transactions with response times greater than boundary 4.

The four bucket boundaries have default values of 1 second, 2 seconds, 5 seconds, and 10 seconds, respectively.

For a detailed explanation of response-time buckets, refer to the TN3270E-RT-MIB.

Preparing to Configure the TN3270 Server

Read the following sections to find important information that is useful to know before you configure the TN3270 server:

•Hardware and Software Requirements

•Design Considerations

•Configuring Host Connections

•VTAM Host Configuration Considerations

•TN3270 Server Configuration Modes

Hardware and Software Requirements

This section provides the following information about the hardware and software required to use the TN3270 server:

•Router Requirements

•Mainframe Requirements

•TN3270 Client Requirements

Router Requirements

Note To enable the TN3270 server feature, you must have a CMCC adapter installed in a Cisco 7000 with RSP7000, Cisco 7200 series router, or a Cisco 7500 series router. The TN3270 server is very different from the TN3270 terminal emulation access feature described in the "Configuring Dial-In Terminal Services" chapter of the Cisco IOS Dial Services Configuration Guide:Terminal Services.

The Cisco TN3270 server consists of a system image and a microcode image, which are virtually bundled as one combined image. The following versions of hardware microcode are supported for the CIP and CPA in Cisco IOS Release 12.1:

•CIP hardware microcode—CIP27-2 and later.

•CPA hardware microcode—XCPA27-2 and later.

For additional information about what is supported in the various releases of the Cisco IOS software and the CIP microcode, see the information on CCO.

Mainframe Requirements

Mainframe hosts using SNA with the TN3270 server must be running VTAM V4R2 or later.

Note You can use VTAM V3R4, but DLUR operation is not supported in V3R4 and proper DDDLU operation may require program temporary fixes (PTFs) to be applied to VTAM.

TN3270 Client Requirements

Based on the RFC standards, the Cisco TN3270 server supports any client that implements the TN3270 or TN3270E protocols.

Design Considerations

The number of sessions that a single TN3270 server can handle is directly related to the number of transactions per second and the amount of memory available to the CIP or CPA. There are other issues to be considered depending upon the environment that you want to support with the TN3270 server.

For comprehensive information about VTAM and router configuration issues and implementing specific TN3270 server scenarios, refer to the TN3270 Design and Implementation Guide.

Handling Large Configurations

The maximum size nonvolatile random-access memory (NVRAM) for the Cisco 7000, Cisco 7200, and Cisco 7500 series routers is 128 KB. The maximum number of nailing commands (commands that map IP addresses to LUs) that can be stored in a 128 KB NVRAM is approximately 4000. However, large configurations may contain as many as 10,000 nailing commands.

To maintain a configuration file that exceeds 128 KB there are two alternatives:

•Store the configuration file compressed in NVRAM.

•Store the configuration file in Flash memory (either internal Flash or on a PCMCIA card).

For more information about maintaining configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide. For information about router hardware and memory, refer to the hardware configuration guide for your Cisco router series.

Configuring Host Connections

Before configuring the TN3270 server, host connectivity must be configured using one of the following methods:

•Configuring CMPC support

•Configuring CSNA support

•Configuring Token Ring attachment to an FEP

For information about configuring CMPC or CSNA, see the "Configuring CSNA and CMPC" chapter in this publication.

VTAM Host Configuration Considerations

Other non-Cisco implementations of TN3270 support depend on predefined, static pools of LUs to support different terminal types requested by the TN3270 clients. The Cisco TN3270 server implementation on the CMCC adapter removes the static nature of these configurations by using a VTAM release 3.4 feature called DDDLU. DDDLU dynamically requests LUs using the terminal type provided by TN3270 clients. The dynamic request eliminates the need to define any LU configuration in the server to support TN3270 clients emulating a generic TN3270 terminal.

To support DDDLU, the PUs used by the TN3270 server have to be defined in VTAM with LUSEED and LUGROUP parameters as shown in Figure 299.
Figure 299 VTAM Host Values Defining LUSEED and LUGROUP
Example VTAM host values defining LUSEED and LUGROUP name parameters:
TN3270PU
PU
.
IDBLK=05D,
IDNUM=30001,
*
Defines other PU parameters
LUSEED=TN3X1###,
*
Defines the seed component of 
the LU names created by DDDLU 
(e.g. LOCADDR 42 will have the 
name TN3X1042)
LUGROUP=AGROUP
*
Defines the LU group name
*
TN3X1100 
LU
LOCADDR=100,
MODETAB=AMODETAB
*
Defines a terminal which 
requires a specific LU name
*
TN3X1101
LU
LOCADDR=101,
DLOGMODE=M3287CS
*
Defines a printer which requires 
a specific LU name
Example VTAM host values defining LUGROUPname, AGROUP:
AGROUP
LUGROUP
*
Defines LU group to support 
various terminal types
327802E
LU
USSTAB=USSXXX,
LOGAPPL=TPXP001,
DLOGMOD=SNX32702,
SSCPFM=USS3270
*
Defines template to support IBM 
3278 terminal model 2 with 
Extended Data Stream. Note that 
the USS messages in USSXXX 
should be in 3270 datastream.
3278S2E
LU
USSTAB=USSYYY,
LOGAPPL=TPXP001,
DLOGMOD=SNX32702,
SSCPFM=USSSCS
*
Defines template to support IBM 
3278 terminal model 2 with 
Extended Data Stream, for 
TN3270E clients requesting 
BIND-IMAGE.
327805
LU
USSTAB=USSXXX,
LOGAPPL=TPXP001,
DLOGMOD=D4C32785,
SSCPFM=USS3270
*
Defines template to support IBM 
3279 terminal model 5
@
LU
USSTAB=USSXXX,
LOGAPPL=TPXP001,
DLOGMOD=D4A32772,
SSCPFM=USS3270
Defines the default template to 
match any other terminal types
With the configuration shown in Figure 298 defined in the host, the ACTPU sent by VTAM for the PU TN3270PU will have the "Unsolicited NMVT Support" set in the SSCP capabilities control vector. This allows the PU to dynamically allocate LUs by sending network management vector transport (NMVT) with a "Reply Product Set ID" control vector.

After the TN3270 server sends a positive response to the ACTPU, it will wait for VTAM to send ACTLUs for all specifically defined LUs. In the sample configuration shown in Figure 298, ACTLUs will be sent for TN3X1100 and TN3X1101. The server sends a positive response and sets SLU DISABLED. The LOCADDRs of the TN3X1100 and TN3X1101 LUs are put into the specific LU cache and reserved for specific LU name requests only.

To allow sufficient time for the VTAM host to send all the ACTLUs, a 30-second timer is started and restarted when an ACTLU is received. When the timer expires it is assumed that all ACTLUs defined in VTAM for the PU have been sent. All LUs that have not been activated are available in a generic LU pool to be used for DDDLU unless they have been reserved by the configuration using the generic-pool deny TN3270 configuration command.

After the VTAM activation, the server can support session requests from clients using dynamic or specific LU allocation.

For more information about DDDLU in VTAM, refer to the VTAM operating system manuals for your host system under the descriptions for LUGROUP.

Note If your host computer is customized for a character set other than U.S. English EBCDIC, you might need to code some VTAM configuration tables differently than indicated in the examples provided by Cisco.

Some VTAM configurations include the number sign (#) and at symbol (@). In the U.S. English EBCDIC character set, these characters are stored as the hexadecimal values 7B and 7C, respectively. VTAM will look for those hexadecimal values when processing the configuration file.

The characters used to enter these values are different in other EBCDIC National Language character sets. Table 19 lists the languages that have different characters for the 7B and 7C hexadecimal values and the corresponding symbols used to enter the characters.

For example, the value for the LUSEED parameter in the PU definition called TN3270PU in Figure 299 has a value of TN3X1###. To properly code this value for LUSEED for the French National Language character set, the value should be TN3X1£££.

Table 19 International Character Sets for Hexadecimal Values

Hexadecimal Value

7B

7C

Language

Symbol

Description

Symbol

Description

German

#

Number sign

§

Section symbol

German (alternate)

Ä

A-dieresis

Ö

O-dieresis

Belgian

#

Number sign

à

a-grave

Brazilian

Õ

O-tilde

Ã

A-tilde

Danish/Norwegian

Æ

AE-ligature

Ø

O-slash

English (U.S./UK)

#

Number sign

@

At symbol

Finnish/Swedish

Ä

A-dieresis

Ö

O-dieresis

French

£

Pound sterling

à

a-grave

Greek

£

Pound sterling

§

Section symbol

Icelandic

#

Number sign

D

Uppercase eth

Italian

£

Pound sterling

§

Section symbol

Portuguese

Õ

O-tilde

Ã

A-tilde

Spanish

Ñ

N-tilde

@

At symbol

Turkish

Ö

O-dieresis

S

S-cedilla

TN3270 Server Configuration Modes

Figure 300 shows the TN3270 configuration modes that are supported in Cisco IOS Release 12.1 and which are described in the following sections of this topic:

•TN3270 Server Configuration Mode

•Listen-Point Configuration Mode

•Listen-Point PU Configuration Mode

•DLUR Configuration Mode

•DLUR PU Configuration Mode

•DLUR SAP Configuration Mode

•Response-Time Configuration Mode

•PU Configuration Mode

The TN3270 server can be configured only on the virtual interface of a CMCC adapter. Some configuration commands create entities on the CMCC adapter. For most of these commands, the command changes to the mode associated with that entity (for example, a PU).

When preparing to configure the TN3270 server it is important to understand how to access and move between these different configuration modes. See the "Moving Between Configuration Modes" section for more information.

Figure 300 TN3270 Configuration Modes

Note The DLUR, DLUR SAP, DLUR PU and PU configuration modes existed in Cisco IOS Release 12.0(5)T and earlier. DLUR PU and PU configuration modes (shown in the shaded boxes) are legacy configuration modes, whose functions can be replaced by the listen-point configuration modes in Cisco IOS Release 12.0(5)T and later. For more information about the relationship of these legacy configuration modes to the new listen-point configuration modes, see the "Migrating from Legacy TN3270 Server Configuration Methods" section.

TN3270 Server Configuration Mode

From interface configuration mode, the following tn3270-server command puts you in TN3270 server configuration mode:
router(config-if)# tn3270-server
The following prompt appears:
(cfg-tn3270)#
Note For the CIP, enter interface configuration mode from the virtual channel interface using port 2; For the CPA, enter interface configuration mode from the physical channel interface using port 0.

Listen-Point Configuration Mode

From the TN3270 server configuration mode, the following listen-point command puts you in listen-point configuration mode:
router(cfg-tn3270)# listen-point ip-address [tcp-port [number]]
The following prompt appears:
(tn3270-lpoint)#
Listen-Point PU Configuration Mode

From the listen-point configuration mode, you can create direct PUs and DLUR PUs:

•From the listen-point configuration mode, the following pu (listen-point) command creates a new direct PU:
router#(tn3270-lpoint)# pu pu-name idblk-idnum type adapno lsap [rmac rmac] [rsap 
rsap] [lu-seed lu-name-stem]
The pu (listen-point) command puts you in listen-point PU configuration mode and the following prompt appears:
(tn3270-lpoint-pu)#
•From listen-point configuration mode, the following pu dlur command creates a new PU for DLUR:
router#(tn3270-lpoint)# pu pu-name idblk-idnum dlur
The pu dlur command puts you in the listen-point PU configuration mode and the following prompt appears:
(tn3270-lpoint-pu)#
DLUR Configuration Mode

From TN3270 server configuration mode, the following dlur command puts you in DLUR configuration mode:
router(cfg-tn3270)# dlur fq-cpname fq-dlusname
The following prompt appears:
(tn3270-dlur)#
DLUR PU Configuration Mode

Note DLUR PU configuration mode is a legacy configuration mode whose function to define DLUR PUs can be replaced by using the listen-point configuration modes in Cisco IOS Release 12.0(5)T and later. When you define listen-point configurations, you can create DLUR PUs within listen-point PU configuration mode using the pu dlur command instead.

From DLUR configuration mode, the following pu (DLUR) command creates a new PU for DLUR:
router(tn3270-dlur)# pu pu-name idblk-idnum ip-address
The pu (DLUR) command puts you in the DLUR PU configuration mode and the following prompt appears:
(tn3270-dlur-pu)#
DLUR SAP Configuration Mode

From DLUR server configuration mode, the following lsap command puts you in DLUR SAP configuration mode:
router(tn3270-dlur)# lsap type adapno [lsap]
The following prompt appears:
(tn3270-dlur-lsap)#
Response-Time Configuration Mode

From the TN3270 server configuration mode, the following response-time group command puts you in response-time configuration mode:
router(cfg-tn3270)# response-time group name [bucket boundaries t1 t2 t3 
t4...][multiplier m]
The following prompt appears:
(tn3270-resp-time)#
PU Configuration Mode

Note PU configuration mode is a legacy configuration mode whose function to define direct PUs can be replaced by using the listen-point configuration modes in Cisco IOS
Release 12.0(5)T and later. When you define listen-point configurations, you can create direct PUs within listen-point PU configuration mode using the pu (listen-point) command instead.

From the TN3270 server configuration mode, the following pu (TN3270) command creates a new direct PU:
router(cfg-tn3270)# pu pu-name idblk-idnum ip-address type adapno lsap [rmac rmac] 
[rsap rsap] [lu-seed lu-name-stem]
The pu (TN3270) command puts you in PU configuration mode and the following prompt appears:
(tn3270-pu)#
Moving Between Configuration Modes

In general, the parameters within a configuration mode can be grouped into two categories:

•Parameters to identify the specific instance of the entity (for example, a PU name).

•Parameters to set operating options.

To return to a mode later in the configuration process, use the same configuration command but specify only the first set of identification parameters. The following examples show how to create, access, and remove different TN3270 entities in their associated configuration modes.

Working with a Listen-Point Direct PU

The following example shows how to create, access, and remove a listen-point PU entity:

1. To create a listen-point direct PU entity called PU1 and enter listen-point PU configuration mode from listen-point configuration mode, use the pu (listen-point) command as shown in the following example:
router(tn3270-lpoint)# pu PU1 94201231 tok 1 10
2. To return later to the listen-point PU configuration mode for the PU1 entity, use the same pu (listen-point) command without the "94201231 tok 1 10" parameters from listen-point configuration mode:
router(tn3270-lpoint)# pu PU1
3. To remove the listen-point PU entity called PU1, use the same command with the no keyword:
router(tn3270-lpoint)# no pu PU1
Working with a Listen-Point DLUR PU

The following example shows how to create, access, and remove a listen-point DLUR PU entity:

1. To create a listen-point DLUR PU entity called PU2 and enter listen-point PU configuration mode from listen-point configuration mode, use the pu dlur command as shown in the following example:
router(tn3270-lpoint)# pu PU2 017ABCDE dlur
2. To return later to the listen-point PU configuration mode for the PU2 entity, use the same pu dlur command without the "017ABCDE dlur" parameters from listen-point configuration mode:
router(tn3270-lpoint)# pu PU2
3. To remove the listen-point PU entity called PU2, use the same command with the no keyword:
router(tn3270-lpoint)# no pu PU2
 
Working with a DLUR Entity

The following example shows how to create, access, and remove a DLUR entity:

1. To create a DLUR entity with a control point name NETA.RTR1 and enter DLUR configuration mode from TN3270 configuration mode, use the dlur command as shown in the following example:
router(cfg-tn3270)# dlur NETA.RTR1 NETA.HOST
2. To return later to the DLUR configuration mode for the NETA.RTR1 entity, use the same dlur command without the "NETA.RTR1 and NETA.HOST" parameters from TN3270 configuration mode:
router(cfg-tn3270)# dlur