Guest

IBM Presentation Services

TN3270 Server

Downloads

Table Of Contents

Q & A

Features and Functions

Secure Sockets Layer Support

Inverse Domain Name System Nailing

Server Defined Definition of Dynamic Dependent LUs

SNA Session Switching

Tuning

LU Nailing

Server Redundancy

Recovery

Accounting

Printing

Server Algorithms

Network Management

Diagnostics

Competitive Positioning

Positioning the Cisco TN3270 Server versus NCIA


Q & A


TN3270 Server

Features and Functions

Secure Sockets Layer Support

Q. What is Secure Sockets Layer?

A. Secure Sockets Layer (SSL) is a transport-layer security feature that provides data privacy (through encryption), data integrity (through one-way hashes), and authentication (through digital certificates). It is based on an implementation by Netscape that was originally used for Secure HTML (SHTML). SSL provides secure TN3270 transmission over private or public networks. It is characterized by a minimum amount of configuration at the client end.

Q. When was SSL support added to TN3270 Server?

A. SSL support was added in Cisco IOS® Release 12.1(5)T and later.

Q. Does TN3270 Server support host-side digital certificates?

A. Yes.

Q. Does TN3270 Server support client-side digital certificates?

A. Partially. It supports the negotiation of an SSL session that requires digital certificates. This means that the TN3270E client can request that TN3270 Server require that the TN3270E client present a digital certificate as part of the session negotiation. Cisco TN3270 Server requires that the client present a certificate, but TN3270 Server does not verify the certificate.

Q. Is SSL support in TN3270 Server an extra-cost feature?

A. Yes. There are separate product codes for TN3270 Server licenses that support SSL. Cisco must pay a royalty for every TN3270 Server that supports SSL. The prices for the TN3270 Server with SSL licenses reflect this increased cost.

Q. Can I use SSL security for TN3270 Server when the Cisco IOS image on the router does not support IPSec?

A. No. The level of encryption provided by TN3270 Server is determined by the level of encryption supported by the Cisco IOS image. If the Cisco IOS image does not support encryption, then TN3270 Server cannot be configured to support encryption. If the Cisco IOS image supports "weak" encryption (56-bit DES), you will not be able to configure "strong" encryption (Triple DES) in TN3270 Server. It is not possible to order a TN3270 Server with SSL support with a Cisco IOS image that does not support IPSec.

Q. Can I run a Cisco IOS image that supports IPSec without running SSL on TN3270 Server?

A. Yes. You can run stronger encryption in the Cisco IOS software than you can run in TN3270 Server. A TN3270 Server without SSL support can be used with a Cisco IOS image that supports IPSec.

Q. Who provided the encryption algorithms for the TN3270 SSL support?

A. Cisco has licensed encryption and SSL algorithms from RSA Security, Inc. RSA Security is the worldwide leader of encryption products.

Inverse Domain Name System Nailing

Q. What is the inverse Domain Name System (DNS) nailing feature?

A. Inverse DNS nailing refers to the TN3270 Server's use of DNS symbolic names during the creation and assignment of logical unit (LU) names. It allows customers to select LU names by DNS symbolic name, rather than by IP address. This is useful in environments where the user's IP address changes frequently, such as when the customer is using the Dynamic Host Configuration Protocol (DHCP) to dynamically assign IP addresses to users.

Q. How does inverse DNS nailing work?

A. When a TN3270E client requests a session through TN3270 Server, TN3270 Server sends a DNS request for the symbolic name associated with the client's IP address. If this request is successful, TN3270 Server allocates an LU name based upon the DNS symbolic name.

Server Defined Definition of Dynamic Dependent LUs

Q. What is server defined definition of dynamic dependent LUs (SDDDDLUs), and why is it important to me?

