SNAplus2 Resources

The resources of the SNAplus2 system can be divided into the following types:

Node resources define the communications capabilities of a particular APPN node. The following are node resources:
- Connectivity resources including the following:
  DLCs
  Ports
  Link stations
  Connection networks
- Session resources including the following:
  LUs (types 0-3 for 3270, RJE, and LUA communications, and type 6.2 for APPC and CPI-C communications and for 5250 emulation)
  Modes and their associated classes of service
  Directory information
Domain resources are additional resources that are available to all nodes (not defined as part of a particular node) to support specific user programs. Domain resources include the following:
- 3270 user information
- 5250 user information
- RJE workstation information
- CPI-C side information
- Logging levels
- Information about access to the UNIX command facility and service point command facility

The following sections describe the various SNAplus2 resources, and explain how those resources work together to support each type of user program.




	NOTE: Some of the resources listed here do not appear in the Motif administration program, or are presented differently. These differences are indicated in the following sections where they apply.

Connectivity Resources

Connectivity to remote systems is supported by the following resources:

DLCs (see “DLCs”).
If you use the Motif administration program to configure a port, the corresponding DLC definition is created automatically. For command-line administration, the DLC is configured separately.
Ports (see “Ports”).
Link stations (see “Link Stations”).
Connection networks (see “Connection Networks”)
If you use the Motif administration program, you can define a connection network as part of port configuration. For command-line administration, a connection network is configured separately.

DLCs

A DLC is the component responsible for communication over a physical link (or multiple links) using a specific data link protocol, such as SDLC or token ring. Each DLC can manage one or more ports, as described in “Ports”.

SNAplus2 provides support for the following data link protocols:

Synchronous data link control (SDLC)
X.25 QLLC (qualified logical link control) , for which the X.25 communications software may be provided by your SNAplus2 supplier or by another supplier
Token ring
Ethernet (standard or IEEE 802.3)
FDDI (Fiber Distributed Data Interface)




	NOTE: In the Motif administration program, DLCs are not shown directly. The information required for configuring a DLC is displayed as part of the configuration of a port owned by the DLC.

Ports

A port represents the local end of a communications link as a unique access point in the network. In general, this corresponds to a single physical access point such as an adapter card. However, some link protocols (such as token ring) enable you to define multiple ports for a single adapter; in this case, the different ports are distinguished by addresses (such as the SAP address).

Each port is associated with a specific DLC. One or more ports can use the same DLC.

Link Stations

A link station represents the logical path through the SNA network between the SNAplus2 local node and a remote computer. The remote computer can be any of the following:

A host computer on which SNAplus2 accesses a host program using 3270, RJE, or LUA communications (or uses APPC or CPI-C for program-to-program communications)
A peer computer with SNAplus2 and the remote computer communicating as equal partners (the typical arrangement in an APPN network)
A downstream computer that uses the SNAplus2 PU concentration feature or DLUR feature as a gateway to access a host.

A link station is associated with a specific port. One or more link stations can be defined on the same port.

Connection Networks

Connection networks cannot be used by LEN nodes.

Nodes that are connected to the same token ring, Ethernet, or FDDI network have a direct communications path between all nodes, so that in theory any two nodes can communicate directly. Such a network is referred to as a shared-access transport facility (SATF).

The local node can have an explicit link station defined for its communication path to another node on the SATF, but enabling communications between every pair of nodes on the SATF requires a large number of link station definitions, and results in a large volume of network topology information flowing on the network.

APPN enables you to set up this type of configuration without having to define each link station explicitly, by defining a connection network (CN) that represents the SATF. For each node on the SATF, you define one or more ports used to access the connection network. Instead of defining a link station to each remote node, you specify the name of a virtual routing node (VRN) as part of the port definition.

You can think of the VRN as an imaginary node that represents all the other nodes on the SATF; you can give it any name you like, but all nodes on the SATF must use the same VRN name (and it must not match the name of any of the real nodes on the SATF). The local node can establish communications with any other node that has a port associated with the same CN, by accessing the VRN (which represents all the other nodes attached to the SATF), instead of requiring an explicitly defined communications path between each pair of nodes.

When two nodes on the SATF need to communicate and both have a port defined with the same VRN name, APPN can dynamically establish a direct connection between them; you do not need any additional configuration.

Because the connection is direct and does not need to go through any intermediate nodes, using a connection network reduces traffic on the LAN and improves performance. You should use connection networks wherever possible to take advantage of this.

You can define CNs for communications using token ring, FDDI or Ethernet DLCs.

To use this feature, you first define a DLC and port for each node that accesses the SATF, and indicate that the port should be defined on the connection network. You do not need to define any link stations; SNAplus2 sets up a dynamic link station to the CN (and hence to any port on it) when required.




	NOTE: In the Motif administration program, CNs are not shown as a separate resource, but are included as part of the configuration of SATF ports.

Session Resources

