The SNA gateway supports:
Refer to Quick Beginnings for instructions on how to configure the SNA gateway using SNA Node Configuration.
The SNA gateway supports workstations connected by:
The SNA gateway can support as many as 254 LUs for each defined PU. You can define a different PU for each of your host connections. The LUs are used by the downstream workstations to connect to the host. The number of downstream workstations supported is dependent on several factors, including the type of connectivity and the number of adapters on the gateway. For instance, if you have one LAN adapter on the gateway, one host link with 254 LUs can be used by 253 downstream workstations concurrently. With two adapters, you can double the number of downstream workstations.
You can choose to connect using SDLC in point-to-point and Multipoint configurations. After configuration has been completed, no special consideration is necessary to run SDLC between the workstation and the gateway.
When setting up multidrop secondary workstations, consider the various factors that control polling turnaround time. There are physical limitations that affect how quickly the primary can poll the secondary that is farthest away. Defining all of the secondary workstations using the same parameters will simplify the following calculation.
To calculate the minimum inactivity time in seconds, use this formula:
NS * (SW + RW) * (IS + 2) / (LS / 8) where: NS = Number of stations SW = Send window size RW = Receive window size IS = I-field size LS = Line speed (bps)
If these values are not the same for all secondary workstations, a separate computation must be made for each group or workstation and added together to find the correct value for the inactivity timer.
For example, for a multidrop link with 16 secondary workstations at 14.4 Kbps, with each workstation set for a send window size of 7, a receive window size of 7, and I-field size of 521, the calculation for the inactivity timer would be:
16 * (7 + 7) * (521 + 2) / (14400 / 8) = 65.1 seconds
|Note:||Always add a few extra seconds for a buffer.|
If you configure the SNA gateway to use only X.25 permanent virtual circuit (PVC) connections between the gateway and the workstations, it is recommended that you configure all the workstation and gateway PVCs with negotiable link station roles. If you do not configure the gateway and workstation PVCs with negotiable link station roles, the workstations might not be able to establish the X.25 PVC links to the gateway.
See Chapter 13, "Planning for X.25" for more information about PVC connections and the configuration.
The SNA gateway supports the following connections to a host:
If there are connections to multiple hosts from the gateway being used by dependent LU traffic, only the host link with the control point PU name can do the following:
The links that are defined with a PU name that is not the same as the control point name can be used only for additional dependent LU connections to a host.
If a gateway host link is defined as a limited resource link, it will send a request discontact to the host after the last LU-LU session is unbound. The gateway then passes the DACTLUs to the workstation and a DACTPU to workstations that have sessions only with that host link. When the workstation connected to the gateway is defined as a limited resource, the workstation link is disconnected if there are no other sessions. In Communications Server you can designate a workstation as a limited resource when defining the explicit client connection.
However, if the workstation has an application (or emulator) that automatically reactivates its host link, the gateway will reactivate the gateway link to its host when the workstation activates its link to the gateway. This means that incompatible workstation definitions would effectively inhibit the limited resource function at the gateway.
Consider the following things when planning for your host connection:
When a nonzero value for DELAY is specified, this saves the host processor instructions at the expense of increased receive response time on the Communications Server workstation.
For coattailing, begin with default value 0.2. A 0.2 second delay has a moderate effect on response time, but if the rate is approximately one transaction per second or greater, coattailing occurs.
If your host VTAM supports self-defining dependent LUs (SDDLU), you might want to take advantage of the function. When configuring host LUs, specify an LU model type or provide an LU model name that matches the LUSEED operand value defined in the VTAM switched major node and used by the VTAM SDDLU exit routine.
You need to provide a destination address if you use one of the supported LAN connections between the gateway and the host or between the gateway and an explicitly defined workstation. When determining the correct destination address to enter in each profile, remember that the proper perspective for both addresses is to view the destination from the SNA gateway. Figure 28 shows this view.
Figure 28. Perspective to Use for Destination Address Entries
The SNA gateway supports both pooled host LUs and dedicated host LUs. When LUs are configured for each host connection at the SNA gateway, they can be grouped into pools. Creating pools is often beneficial for the following reasons:
Pooled LUs are not dedicated to any particular workstation, nor do they have to be dedicated for use by only downstream gateway users. A single pool can be shared by downstream TN3270 users and SNA gateway workstations, as well as SNA API clients and local emulator sessions. If you want to configure one pool (for example, PUBLIC) for all dependent LU uses, you do not need to know how the users will be distributed across those types.
Consider the following scenarios:
The SNA gateway assigns pooled LUs to workstation sessions when the downstream workstation connects to the gateway. The workstation sessions can be defined to use LUs on different hosts with either dedicated or pooled LUs.
Dedicated LUs do not belong to a pool. A dedicated LU can be configured for use by an explicitly defined client.
Figure 29 shows a simple configuration with workstations using dedicated LUs, pooled LUs, or both. (The connecting lines represent the LUs.)
Figure 29. A Simple Scenario Using Pooled and Dedicated LUs
There are two types of gateway-supported downstream workstations: explicit and implicit. Explicit workstations are workstations that have defined destination addresses over a particular DLC type (for example, token-ring network and SDLC). To configure explicit workstations, you must know the destination address or fully qualified adjacent control point name or adjacent node ID of each workstation and also define a logical link to the gateway for each workstation. LUs that are defined for explicit workstations can be pooled or dedicated.
Implicit workstations are easier to configure, but they can use only pooled LUs. Instead of defining a link to each workstation using the gateway, define a host LU pool (or pools) and configure the devices (DLCs) used by the workstation connections. Configure an implicit client template to be used as a model for LU definition for each workstation that connects to the gateway and does not match an explicit definition. For example, if each workstation in an Ethernet LAN has two 3270 sessions configured with NAU addresses 2 and 3, you would configure a client template with two LUs (one for address 2 and one for address 3). If both addresses are used for sessions to a single host, map both addresses to the same host pool. If however, address 2 is used to go to HOST_A and address 3 is used to go to HOST_B, map each to the appropriate host pool. In this example, each time a workstation connects to the gateway over Ethernet, which does not match an explicit definition, a link is dynamically created and the two LUs for NAU 2 and 3 are allocated from the host LU pool(s).
For implicit workstations, users connecting to the gateway need to know only the adapter address of the gateway DLC that is configured for the implicit workstations and what NAU values have been defined on the gateway. They must use these NAU values when defining their 3270 sessions and logical printers.
A downstream Personal Communications workstation connecting to Communications Server can use LAN discovery, searching for the group name IGO2HOST, to find the adapter address.
Performance through any gateway is dependent upon many factors, including:
Using a workstation that implements a software gateway for other functions can also impair the performance of the gateway.
If none of the previously mentioned factors is causing a negative impact on performance, an individual workstation using supported SNA protocols should not experience any noticeable performance difference between a direct connection to the host and an indirect connection by way of a LAN through an SNA gateway connected to the host. In fact, if the host links are active at the gateway, the workstation activation might improve by removing host overhead delay. However, because of the many variables involved, you might want to conduct performance tests in your operational environment so that you can attain the desired balance between function and performance.
By using DLUR for the connection to the host, you gain flexbility in where the SNA gateway can be placed. The connection to the host can traverse any APPN network, and is not restricted to being adjacent to a HOST/NCP. A DLUR to DLUS pipe is created to the DLUS VTAM that is used for dependent session control flows.
The recommended configuration for having a DLUR connection to the host is to define the gateway to be a network node and configure the DLUS information. During configuration of the explicit and implicit clients, map them to the DLUS. This configuration is easiest because it requires no knowledge of the downstream LUs at the gateway and it provides the highest visibility of the downstream devices to VTAM, since VTAM is aware of the PU.
If you do not want VTAM to be aware of the downstream PUs, you can configure an internal PU at the gateway (rather than a host connection), and map the downstream workstations to that internal PU.
If a downstream workstation, such as Personal Communications, is DLUR-capable, you might want that workstation to route through the Communications Server using the network node capability rather than the SNA gateway function.