A. SDDDDLU means that TN3270 Server can ask Virtual Telecommunications Access Method (VTAM) to create an LU with a specific name and a specific LU type. This means that the LUs do not need to be predefined in VTAM, and they do not need to be tied to a specific TN3270 Server. The feature greatly reduces the amount of configuration within VTAM, and it makes it much easier for multiple TN3270 Servers to provide load balancing and redundancy.

The etymology of the feature name comes from the following:

A dependent LU is the type of LU that is defined in an SNA subarea network. The "dependent" part means that the LU is dependent on the owning VTAM for session services, such as session setup and teardown. In contrast, in an Advanced Peer-to-Peer Networking (APPN) environment, the LUs are not dependent on a host VTAM and are considered to be independent LUs.

The dynamic part of the name means that these LUs do not need to be predefined, they are created dynamically by VTAM.

Server defined definition means that TN3270 Server defines the LU name and LU type, instead of VTAM. In previous releases of TN3270 Server, VTAM would create the dynamic definition of the dependent LU and would tell TN3270 Server what the name and properties of the LU were. This function is still supported.

SNA Session Switching

Q. What is the SNA Session Switching function?

A. The SNA Session Switching function is a small subset of the APPN End Node (EN) specification along with the Dependent LU Requester (DLUR) specification. In combination, this streamlined code provides SNA session switching on the Channel Interface Processor (CIP) for dependent LU traffic. Sessions can be routed to multiple VTAM nodes in the network without requiring the owning VTAM to route all traffic. This function requires a minimum of one VTAM in the network that is running Advanced Communication Function (ACF)/VTAM 4.2 or above and is defined as a Dependent LU Server (DLUS) host. Although the SNA Session Switch will route traffic to both channel-attached mainframes and remote mainframes, it makes the most sense implemented in a single Data Center when multiple mainframes are connected to the CIP and the TN3270 Server.

Q. How does the SNA Session Switching feature compare with implementing APPN on the router to switch TN3270 sessions?

A. The SNA Session Switching feature routes the TN3270 traffic after it has been converted from TCP/IP to SNA. Logically, the session switch sits "on top" of TN3270 Server on the CIP, and it routes only TN3270 traffic at this time. APPN, on the other hand, is located on the Route Processor or Route Switch Processor (RSP). Because TN3270 traffic is converted from TCP/IP frames to SNA frames on the CIP, using APPN on the router to route TN3270 sessions would require all packets to follow the path RP->CIP->RP->CIP->mainframe. Note that the SNA session switch is for TN3270 data only.

Q. Which LU types does TN3270 Server support?

A. TN3270 Server supports LU 1, 2, and 3 types. The standard does not support LU 6.2 sessions or LU 0 device types.

Q. What level of VTAM is required to support the Dynamic Definition of Dependent LUs (DDDLU)? Is this level a prerequisite for our TN3270 Server?

A. DDDLU was first made available on VTAM 3.4; all subsequent releases support the feature. The TN3270 Server relies upon this feature to define its pools of LUs. Therefore, VTAM 3.4 is a prerequisite to the Cisco TN3270 Server. This is also the minimum level required to support Cisco SNA (CSNA). Luckily, this level of VTAM has been available for many years, and most customers are already beyond this level. VTAM 4.1 is a minimum requirement for the optional SNA session switching feature.

Q. What about printer support?

A. Printer support was not dealt with in the early TN3270 standards, forcing vendors to implement proprietary support. The TN3270E standard (RFC 1647) was the first final standard to define printing support. [Note: an earlier informational RFC, 1646, was offered to the committee. RFC 1647 is the only final standard to deal with printing.] The Cisco TN3270 Server supports RFC 1647. In order to print to LAN printers, at least one TN3270E-capable client must reside in the network. The print job is sent to this client, which provides the translation of the data and redirects the output to a local or LAN-attached printer.

Q. My customer has TCP/IP on the mainframe to support only two applications: TN3270 and FTP (File Transfer Protocol). If we offer an "FTP-offload" application, they could get rid of the TCP/IP mainframe license. Does such a product exist?