The following session resources are used by SNAplus2:

Logical units (see “Logical Units”)
Modes and their associated classes of service (see “Modes and Classes of Service”)
Directory information (see “Directory Information”)

Logical Units

An LU is the node's point of contact with a user program (3270 emulation program, RJE workstation, APPC TP, CPI-C application, or LUA application). LUs are divided into two categories:

Dependent LUs

Type 0-3 LUs are referred to as dependent LUs ; they can support only one user session at a time, and a session is controlled by the host program. Type 6.2 LUs can also be dependent LUs if they are used to communicate with host computers running older versions of SNA host software.

LU types 0-3 are sometimes referred to as “old LUs,” and are used to communicate with hosts using 3270 emulation, RJE,or LUA.

Type 0-3 LUs can also be grouped into LU pools, as described in “LU Pools”. In addition, dependent type 6.2 LUs can be assigned to default pools, as described in “Default LUs”.

Independent LUs

LU type 6.2 is used to communicate with either hosts or peer computers using APPC or CPI-C.

Type 6.2 LUs that are used to communicate with peer computers, or with newer SNA software on host computers, are referred to as independent LUs. Independent LUs can support multiple user sessions simultaneously.

Dynamic Definition of Dependent LUs

Dynamic definition of dependent LUs (DDDLU) is a host feature that enables dependent LUs on the SNA system to be added to the host configuration when the communication link from the SNA system to the host is established. With DDDLU, LUs do not have to be configured statically at the host. (You must still define dependent LUs on the SNAplus2 node.) This reduces the initial configuration required at the host, and makes later expansion easier.

SNAplus2 can communicate with both DDDLU-capable and non-DDDLU-capable hosts, with no difference in the configuration required. When the communications link from the SNAplus2 node to the host is established, a DDDLU-capable host informs the node that it supports DDDLU; the node then sends the required information to define the dependent LUs that use the link. If the host is not DDDLU-capable, SNAplus2 does not send this information; it assumes that the LUs have already been defined statically at the host.

LU Pools

Type 0-3 LUs can also be grouped into LU pools, so that a user session can be assigned to a pool of LUs. For 3270, RJE, and LUA applications, you can use LU pools to simplify configuration and give greater flexibility.

All of the LUs in a pool must be the same type. For example, you can define several 3270 display LUs in a single LU pool, then configure multiple 3270 display sessions using this LU pool. This makes configuring 3270 sessions easier and enables any 3270 session to use any LU in the pool.

LU pools can also span multiple SNAplus2 servers—just define LU pools with identical names on the different servers. Clients that use the LU pool can then use any server. This means that the clients can still be used if a server fails or is taken out of service. Using LU pools also simplifies client configuration and makes it easy to increase capacity by adding another server or by adding LUs on an existing server.

LU pools support the following operations:

Assigning LUs to users on a “first come, first served” basis when there are more users than LUs.
Balancing the traffic from user sessions across multiple servers or multiple host links, by defining a pool containing LUs on more than one node or on more than one host link.
Permitting access to more than one host system from the same configuration, so that if one host system becomes unavailable, sessions can still be established to another system without requiring reconfiguration.

Default LUs

If you are configuring type 6.2 dependent LUs for use with APPC or CPI-C applications, you may wish to define them as members of the default pool. The default pool can include LUs from more than one node. An application that does not specify a particular local LU is assigned an unused LU from the pool of default LUs.

An application requesting a default LU can be assigned to any of these LUs as available; the LU does not need to be on the same computer as the application. However, if you are defining partner LUs for the applications, the partner LUs must be defined on all nodes where default LUs are defined, so that the application can contact the correct partner LU using any of the default local LUs defined on any node.

Modes and Classes of Service

A mode specifies a set of characteristics that a type 6.2 local LU uses to communicate with its partner LU. These characteristics include information about the way data is transmitted between the two LUs (such as maximum RU size and pacing window sizes), and about whether the LUs can establish parallel sessions.

The definition of a mode can also include the name of a class of service (COS), which specifies minimum and maximum acceptable values for characteristics such as transmission time, transmission cost, and network security, together with weightings associated with different ranges of these values. This enables the node to calculate the best route across the network when two or more routes to the same remote LU are available. The configuration of the SNAplus2 node specifies whether the node performs explicit mapping between modes and COSs. If explicit mapping is not supported, you do not need to associate a COS with the mode; the COS name is determined dynamically.

Directory Information

APPN network and end nodes maintain dynamic directory information about remote nodes and partner LUs. In addition, you can configure such information directly. On a LEN node, you must configure directory entries for each partner LU. You can also configure such resources directly on an APPN end node or network node (for example, to eliminate the need for a network node to locate a frequently used resource).

Domain Resources

Information about domain resources such as 3270 users, RJE workstations, access to the remote command facility, CPI-C side information, and logging levels may be needed anywhere in the network. For this reason, only one definition is required for each such resource .