Introduction
Prerequisites
Requirements
Conventions
Frequently Asked Questions
Q. Do I need the Cisco SNA (CSNA) option if I want to use the TN3270 server?
Q: Can I assign two different physical units (PUs) on the CIP to the same target IP address? If so, how do the logical units (LUs) get distributed from each PU (with Dynamic Definition of Dependent LU [DDDLU])?
Q. What is the configuration parameter for coding a session limit?
Q: If we code a session limit in the TN3270 server, what happens to a user who addresses the server when no more connections are available on the server?
Q: What is the CIP memory requirement for the following number of concurrent sessions? Is there a rule-of-thumb for this: 1000 sessions 2000 sessions 6000 sessions?
Q: What would be the throughput fif you run a Cisco 7000/7500 with up to four CIPs that run a TN3270 server? (There are 2000 sessions on each CIP that runs 130 transactions per second on each CIP server. The transaction size is 50 bytes in by 1024 bytes out.)
Q. Does the transaction rate in these questions seem feasible given four TN3270 servers in the same Cisco 7500?
Q: Do I need TCP/IP on the host to support a TN3270 Server on CIP?
Q: If there is no TCP/IP stack that runs on the mainframe host, how do we code the host IP address and initiate routing that is currently defined in TCP/IP on the mainframe?
Q: How does the TN3270E support dial-up and printing? I have been told that our TN3270E server does not support printers from dial-up TN3270E clients. I thought that the TN3270E server does not know how a client is connected to it, and only knows the client side IP address. In addition, the server does not know if the actual printing is done on a printer directly attached to the client or through a server or queue printer.
Q: What is the real value for the LUs supported by the CIP? The CIP brochures said that it supports 8000 LUs. Is that number correct?
Q: Does a router (RSP) need more memory in order to support all the features provided by the CIP?
Q: What is the minimum Cisco IOS® Software release needed in the router in order to support the CIP?
Q: If a unique LU group (TN3270) is defined for all users, how can the security be managed? How do I determine who tries to violate the system if no trace is kept?
Q: What is "tail-ending" in the TN3270 environment?
Q: What should be the VTAM IOBUF size for CIP? I have an VTAM IOBUF size of 128 which prevents the activation of the XCA major node.
Q: We implemented Virtual IP Address (VIPA), which allows us to transparently switch from one router to another when there is a hardware failure, while at the same time users need only one IP address (the virtual one). How can we get a similar redundancy with a TN3270 server and use only one IP address for the users?
Q: What are the alternatives if we cannot use the Cisco DNS solution for TN3270 server redundancy? We cannot replace the DNS servers because they are in a different location.
Q: How do LUs in VTAM get activated when you run the CIP TN3270 server?
Q: Does Cisco support 3820 printers? Does not the 3820, a JES-supported device, need FMHs (which Cisco does not support)?
Q: I currently have USS10 message tables assembled for SNA terminals. Can I use these with our TN3270 server?
Q: What is the difference between clients that use SNA Character String format SSCP-LU dialogs and traditional TN3270 clients that use 3270DS format SSCP-LU dialogs?
Q: LUs hang during TN3270 sessions. How do I get TN3270 Trace from the CIP?
Q: With TN3270 server, how do we print to LAN-attached printers? I understand that it requires a TN3270E client, but I do not understand how the print stream gets from the TN3270E client to the destination printer if they are not the same. Is it preferable to have multiple TN3270E clients for printing? One per subnet? One per network?
Q: Can you clarify what are potential bottlenecks for the CIP TN3270 server that runs in a source-route bridging (SRB) environment?
Q: Is there a way to statically match an LU with an IP address so that an LU always connects across the same IP address?
Q: With the CIP TN3270 server, Specific LU Allocation states that the "The LU names have to be defined in the server configuration with the LOCADDR that match the VTAM configuration." How do I do this? How do I associate PU, LU-NAME and LOCADDR?
Q: I have two routers with a CIP connected to the same mainframe that run TN3270 on both CIPs. Is it possible to run HSRP in the common LAN connected to both routers so that remote clients (not directly connected to the LAN) Telnet to one of the two TN3270 servers transparently (with the same destination address)? This is for redundant service.
Q: How do we print to LAN-attached printers [LU type 1 (SCS) support as well as LU type 3 over a TCP/IP network]? I need your product to hide from the MVS machine the fact that it does not talk to a SNA-connected device, and to allow me to use a pseudo LU just like a real SNA LU with SNA Network Interconnection (SNI) access, a one-to-one relation with hardware on the other side, and NetView visibility. This is what I need:
Q: Does the system services control point format (SSCPFM) parameter in the switched network (SWNET) major node sift down to LU Group from PU?
Q: I have several questions about this design that includes fault tolerance and load balancing. Can we load-balance user traffic to NVASPROD between the two 7513/CIPs? :
Q: In regard to fault tolerance, what happens if the 7513/CIP1 fails?
Q: Can this move be hidden from a user's point of view, so there is no change at the 7513/CIPs and no change in user configurations.
Q: How do I configure LOCADDR with specific names in the server so the specific names can be found in the specific LU cache?
Q: If two CIPs are configured for redundancy and one fails, what is the best way to redirect clients?
Q: Can LU pooling be performed without the implementation of Advanced Peer-to-Peer Networking (APPN)?
Q: Does the TN3270 or xmodem support require additional memory in terminal servers?
Related Information
This document contains frequently asked questions about the Cisco TN3270 server.
There are no specific requirements for this document.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
A: Yes, the TN3270 server relies on CSNA for Logical Link Control, type 2 (LLC2) connections to either the external communication adapter (XCA) connected hosts or the Token Ring connections through source-route bridging (SRB) or with data link switching plus (DLSw+) to a remote channel-attached Channel Interface Processor (CIP) router or front end processor (FEP).
A: Yes. Almost all of the LUs that belong to all PUs sharing an IP address are eligible to be allocated by TN3270 client sessions that connect to that IP address. LUs that are predefined at the host's switched major node definitions cannot be allocated by TN3270 client sessions (unless the client is a TN3270E and requests a specific LU by name).
A: The configuration parameter is maximum-lus. If you reduce the parameter value below the number currently in use, this will not affect active sessions. No new client connections are allowed until the number of LUs in use is below the maximum allowed limit. The allowed range is 0 to 32000, and the default is 2100. LU control blocks in excess of the maximum are not returned to the available memory pool until the PU goes inactive.
A: The TN3270 client gets this message:
MAXIMUM NUMBER OF LUs EXCEEDED
This behavior can or cannot be visible to the end client. In addition, two other things happen:
A message appears on the router console:
No LU sessions left for PUs at IP addr %s, port %d
An SNA alert is generated for this event.
A: The only rule is based on theory, not measurement. CIP allows 4K per session for control blocks plus buffered data (mostly the latter). It takes 8M for the base code and fixed data areas, so for a 32M CIP, you get (32M-8M)/4K = 6K sessions.
In practice, you can probably run many more sessions on a 32M CIP, but you can get a performance gain if you go to 64M or 128M.
Note: CIP1 can have maximum memory of 64M, while CIP2 can have maximum memory of 128M. Remember to account for other CIP features when you estimate the total CIP memory usage.
A: Throughput is only 4.4 megabits per second, as shown here:
130trans/sec x 4CIPs x 1074 bytes/transaction x 8 bits/byte = 4,467,840
A: Yes, provided that there is no traffic that traverses more than one CIP, but if you used CSNA on some CIPs as fallback channel access (duplicate Media Access Control (MAC) Address) for PUs on other CIPs, some traffic would traverse two CIPs.
A: TCP/IP on the host is not required for TN3270 Server support on CIP as long you have TCP/IP 3270 access to the server, and direct Systems Network Architecture (SNA) traffic to the host, but there is no File Transfer Protocol (FTP) application without the TCPIP stack on the host, so you would have to transfer data by SNA methods to Virtual Telecommunications Access Method (VTAM).
The same applies to a CSNA only environment, where you have SNA direct connectivity to the host with no TCP/IP at all (unless you transport the SNA over the WAN through data-link switching (DLSw).
TCP/IP is required for the IP Datagram and Offload features because you connect to the mainframe as a TCP/IP peer. The only difference with Offload is that the CIP does the TCP processing and sends socket calls to the FTP/TN3270/Telnet applications that reside on the host, which acts as a TCP/IP peer.
A: Instead of the mainframe TCP/IP host, the TN3270 server on the CIP has to be given an IP address. If you have TCP/IP on the host, it has an IP address that is known by the configurations that are set up on the channel, so it can be accessed by normal IP routing. In Offload mode, the CIP has the IP address to which you connect because it is the endpoint of TCP processing. It removes TCP/IP packet information and sends a socket-type header across the channel to the TCP/IP Offload Application Programming Interface (API) in the host.
A: The TN3270E cannot support dial-up printing when the printer LUs are based on remote IP addresses. It is difficult for the dial-up TN3270-print client to determine what the printer LU is for the dial-up connection. Both the end-user and the client-TN3270-print software do not know the LU name to specify.
In order to get around this, create a print queue (and reserve an LU) for each user who can dial-in. Then, the print-LU used by the dial-up user can remain constant. This solution is attractive to laptop PC end-users who want to use the same TN3270 session configurations at work and home.
This implies that to support dial-in users, you must create print-LUs for each possible remote user. The number of LUs created is usually at least an order of magnitude greater in size than the number of dial-in lines, but this should not be a problem because print queues are not expensive. In addition, the PC of an end-user must be configured for a special print stream name. Extra configuration on each PC that can dial in remotely makes this solution less of an option. The use of application-based print LUs complicates the problem considerably because the printer-LU assignments sometimes cannot be changed at runtime.
A: Yes, 8000 LUs is correct for CIP1: 8000 LU sessions at one transaction per session per minute. The transaction size from the point of view of the 3270 data-stream is 200 bytes inbound to the host and 800 bytes outbound from the host.
For CIP2, the number is 16,000 LU sessions at one transaction per session per minute (200 bytes inbound to the host; 800 bytes outbound from the host).
A: You need to run a minimum of 24MB on a Route/Switch Processor (RSP).
A: CIP runs on Cisco IOS Release 10.2 and later (IP Datagram). IP Offload and CSNA support began in Cisco IOS Release 11.0. The TN3270 Server requires Cisco IOS 11.2 or later; the TN3270 Server feature was first made available as an engineering special release in Cisco IOS 11.0. This special release was supported for up to one year after the Cisco IOS 11.2 first customer shipment (FCS) had been in the field. Offload is only available with mainframe TCP/IP until version 4. After this, IBM withdrew offload as an option.
A: Security is left up to the host; it follows the normal user/account/password sequences.
In addition, tracking information is provided at TN3270 session setup time. An NMVT(Reply-PSID) is sent to the host. The reply-PSID is a necessary part of the DDDLU process, but it is sent for all LUs whether or not they are DDDLU based. The reply-PSID flows on the SSCP-PU session, and contains this information:
LOCADDR number of the LU requested
IP address of the remote client that connects
TCP port number of the remote client that connects
You can then log the received reply-PSID records to System Management Facility (SMF) through NetView or NetMaster exits. The exits are not supplied by Cisco.
The information given on the reply-PSID can be useful for accounting purposes as well as security purposes.
Release 12.1(5)T of Cisco IOS software offers new TN3270 Server feature that enhances security, which is SSL Encryption between the TN3270 Client and Tn3270 Server. SSL is a de facto standard to protect TCP/IP data transmitted between a server and a client. The TN3270 Server in the Channel Interface Processor (CIP) and Channel Port Adapter (CPA) supports SSL encryption. The Cisco TN3270 Server comes in three modes: no encryption, exportable encryption, and strong encryption. It includes support for RC2, RC4, RC5, and DES encryption algorithms, and MD2, MD5, and SHA message authentication schemes. When used with an SSL-capable TN3270 emulator, such as IBM's Host On-Demand, SSL provides secure message integrity and confidentiality.
SSL encryption is an extra-cost feature because of royalty considerations. There are different product codes for SSL-enabled licenses for the TN3270 Server. The SSL-enabled version of the TN3270 Server requires an IPSec-enabled version of the Cisco IOS software.
A: In tail-ending, an LU session user is "booted off" the application through the master console of the application. The TN3270 session that uses the LU is then disconnected, and a SNA NOTIFY(SLU-inhibited) is sent to the host from the CIP, as shown here:
[seen from point of view of VTAM....]
VTAM CONTENT CIP TN3270 Server
-----------------------------------------------------------
------------ UNBIND(normal) ----------->
<----------- NOTIFY(available)---------
<----------- +RSP.UNBIND --------------
------------ +RSP.NOTIFY -------------->
<----------- NOTIFY(inhibited)---------
------------ +RSP.NOTIFY -------------->
So, if there is a queued BIND, you would get:
VTAM CONTENT CIP TN3270 Server
-----------------------------------------------------------
------------ UNBIND(normal) ----------->
<----------- NOTIFY(available)---------
<----------- +RSP.UNBIND --------------
------------ BIND --------------------->
<----------- -RSP 0845 ----------------
------------ +RSP.NOTIFY -------------->
<----------- NOTIFY(inhibited)---------
------------ +RSP.NOTIFY -------------->
The problem is that the NOTIFY(inhibited) does not cause VTAM to invoke a queued LU session request off the session queue of the LU. So, before and after the NOTIFY(inhibited) happens, a VTAM display of the LU shows the queued session. This queued session is the session manager of the user.
When another TN3270 end-user wants to connect to the same host, the same LU is reused. So a reply-PSID (for DDDLU) is sent to the host, followed by a NOTIFY(available). The host eventually sends a BIND. The end-user, instead of a user/password challenge screen from a new super-session, gets the super-session screen of the previous user (which results in a security hole).
There have been several fixes integrated in different levels of CIP microcode to address this problem: CSCdk48736 integrated in CIP22-36; CSCdm51110 integrated in CIP22-39; CSCdt84286 integrated in CIP26-23, CIP27-18, and CIP28-7; and CSCdx56737 integrated in CIP27-22, CIP28-11, and CIP26-28.
A: The low IOBUF sizes waste VTAM processing because of buffer chaining. The reason for a low IOBUF size was to match the buffer allocation in the 3705 router. More recently, front-end processors (FEPs) have more memory and can have bigger buffers, which allows IOBUF to be larger.
IOBUF buffer size is often 512, 1024, or larger.
A: One way to provide redundancy is to use a Local Director. This is an IP address translation function. For example, the users specify one address (the Local Director), and the Local Director maps it to the actual address it chooses; this is an active router through which all frames pass. If a TN3270 server dies, it automatically routes future requests to the other router.
You can also use NetView CLIST, which triggers off the PU failure message and uses the node switch processor (NSP) to issue configuration commands to a backup router. When NetView detects that the primary router fails, it configures the standby router with the same IP address that uses RUN commands. This is not transparent, but it is automatic.
A: If you have Domain Name System (DNS) Servers in different locations, you can still have a second DNS, which performs the first queries when the request is for one of the TN3270 names. In this way, only requests related to the TN3270 server come to the second DNS.
The solution is more complicated if you have many other downstream customers which have independent private DNS systems. The problem is not impossible, but to craft a solution for every dual-boundary downstream DNS system is very complicated to implement. In this case, a single virtual IP address solution with Local Director is a better approach.
A: There are two scenarios:
Scenario 1:
Specific or static LU: The host activates at PU startup. The host sends an ACTLU for all LOCADDRs defined in the PU definition shortly after the +rsp ACTPUs are exchanged. The TN3270 server accepts with an ACTLU(UNAVAILABLE). When a TN3270 client comes in and expects that LU, a NOTIFY(AVAILABLE) is sent to the host.
Scenario 2:
Dynamic LU or DDDLU: The host does not send an ACTLU at PU startup. Instead, nothing happens until a TN3270 client requests a session. Then a Reply-PSID is sent to the host with the terminal type (model number and type). The host then sends an ACTLU. The LU is typically not deactivated after that point. Instead, the TN3270 server just sends another Reply-PSID for each new TN3270 client that gets coupled to that LU.
The CIP TN3270 server allows both methods to be used. The first requires an LU definition for the desired LOCADDR in the SWNET major node definition. The second requires an absence of such a definition, and the LUSEED and LUGROUP parameters must be specified on the PU macro.
A: No, because a 3820 is a type 1 device, and no Function Management Headers (FMH) are allowed for type 1 or type 3 devices.
A: For clients who want SNA Character String SSCP-LU dialog, yes, these message tables work. For traditional TN3270 clients, a 3270DS USS10 message table is required. You need to create a new Unformatted System Services (USS) table:
Copy the source file from the original file name to a new name.
Insert 3270DS Write() commands before each display line.
Make sure the cursor is placed where you want it.
Assemble the new USS table in accord with your VTAM environment.
Edit the switched and LUGROUP major node definitions, so they point to the new USS10 table (for LUs/LU-models, which expect 3270DS SSCP-LU dialogs).
A: The CIP TN3270 Server requires the USS10 to be coded in the correct datastream for the client: SCS for those TN3270E clients (such as printers) that request a BIND image and 3270DS for all other clients.
In order to assist in this, the model string that is sent in the reply PSID indicates the datastream. If you want SCS, the fifth character of the model string is "S," for example, 3279S5 instead of 327905. The LUGROUP model statements must be coded accordingly:
SSCPFM=USSSCS,USSTAB=<scs USS10> for "S" entries
SSCPFM=USS3270,USSTAB=<3270ds USS10> for non-"S" entries
Remember to allow for the screen position taken by an attribute in the 3270DS USS10.
A: A CIP slot of 1 is assumed, where you know the PU is foo, and the LOCADDR of the hung LU is 3; enter these show commands on the router:
sho ext channel 1/2 tn3270
sho ext channel 1/2 tn3270 pu foo
sho ext channel 1/2 tn3270 pu foo lu 3 history
Send the output (along with output from wr t, sho contr cbus, sho diag, and sho ver) to the Cisco Technical Assistance Center (TAC).
Note: This can be done after the LU is discovered to be in a hung state. In really tough cases, the Cisco engineer still needs the problem scenario recreated with the CIP TN3270 trace turned on. Here is how to do this:
Telnet to the router and enable privileged mode. Ensure you capture the output of the Telnet session to a file.
If you are not on the console port, issue the term mon command.
Get the test environment set up to the point just before the LU login.
Determine what slot the CIP card is in (call it slot <x>), then issue the if-con <x> c command.
Issue these commands:
tn3270 capture reset
tn3270 capture ip <client ip address>
Recreate the problem. The trace data is logged to the console/Telnet session.
When finished, issue these commands at the router to turn off all tracing:
if-con <x> c
tn3270 capture reset
if-quit
! only if not at console
term no mon
Send output of the trace to the Cisco TAC.
A: The TN3270E client software most often determines how to print to a LAN print queue. For Windows, Win95, and Windows NT platforms, this is how to print to LAN printers: the client prints to the Windows printer-driver, which then spools to the LAN printer, either through a network print-queue or an LPTx printer-device redirect.
It is probably best to have one TN3270E printer connection per LAN printer (or per LAN print queue, if the two are not the same). For example, this situation dictates what the TN3270E printer topology looks like:
Host-based printer software
Mapping of user application-profiles to printer queues
Actual end-user requirements
A: CIP CPU is the bottleneck, whether you operate through a channel or Token Ring if MAXOUT is large enough for the Token Ring path length. This is particularly important for session-switch because there are more LU-LU sessions per link.
For example, look at this on the CIP, as well as the comparable parameters on the front end processor (FEP):
conf t
int ch x/2
llc2 local-window 20
Also look at MAXDATA and MAXOUT wherever appropriate. For example, make sure that no bridge imposes a small segment size. In addition, if the CIP manages 150 transactions per second and each transaction is about 4 KB of data, that is nearly 5 Mbps on the Token Ring. If there are other CIPs on the same Token Ring, even a 16 Mbps Token Ring could be the bottleneck.
A: With TN3270E, the client has the ability to specify an LU. If you use TN3270E client software for all end-stations that need specific LU access, specify the LU name in the client-software configuration. With TN3270, this is possible if you devote a PU and server IP address to each LU to be mapped statically to a client IP address. This is known as IP Address Nailing or IP Address-to-LU-Name Mapping, and was first supported in Cisco IOS® Software Release 11.2BC and 11.3T, as well as now in the 12.0 and 12.1 releases.
A: First, a walk through the definition of a specific LU:
Determine whether or not your site uses a Dependent LU Requester (DLUR) or SNA session switch or not. If an SNA session switch is in use, the CIP TN3270 Server learns the LU name from VTAM when the ACTLU is presented. Otherwise, the CIP TN3270 Server uses the "LU-seed" parameter as the "stem" of the LU name with the same algorithm as the host does with the VTAM LUSEED parameter. For instance, consider this PU statement:
pu TN3PU01 05D19001 172.18.4.210 token-adapter 0 70 lu-seed T3P01T##
If this statement is used, TN3270E clients use a DEVICE-NAME (or whatever your client software calls the LU-like name on the session configuration panel) of T3P01T45 when it attempts to connect to LOCADDR 45 (hex).
Configure the client as mentioned.
In the switched PU major node definition, add the specific LU to the PU definition. For instance, if the PU definition was this:
TN3PU01 PU ADDR=01, X
IDBLK=05D, X
IDNUM=19001, X
ISTATUS=ACTIVE, X
MAXPATH=1, X
PUTYPE=2, X
LUGROUP=TN3LUGRP, X
LUSEED=T3P01T##
Add this to this line (in this case, a printer):
T3P01T45 LU LOCADDR=69,MODETAB=RSCSTAB,DLOGMOD=RSCSPRT1, X
LOGAPPL=
Remember that the LOCADDR parameter in the switched major node is always decimal. In order to connect to LOCADDR 45 (hex), define LOCADDR=69 for the LU.
Activate the PU (with new definition) and test it out.
Note: The LU names (in the case of non-SNA session switch) do not need to be the same as on the host VTAM definitions; it is just easier to keep track of things.
If you run the DLUR feature of TN3270 server, the VTAM names are automatically passed to the router on LU activation. In VTAM 4.4 and the example, IBM introduced the INCLUD0E parameter in the Switched Major Node PU definition, which tells VTAM to pass the names of the dynamically created LUs to the router for non-DLUR PUs as well, so it is no longer necessary to do this.
A: Yes, you can use Hot Standby Router Protocol (HSRP) provided that you also use DDDLU at the host. If you use static LUs (not DDDLU, and the TN3270E client asks for LU by name), it does not work. The LU in question can be active at only one of the CIPs, so you have to be sure that HSRP directs the client to that CIP.
If the host or channel fails, the TN3270 server discovers that its PUs are inactive. That stops the TN3270 server from listening for connections, but it does not tear down the TCP/IP stack. Pings are still answered.
Another issue is what happens when nothing has failed. The same PU is defined on multiple CIPs, which try to connect. The host accepts the first (with a given IDBLK/NUM) and rejects the rest. This leads to error messages once every few minutes.
A worse problem can occur when there are multiple PUs on the one IP address in the CIP. Suppose CIP 1 and CIP 2 each have one IP address, but with PU A and PU B configured on it on each CIP. All four PUs try to connect to the host. If PU A succeeds on CIP 1, and PU B succeeds on CIP 2, both IP addresses listen for connections, which leaves HSRP no way to choose the right one.
One way around all these issues is to keep the backup PUs in a shutdown state on the CIPs. When they are required, issue no shut commands. With Native Service Point (NSP) on CIP, this can be automated from the host.
A final option is to use different IP addresses on the CIP (and different PUs) for the static and dynamic LUs. Use HSRP to reach the PUs with dynamic LUs but not those with static LUs.
The ability to print over an IP network without the need to change the MVS applications.
The ability to use the same print driver system (in our case, VPS) and the same print-queue to LU mapping that I have on a conventional SNA setup.
The ability to put a job on a queue from batch mode job control language (JCL) from TSO or CICS (any valid LU-LU terminal session), and over an NJE (JES to JES) or Remote Job Entry (RJE) connection.
A: These are the answers to the different parts of your question:
Printer-driver system: Yes, as long as your printer-driver system drives a type1 or type3 LU (see noted restrictions), you can keep it. Certainly you should not have to make non-trivial changes to the VPS system.
Job entry subsystem (JES) queues: This works fine.
RJE connections: Remote Job Entry connections use frequency modulation headers (FMH). Both TN3270 and TN3270E do not permit FMH, so RJE is unsupportable.
SNI access: The TN3270 server terminates the SNA part of the connection at the CIP. Yes, Cisco supports subarea routing in that, and SSCP provides subarea routing on behalf of the CIP. We also support APPN-based routing as a DLUR end-node.
Note: With most TN3270E client implementations, some of the ability to detect printer conditions is taken away. Most of the clients do not report status as per RFC 1647 (TN3270E). This lack of detail is because (in the typical Windows TN3270E client case), the TN3270E client does not actually know the real status of the printer. In this scenario, the TN3270 clients simply dump the print job into the local or network-defined print queue.
A: All PU parameters (which include the SSCPFM parameter through which VTAM interprets the inbound data from the clients) in the switched major node only sift down to static (specifically configured) LUs. For DDDLU, all the parameters must be specified on the LU model statements under the LUGROUP.
MVS, two partitions
LPAR1 LPAR2
! ! ! !
! ! !--------! !
! !--!-------! !
! ! ! !
7513/CIP1 7513/CIP2
FDDI and Token Rings
These apply to the diagram:
There is a CIP with one Enterprise System Connection (ESCON) connection in each Cisco 7513. LPAR1 is production; LPAR2 is production, test, and backup for production applications.
These applications run on LPAR1: NVASPROD, CISCPROD, and so on. These applications run on LPAR2: NVASTEST, TSOPROD, TESTAPP1, and so on.
Direct PU must be used.
A typical user has IP access to both 7513s and logs on to NVASPROD on LPAR1. From NVASPROD, the user typically chooses CISCPROD or TSOPROD.
NVASPROD is a real LU-LU application. For the rest of this information, just assume that it is a real LU-LU application.
A: Local Director can be used to load balance session between two TN3270 servers.
A: See this scenario. In the case of a failure, Local Director directs all traffic to the active CIP. This applies only to non-named LUs. PUs that contain named LUs run by CIP1, which must be manually turned on at CIP2 by the operator once the CIP1 failure is recognized. This implies that you must configure all PUs used by the TN3270 server to have either named LUs or generic LUs, but not both.
If something happens to LPAR1, the production applications are moved to LPAR2, as in NVASPROD and CISCPROD.
A: See this scenario. Yes, if you define a switched major node definition at LPAR2 that contains PU definitions that allow users to access NVASPROD and CISCPROD. This switched major node definition is not normally activated. Also, define (actively) comparable definitions for these PUs in CIP2 and CIP1. Within normal operation, these PUs are not active because the major node at LPAR2 has not been activated. When LPAR2 takes over the NVASPROD and CISCOPROD applications, the operator also activates the switched major node that contains those extra PUs. CIP1 and CIP2 can now connect-in and activate those PUs, which they do automatically.
A: Free-form LU-level naming is not allowed; LU naming based on an algorithmic scheme (known informally as the LUSEED scheme) is allowed.
You can achieve a LOCADDR naming with a lu-seed parameter value in the PU configuration statement. This is how router PU configuration statement appears:
pu GENPU 05D18001 172.22.13.3 token-adap 0 70 lu-seed GENLU###
The VTAM switched major node definition must have the same LUSEED parameter within the PU definition; this assume that it also has two specific LUs (SPEC100 and SPEC101) defined underneath it.
Now suppose that PU configuration is in use. A client that wants to connect to LOCADDR 101 of the PU has this session configuration:
[generic names...your client software names may vary from this]
HOST_IP = 172.22.13.3
RFC1647_DEVICE_NAME = GENLU101
The fact that VTAM names the LU SPEC101 is immaterial; the CIP TN3270 server maps the name given by the client to a LOCADDR with the lu-seed map (for non-SNA-session-switch-based PUs).
This is the way that the CIP TN3270 server software works: LU names cannot be configured on a free-form LU-by-LU basis through the CIP TN3270 server configuration commands. They are configured one of two ways:
If the PU is defined within the context of the TN3270 server DLUR configuration mode, the LU names associated with that PU are configured at the time of the ACTLU, when the host sends the name of the LUs to the DLUR node.
If the PU is defined directly (such as not under the DLUR configuration mode), the LU names are configured through the lu-seed algorithm.
A: Use DNS, Local Director, Distributed Director, and sometimes HSRP as appropriate ways to solve this problem.
A: Yes.
A: TN3270 uses about 90K per connection. Xremote uses about 60K per user, plus about another 2K for each window (TCP connection).
All contents are Copyright © 2006-2007 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.
| Updated: Mar 06, 2007 | Document ID: 12263 |