A. A few such products exist in the marketplace. Cisco is evaluating offering an AFTP-to-FTP conversion feature in the future. This would allow network-based FTP clients to send file transfers to the mainframe and vice versa without installing TCP/IP on the mainframe for those customers only requiring the two applications, TN3270 and FTP.

Q. Can a CIP card running TN3270 Server also support one or more of the other three CIP applications (IP Datagram, TCP/IP Offload, CSNA)? What are the considerations of a mixed implementation?

A. Yes. Any of the CIP applications can run alone or concurrently with all other CIP applications. And with the CIP Loader at Release 11.1, only the applications desired by the customer are loaded onto the CIP card. This means that customers optimize the memory on the CIP card. The largest planning consideration is for memory. Running multiple applications on a single card will limit the total number of sessions for each individual application. See the CIP home page on the Cisco Web for further planning details.

Q. How is the TN3270 Server positioned against the TCP/IP Offload feature already available on the CIP card?

A. The TCP/IP Offload feature offloads the TCP and IP stack processing from the mainframe without regard to which application the data being processed is destined for. This is a valuable function. But TN3270 traffic is characterized as processor-intensive because of its small packet (< 2 KB) characteristic. Offloading 100 percent of cycles for TN3270 can reduce mainframe CPU cycles more than offloading 30 percent of FTP cycles. But when combined, the two features together are invaluable. Sell your customer the value of offloading one hundred percent of the most egregious application (TN3270) while still offloading 30 to 50 percent of the other, more efficient applications like FTP using the CIP Offload feature. Support for TCP/IP Offload was removed from the Communication Server for OS/390 (CS/390) beginning with Version 2 Release 5.

Q. Since running TN3270 Server on the CIP requires the ability to transport SNA on the channel, does the TN3270 Server product come with CSNA bundled?

A. If CSNA is used for anything other than TN3270 Server, then it must be purchased separately.

Q. What is the maximum number of physical units (PUs) that can be defined within a single TN3270 Server?

A. The number of defined PUs is affected by the following constraints:

CIP memory.

Unique local/remote Media Access Control/Service Access Point (MAC/SAP) quadruples. (This is an issue for direct PUs only.) Since only even-numbered SAPs from 0x02 to 0xDE should be used, if all PUs are to go to the same remote MAC/SAP then only 110 PUs can use one local adapter.

Maximum CSNA link stations. (This is an issue for direct PUs only.) Each direct PU uses a CSNA link station. If it is connected via the channel to the host (instead of going from the CIP across Token Ring or FDDI, etc.), then the host side of each link also uses a link station.

Q. What is the formula for calculating the amount of required CIP memory?

A. See this URL: http://www.cisco.com/warp/public/650/60.html

Q. What is the CIP memory requirement for the following number of concurrent sessions? Is there a rule of thumb for this?

A. The only rule is based on theory, not measurement. Being conservative, CIPs allow 4 KB per session for control blocks plus buffered data (mostly the latter). It takes 8 MB for the base code and fixed data areas, so for a 32 MB CIP, you get (32 MB-8 MB)/4 KB = 6 KB sessions. In practice, you could probably run many more sessions on a 32 MB CIP, but you might get a performance gain by going to 64 MB or 128 MB. Recent tests have maintained 32,000 concurrent, active TN3270 sessions on a single CIP using dual ESCON.

Q. What is the maximum number of LUs that can be defined within a single TN3270 Server?

A. As many as 255 per PU, up to the limit imposed by CIP memory. However, it is not recommended to try passing more than 450 TN3270 transactions per second through the CIP. At the reasonable rate of one transaction per minute, per user, it equates to 27,000 simultaneous users. Anything greater can affect response time.

Q. How many TN3270 Servers can run on a single CIP interface?

A. A single CIP interface supports one TN3270 Server and many PUs under that particular server. More than one CIP can be installed on a router, and for each CIP interface, a single TN3270 Server can be used.

Q. How can I tell if I am approaching a limit somewhere?

A. There are various limits to consider:

For the numbers of LUs in use, there is no high-water statistic available. However, if the configured maximum-LU number is approached, a warning message is logged. The threshold for generating the message is automatically raised each time the message is generated and automatically lowered again over time.

For CIP CPU utilization, look at the output from the command show controller cbus. This gives the one-minute, five-minute, and 60-minute sliding averages (as shown in Table 1).

Table 1  CIP CPU Utilization

Memory

DRAM 53610040/64M

CPU

1m 1%, 5m 0%, 60m 0%

DMA

1m 1%, 5m 0%, 60m 0%

ECA0

1m 0%, 5m 0%, 60m 0%

ECA1

1m n/a, 5m n/a, 60m n/a


Tuning


Note: Modifying the default parameters without understanding the impact of each may impact the performance of TN3270 Server. Caution must be taken when changing these parameters.


Q. What LLC2 parameters should I use?

A. The default parameters are suitable for most installations. If DLUR with thousands of LU-LU sessions per link is required, it may be necessary to increase the recv-window. The recv-window parameter is modified via the CIP virtual interface under the LAN definition.

Warning: Making the window too large on many links could result in channel slowdowns. These are far more costly in terms of performance degradation.

Tuning Tip: When experimenting with the CIP to assess the performance, it is important to remember that it is designed for high traffic volume over independent flows. A test with a single file transfer, for example, will not show its capabilities. Running a second transfer in parallel can actually make both transfers run faster!

Q. When connecting CIP TN3270 to the host via the channel, is it best to put the TN3270 PUs/DLUR on the same adapter as the XCA port, on a separate adapter in the same virtual LAN, or on a separate virtual LAN in the same CIP?

A. All of these will work well today. In the future, there may be a disadvantage in using separate VLANs, and there is no advantage to doing so. The advantages of sharing an adapter are only the saving in memory and MAC addresses. The advantages of a separate adapter include a reduced risk of conflict in SAP addresses and the ability to duplicate MAC address on the XCA adapter to provide redundancy.

LU Nailing

Q. What is the minimum Cisco IOS software level and CIP microcode required for LU nailing?

A. First, let us be clear what is meant by LU nailing. Using TN3270E (RFC1647), a client can select LUs in the CIP by LU name. This is a form of LU nailing and it is supported by all releases of CIP TN3270 Server.

Fixing the client-LU mapping within the CIP by configuration command is another form of nailing. This was added in Release 11.2(8) BC and CIP Microcode 24-0. At present, the only nailing provided is by client IP address.

Q. What is the minimum Cisco IOS level and CIP microcode required for TN3270 Server—without LU nailing—and an RSP4?

A. Cisco IOS Release 11.2P.

Q. What is the minimum Cisco IOS level and CIP microcode required for TN3270 Server—with LU nailing—and an RSP4?

A. Cisco IOS Release 11.3ED.

Q. What is LU capping?

A. This feature provides a way for a customer to limit the number of LUs that can be used concurrently by a single client IP address.

Q. What platform is the LU nailing feature available on?

A. The feature is available on the RSP only.

Q. We already have conventions for naming LUs. How can we use these conventions with CIP TN3270 Server?

A. Because the CIP TN3270 Server can handle thousands of LUs but has no hard disk available to hold configurations, there is no facility for configuring arbitrary LU names. There are several options:

Accept that the LU name in the CIP is different from the LU name at the host. In particular, if TN3270/E clients are requesting LUs by name then they must use the LU name (generated by lu-seed) in the CIP.

Use DLUR and static LUs. When VTAM activates the LU, the CIP learns the LU name.

Depending on the naming convention being used, it may be possible to have the CIP use the same convention by defining more PUs and not using all the LUs.

Q. How can I provide redundancy for nailed LUs?

A. There are several ways to use nailing. At first it may appear that there are different answers for different cases.

In the simplest nailing use, a client is mapped by IP address to a single fixed LU that is statically defined in VTAM. The same client, if routed to a different CIP, can also be mapped there to a single LU. (Note that a TN3270E client requesting an LU by name is also covered by this case.)

It might not matter that a user uses either of two different LUs; but, typically, the host will not accept the user being on both LUs at once. So if there has been some network outage that has not yet resulted in terminating the old session, the host may refuse the user's new connection.

More commonly, the host requires that the user always use the same LU. Therefore this same LU must be on both CIPs. Today, this can be achieved only by having the same PU on both CIPs (because there is no effective mechanism for dynamically moving an LU from one PU to another at the host). For a full discussion of the duplicate PU solution, see the Server Redundancy section.


Note: It is frequently suggested that a customized ISTEXCSD exit can help by allocating an LU name that's based only on the client IP address, not on LOCADDR or PU identity. That way, the same LU can be on any of several PUs. Unfortunately, VTAM today provides no means, short of PU deactivation, to release the name from the PU.


A similar use of LU nailing uses DDDLU. Because the client is nailed, the CIP always chooses the same PU and LOCADDR for the client, so although it is technically DDDLU, it functions the same as for a static LU.

In a third use of nailing, a subnet of clients is nailed to use a pool of LUs. Within the cluster, the only discrimination made by the CIP is between printers and screens. Any screen client in the subnet can be mapped to any available screen LU in the pool. Typically, this arrangement is used because the screens share printers in the same subnet. The host does not require a particular user to use a particular LU, but it does need to understand the relationship between screens and their printers. Consider a fallback CIP with the same nailing configuration. If both have their listening points active, then a screen may find an LU on one CIP, and a printer from the same subnet could end up on the other CIP. Once again, it is necessary to ensure that only one of the PUs is active at a time.

Server Redundancy

Q. What is a better solution, LocalDirector or DistributedDirector?

A. It depends on the network requirements. What you choose depends on what your needs are. If you have deployed DNS to the desktop—clients use the DNS name of the host service and not the IP address—and you primarily want only TN3270 access into the mainframes, then DistributedDirector is a viable solution.

LocalDirector performs well at handling short-lifetime TCP connections such as HTTP or custom TCP socket-based transaction programs. DistributedDirector isn't as good at this because it causes more network traffic and session startup delay. If the customer is going to run the mainframe as an HTTP server, or other similar functions, then LocalDirector is a viable solution.

Q. How can I provide server redundancy for LUs with specific meanings to host programs?

A. This is a major issue with TN3270 servers, and there is no easy solution. The only technique that's feasible today is to have the same PU (that is, same idblk/num) on two or more CIPs. These compete for activation in VTAM. (VTAM will allow only one to become active.) The activation of only one PU brings with it the following problems:

Disruptive messages on the VTAM console—If all backup instances of the PU are allowed to keep trying to connect to VTAM, VTAM will keep rejecting them, as expected, and keep putting messages on the VTAM console, which can be disruptive. It may be possible to filter out these messages. However, we recommend that you find a way to prevent the PUs from trying to reconnect. There are two ways the reconnections can be inhibited, and both require a host script. The script could issue CIP configuration commands (that is, shut/no shut of the PUs) through NSP, or it could control access by activating and deactivating XCA major nodes. Both solutions also help to reduce the fallback times. See the fallback time listing below. Note that the XCA solution works for only direct PUs, not DLUR PUs. Also, it will not work if you are using duplicate MAC addresses to provide the PUs with an alternative path to the host.

PU grouping—The PUs that share a listening point (TCP/IP address) on a CIP are a logical group. If any one is active and has available LUs, the listening point will be open and a DNS will direct clients to it. If another CIP provides redundancy for these PUs, you must have the same logical grouping on both CIPs, and you need to ensure that all the active copies in the group are on the same CIP. The simplest way to do this is to assign a separate TCP/IP address to each PU.

Fallback time—If a TN3270 Server PU attempts to contact VTAM and is rejected (for example, because another PU with that idblk/num is already active), the PU can take several seconds before retrying.

Blocking access to the host by deactivating the XCA major node helps because it causes the Test command to go unresponded. The time to retry the Test command is not more than one minute.
The shut/no shut mechanism is better still. The PU will initiate contact with VTAM immediately if it is configured no shut.

Switchover logic—How is the script to determine when to switch to a fallback? In the case of planned outage or server failure, the determination is easily made. The awkward case is when there is a network outage adjacent to the server. The server has become unusable, but it may not realize this, and neither will the host.

Recovery

Q. There has been an outage in part of the network. The users are trying to connect back into it. The keepalive is normally set to 20 minutes (or is disabled entirely). How can I clean up the hung sessions without disrupting other users?

A. You can set the keepalive to a lower value temporarily. If you set it down to, say, five minutes, then the CIP TN3270 Server will immediately generate keepalive traffic to each client that has been silent for five or more minutes. The hung sessions will be cleaned up by the normal TCP retry exhaustion logic.

Q. Does CIP TN3270 Server support takeover/giveback?

A. Yes. You should configure the PUs at VTAM with ANS=CONT. Takeover/giveback works for both direct PUs that go via a FEP to the host and for DLUR PUs. Takeover/giveback is not supported over XCA unless you are using DLUR.

Accounting

Q. When using DDDLU, how can we track who is using the system?

A. The CIP TN3270 Server sends the client TCP/IP address to the host in the NMVT Reply PSID message that drives DDDLU. It sends a second NMVT Reply PSID message (saying "power off") when the client disconnects.

You can replace the IBM-supplied default exit with your own exit. This will allow you to track the relationship between LUs and IP addresses. The model string is also present, so you can distinguish screens from printers at the same IP address.

Printing

Q. Can the Cisco TN3270 Server address network printers directly or does it need a TN3270E client for printing support?

A. The customer needs a TN3270E client for printing. The client performs the appropriate transformations and talks to the print spooling system, such as NetWare, and to LPR/LPD.


Note: RFC1646 (TN3270) printers are also supported.


Q. How can I have screens at the host associated with the right printers and yet have redundant CIPs?

A. This is a complex question. Refer to the questions under the Server Redundancy section.

Server Algorithms

Q. When using DDDLU, how does the CIP TN3270 Server choose the LUs it allocates?

A. There are many considerations. The first preference is for an already active LU that had no problems when it was last used (such as Bind timeout) and that was last used with the same terminal model. The second preference is for an LU that has not been allocated since the PU was last recycled. There is also a delay of 10-15 seconds imposed on reusing the same LU. This avoids a window in VTAM.

When the choice is a fresh LU, consider the order in which the PUs are used. The CIP TN3270 Server attempts to spread the LUs across the PUs in a round-robin fashion.

Network Management

Q. What products and methods are available for managing TN3270 Server and TN3270 sessions?

A. This is a complex question, because it covers both the server and the sessions. There are several methods for managing TN3270 Server:

show commands, as detailed in the Cisco IOS command reference manual

Management Information Bases (MIBs) for TN3270 Server

Management application for UNIX workstations, called TN3270 Monitor

CiscoWorks Blue Internetwork Status Monitor

CiscoWorks Blue SNA View

Latest release of Tivoli NetView for OS/390

SOLVE: Netmaster for TCP/IP

NetView Performance Monitor (NPM) and CA's NetSpy

These methods differ in the information type available, the platform, and the management components.

Q. When measuring end-to-end responses, NetSpy measures response times from the host perspective. What is actually being measured?

A. It depends on the server and client configurations. If the client is running as TN3270E and has response mode enabled, the response time is genuine end-to-end. Otherwise, if timing-mark is configured in the CIP TN3270 Server, then the server will map definite response (DR) to timing mark (TM) and the response time is, again genuine, provided the client replies to the TM with the same chronicle with which it would have sent a positive response. Note that this last proviso may be violated in either sense: the client may reply to the TM in a delayed manner or before processing the outbound data. In all other cases, the response is from the server and does not incorporate the network transit time.


Note: NetSpy and NPM use the same mechanism for managing response times.


Q. Is Response Time Monitor (RTM) supported?

A. No.

Q. Does the Cisco TN3270 Server support the TN3270 response time MIBs?

A. TN3270 Server has supported the RFC 2562 response time MIB since Cisco IOS Release 11.2(18)BC and 12.0(5)T.

Diagnostics

Q. What does "dyn timer expired" mean?

A. The use of the term "dyn" comes from the original purpose of the timer. The timer is now used for many purposes, but the term is retained purely to distinguish it from another timer event that can occur (inactivity timer). Because of the need to minimize the per-LU memory usage, the finite state machine (FSM) state is not logged in the history buffer. So the only way to determine exactly what the event represents is to deduce the state from the prior history.

Table 2 lists the circumstances and significance of these timer events. Table 3 reflects the prior history.

Table 2  Significance of Timer Events

Abbreviation

As Shown on Console

Actlu

actlu req

Bind

bind req

DynTimer

dynamic timer expired

RspNfy

notify resp

RspPSID

{Reply PSID pos rsp

{Reply PSID neg rsp

RspUnbind

Unbind rsp

-RspSent

Neg rsp to host

SDT

sdt req

TnetConnect

Client connect req

TnetDisc

Client disconnect req

TnetTmww

Timing Mark received

Unbind

unbind req


Table 3  Prior History

Prior history

Notes

FSM state

Meaning of tmr expiry

RspNfy

 

Actlud

Business as usual

TnetConnect

 

PsidSent

"No PSID Rsp" logged

RspPSID

(5, 7)

WaitToSendNfy

Safe to change model

RspPSID; or RspPSID, DynTimer

(5)

NfyAvSent

"No NFY Rsp" logged

Actlu; or RspNfy;

or Bind, Unbind;

or Unbind,

TnetTmww;

(1)

(1, 3)

Sscp

"No Bind" logged

Bind

 

Bound

"No SDT" logged

SDT

(3, 6)

SdtWt

"No SDT Tm" logged

SDT;

or SDT, TnetTmww;

(4)

(3)

LuLu

Business as usual

Unbind

(1, 3, 6)

UnbindWtTmww

"No Unbind Tm" logged

Unbind; or TnetDisc, RspNfy;

(2)

NfyUaSent

"No NFY UA Rsp" logged

RspUnbind; or RspUnbind, -RspSent;

 

WaitSendNfyUa

Safe to send Nfy Ua


Notes:

1. And unbind-action keep

2. And unbind-action disc

3. And timing-mark

4. And no timing-mark

5. The only way to discriminate the two cases of timer expiry following RspPSID is by whether "No NFY Rsp" was logged.

6. "No xxx Tm" means client failed to reply to a timing-mark that was sent for that stated reason (xxx).

7. This marks the end of the delay imposed when the server was forced to assign an LU that was last used as a different model.

Q. When I take a CIP TN3270 trace, some of the events seem to be in the wrong order. Why?

A. The CIP TN3270 Server categorizes events by importance. Most trace entries are of low importance. These go into a trace ring on the CIP which, in heavy traffic, can become overwritten faster than they can be spooled to the console. Events of greatest importance are sent directly to the console log by a more secure path and can therefore overtake the trace entries.

Competitive Positioning

Q. There are a number of channel-attached hardware vendors that offer Novell's NetWare for SAA and Microsoft's SNA Server on their platforms. In general, how is the Cisco solution positioned against these solutions?

A. All of these hardware solutions that run NetWare for SAA or SNA Server are PC or server platforms. They run DOS plus NetWare or Windows NT, which are both general-purpose operating systems. Thus, the scalability and performance of the system solution are limited. Most of these platforms in a real-world networking environment can only support a few hundred or perhaps a thousand sessions. The Cisco CIP implementation supports up to 16,000 sessions.

Q. What if I have a customer who has made a commitment to Windows NT? Does our implementation support Windows NT?

A. Yes. Separate the Windows NT server from the SNA Server. A Windows NT server is just a PC server that communicates over a network with other servers using some protocol. NT supports TCP/IP natively. So if the NT clients require access to the TCP/IP stack on the mainframe, they can go through the CIP using IP Datagram or TCP/IP Offload. On the other hand, if the NT clients want to access VTAM applications, they should run TN3270 client software on the client itself. The NT server, which sits between the client and the CIP, has no role in the mainframe access other than forwarding IP packets to the Cisco 7000 with CIP.

Q. Why would a customer want an external solution like Cisco's rather than just leaving the TN3270 server function on the mainframe?

A. The TN3270 server function is bundled into the pricing of TCP/IP mainframe stacks. But the real price of mainframe-based TN3270 server solutions is in the mainframe cycles. Each 3270 screen of data comes into the mainframe as TCP/IP data. It is processed by the TCP/IP stack (unless TCP/IP Offload is enabled), then sent to the TN3270 application in the mainframe (even if TCP/IP Offload is enabled). The mainframe massages the data, then hands it off to VTAM for final processing by a VTAM application. With an external solution like Cisco's, the TCP/IP stack and massaging of the TN3270 data are done on the CIP card. The amount of processing required in the mainframe is minimal. And, in the case of TN3270 sessions, the TCP/IP mainframe stack is not required at all.

Positioning the Cisco TN3270 Server versus NCIA

Q. The TN3270 Server and Cisco's native client interface architecture (NCIA) appear to provide similar functions and compete with one another. What message is Cisco sending to the marketplace with support for TN3270 Server? Are we giving up on NCIA?

A. The TN3270 Server and NCIA provide a similar function at a very high level— both allow client emulator software packages access to existing IBM mainframe applications, and both support TCP/IP as the backbone transport for these sessions. A different type of implementation includes Data Link Switching Plus (DLSw+), where the client LAN runs SNA or NetBIOS and the router or other device encapsulates this into TCP/IP. In both NCIA and TN3270 Server, the native protocol from the client PC is TCP/IP. The primary difference between these implementations is in the location of the SNA PU and LU. With NCIA, the client is a full SNA PU and LU. With TN3270, the SNA PU and LUs are located on the TN3270 server.

The primary advantage of the NCIA approach is that the full SNA capability built into the SNA emulator is maintained, and NetView visibility of the client is maintained. The primary advantage of the TN3270 approach is that the definition and  configuration are eased, because each client looks like one or more LUs but does not require the definition of a PU. TN3270 is also an accepted industry standard with a very large installed base of devices supporting it.

Cisco will continue to support and enhance NCIA to meet the needs of customers preferring this implementation. We are offering the TN3270 Server as an alternative for those customers that have made a commitment to TN3270.

Q. How do I know when to sell NCIA and when to sell TN3270?

A. The best way to determine which approach to sell is to find out the customer's intention and to determine the current emulator installed base. The customer who would probably prefer a TN3270 solution is one who:

Has an installed base of TN3270 clients and servers, or

Needs to support a large number of users economically, or

SNA functionality required is limited to 3270 datastreams (LU 1, LU 2, LU 3) and PU Type 2.0

A client who may prefer NCIA is one who:

Is architecting an end-to-end solution and is open to the choice of emulators, or

Requires SNA visibility to each end station, or

Requires full SNA capability—native keyboard support, LU 0, LU 6.2, NT 2.1