|
|
|
|
Node resources define the communications capabilities of the APPN node, including connectivity resources (ports and link stations), LUs (type 0-3 for 3270, NDMA, RJE, LU0, and LUA communications, and type 6.2 for 5250, APPC and CPI-C communications), modes, and directory information.
Domain resources are available to all of the SNAP-IX systems in the local network; such resources are used to support particular user programs. Domain resources include RJE workstation definitions, 3270 user information, CPI-C side information, and information about access to the UNIX command facility and the service point command facility.
In some cases, the SNAP-IX Motif administration program or the Web administration program simplifies the presentation of resources (as compared to the command-line administration program). You do not need to know what these differences are unless you intend to use both the Motif (or Web) and command-line programs. In this case, details can be found in SNAP-IX Administration Guide.
The following resources can be defined on individual nodes:
A port represents the local end of a communications link as a unique access point in the network.
Each port is associated with a specific link protocol, which can be any of the following:
SNAP-IX Channel Attachment is a separately installed feature that provides communication links to IBM System/370 and System/390 host computers. It bypasses front-end processors (also known as communication controllers, or SNA type 4 nodes), providing connections directly from the host channel to the Solaris workstation.
Additionally, SNAP-IX Channel Attachment can be used in conjunction with PU concentration. This provides channel connectivity to the host for downstream LANs or WANs.
More than one port can be associated with a particular link protocol.
In general, a port corresponds to a single physical access point, such as an adapter card. However, for some link protocols (such as token ring), you can define multiple ports for a single adapter. In this case, the different ports are distinguished by addresses such as the SAP number.
A link station (LS) represents the logical path through the SNA network between the SNAP-IX local node and a remote computer. The remote computer can be any of the following:
A host computer
A peer computer, with SNAP-IX and the remote computer communicating as equal partners (the typical arrangement in an APPN network)
A downstream computer that uses the SNAP-IX PU concentration or DLUR features to access a host
A link station is associated with a specific port; one or more link stations can be associated with each port.
Each link station has an associated PU (physical unit). Because such PUs are associated with link stations, SNAP-IX does not treat them as separate resources; they are configured as part of link station configuration, and started and stopped as part of starting and stopping link stations.
If a remote node attempts to connect to the local node, and a suitable port is defined on the local node, but no link station is defined that matches the address specified on the incoming call, SNAP-IX can define a dynamically created link station for the duration of the connection.
In addition, SNAP-IX provides support for Rapid Transport Protocol (RTP), a High-Performance Routing (HPR) feature of APPN. RTP enables you to reroute session traffic around route failures or congestion.
In an APPN network, an end node is often connected only to a single network node, and each network node is connected only to its nearest neighbors. Any node in the network can communicate with any other node, even if there is no direct connection between them, because the communications path can be established through the intermediate nodes.
If all the end nodes and network nodes are connected to the same Enterprise Extender (HPR/IP), token ring or Ethernet network, there is 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). However, to enable direct communications between two nodes, you need to define link stations between every pair of nodes; this results in a very large number of link station definitions if you want to enable any two nodes on the SATF to communicate directly.
APPN enables you to set up this type of configuration without having to define each link station explicitly, by defining a connection network 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. All nodes on the connection network use the same VRN name.
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; no additional configuration is necessary.
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.
An LU is the node's point of contact with a user program (3270 emulation program, RJE workstation, APPC TP, CPI-C, LU0, or LUA application). LUs are divided into the following categories:
LU types 0-3 (sometimes referred to as old LUs
) are used to communicate with hosts using 3270 emulation,
RJE, LU0, or LUA.
LU type 6.2 is used to communicate with either hosts or peer computers using APPC or CPI-C.
Type 0-3 LUs are referred to as dependent LUs.
They can support only one user
session at a time. The user 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 that use older versions of SNA host software.
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.
They
can support multiple user sessions simultaneously.
SNAP-IX supports the following type 0-3 LUs:
Display LUs support 3270 display sessions, with the models representing different screen sizes:
Model 2 - 80 x 24
Model 3 - 80 x 32
Model 4 - 80 x 43
Model 5 - 132 x 27
Printer LUs support printer sessions:
3270 printer
SCS printer
RJE model LUs support RJE workstations.
Unrestricted LUs support LU0, LUA, NDMA, and upstream LUs that provide host communication with downstream LUs through PU concentration.
LUs can also be grouped into LU pools. A user session can be assigned to a pool of LUs, rather than to a specific LU, so that it can use any available LU within that pool.
A mode specifies a set of characteristics that a local LU (type 6.2) uses to communicate with its partner LU. These characteristics include information on the way data is transmitted between the two LUs (such as maximum RU lengths and pacing window sizes), and on whether the LUs can establish parallel sessions.
In addition, you might need to specify requirements for the communications path between the LUs, such as enforcing a certain level of network security, minimizing transmission time, or avoiding the use of expensive communications links. These requirements can be defined using a class of service (COS), which specifies minimum and maximum acceptable values for characteristics such as transmission time, transmission cost, and network security, and weightings associated with different ranges of these values. The COS definition enables the node to calculate the best route across the network when two or more routes to the same remote LU are available.
If the SNAP-IX node is a network node, the definition of each mode includes the name of the required COS for that mode. If the SNAP-IX node is a LEN node or end node, you do not need to associate a COS with the mode; the COS name is determined dynamically.
SNA defines a number of standard modes and associated COSs that cover the requirements of most systems; in general, you do not need to define additional modes and COSs.
SNAP-IX includes end user applications, as well as application programming interfaces that you can use to write your own applications. SNAP-IX supports the following end user applications:
3270 emulation program
5250 emulation program
NDMA
RJE workstation daemon
APPC transaction programs
CPI-C applications
APPC Application Suite
LU0 applications
LUA applications
UNIX command facility
Service point command facility
These are all user-space programs. SNAP-IX supports multiple copies of the 3270 emulation program and multiple APPC TPs, CPI-C applications, LU0 applications, and LUA applications, running concurrently.
SNAP-IX provides the following user applications:
SNAP-IX provides 3270 emulation software that lets users log on to and use IBM host systems from Solaris computers. Using this software, a user can transfer files between the local and host computers, and control display and printer emulation sessions. A user can also customize some of the 3270 emulation features, such as key mapping and display attributes, and store them in the style file that is used to initialize an emulation session. SNAP-IX 3270 emulation also enables users to run HLLAPI applications.
The 3270 emulation program uses the node's type 0-3 LU resources. In addition, SNAP-IX requires definitions for the 3270 users on the system, identified by their login IDs, and the 3270 sessions available to them. User and session definitions for 3270 emulation are configured in the domain configuration file.
The 3270 emulation program is available in both Motif and character-based versions.
The Motif 3179G emulation program provides IBM 3179G graphics display emulation.
SNAP-IX provides 5250 emulation software that lets users log on to and use IBM AS/400 systems from Solaris computers. Using this software, users can control display and printer emulation sessions. Users can also customize some of the 5250 emulation features, such as key mapping and display attributes.
The 5250 emulation program uses the node's type 6.2 LU resources. In addition, SNAP-IX requires definitions for the 5250 users on the system, identified by their login IDs, and the 5250 sessions available to them. User and session definitions for 5250 emulation are configured in the domain configuration file.
SNAP-IX provides support for Remote Job Entry (RJE), enabling users to submit jobs to an IBM host computer for processing. The RJE workstation daemon is the SNAP-IX component that handles transfer of jobs to the host, as well as the output returned from the host.
Users can prepare jobs for submission to the host and add them to the queue for an RJE workstation at any time, regardless of whether the RJE workstation is running. When the workstation runs, it submits to the host any outstanding jobs, in the order in which they were submitted. It also routes to the appropriate destination any output received from the host, as determined by the configuration.
The RJE workstation uses the node's type 0-3 LU resources. In addition, SNAP-IX requires definitions for the RJE workstations on the system. RJE workstation definitions are configured in the domain configuration file. In addition to the SNAP-IX configuration, the operation of the workstation is controlled by a workstation style file, which is maintained by the users of the workstation.
The optional NetView DM Agent package can be used to access NetView DM on a host system, to manage Solaris files from the host. An administrator can use this agent from a host system to create and delete Solaris files, to transfer data between host files and Solaris files, to send operator messages to the Solaris operator, and to send shell scripts from the host and run them on the Solaris system.
APPC Application Suite provides SNA equivalents of common TCP/IP applications such as ftp and ping. APPC Application Suite can be used to provide support for operations, such as file transfer, that are frequently performed across a network.
For more information, refer to SNAP-IX APPC Application Suite User's Guide.
SNAP-IX supports applications written to the following APIs:
APPC applications use the node's LU type 6.2 resources to communicate with another APPC or CPI-C application on a host or peer computer, using a specified mode. The APPC API includes TP server support, enabling applications to have greater control over starting transaction programs (TPs) and distributing conversations to those TPs.
CPI-C applications use the node's LU type 6.2 and mode resources to communicate with another APPC or CPI-C application on a host or peer computer. A CPI-C application requires the same resource definitions as an APPC application. In addition, a CPI-C application can have side information entries that provide information about partner TPs, the LU and mode resources used to access a partner, and any security information required.
As well as the standard C-language CPI-C API, SNAP-IX also includes a CPI-C API for use by Java applications. For more information, refer to SNAP-IX CPI-C Programmer's Guide.
HLLAPI applications interact with the 3270 emulation program to automate standard 3270 tasks.
LUA applications use the node's type 0-3 LU resources to communicate with a host application. LUA operates with all the LU types 0, 1, 2, and 3, including access to the SSCP session as well as the LU session.
No additional resource definitions are required.
LU0 applications use the node's type 0 LU resources to communicate with a host application. LU0 provides a simple and easy-to-use interface, but operates only with LU type 0 and does not provide access to the SSCP session.
No additional resource definitions are required.
MS applications provide Management Services functions for network management. An application can be either NMVT-level or MDS-level, depending on the type of MS data it sends and receives. SNAP-IX performs any data conversion that is required.
NOF applications administer SNAP-IX configuration and management resources.
Applications use Common Service Verb (CSV) verbs to provide utility functions such as character translation and application trace control.
The APIs for APPC, CPI-C, LUA, and CSV are included both on SNAP-IX servers and on Solaris and Windows clients. LU0, HLLAPI, Java CPI-C, NOF and MS APIs are only available on Solaris systems (both servers and clients). Many third-party Windows emulation programs supported by SNAP-IX include HLLAPI support.
For more information, see Client/Server Support.
On Solaris systems, applications using the SNAP-IX APIs can be compiled and linked to run in either 32-bit mode or 64-bit mode.
Passthrough services support communication between a host and computers on a LAN, making it possible to reduce the number of communication links to the host and simplify configuration. In addition, the TN server feature can provide access to TN3270 users in a TCP/IP network.
Normally, a dependent LU session requires a direct communications link to the host computer. If many nodes (including a host node) are connected together in an APPN network, some of them might not have a direct connection to the host, but only an indirect connection through another node; it is not possible to establish dependent LU sessions to the host from these indirectly connected nodes.
Dependent LU requester (DLUR) is an APPN feature designed to overcome this limitation. DLUR on an APPN node (such as a node running SNAP-IX) works in conjunction with dependent LU server (DLUS) at the host, to route sessions from dependent LUs on the DLUR node across the APPN network to the DLUS host. The route to the host can span multiple nodes, and can take advantage of APPN's network management, dynamic resource location, and route calculation facilities. DLUR must be available on the node where the LUs are located, and DLUS must be available on the host node, but there is no need for DLUR to be available on any intermediate nodes in the session route.
If the SNAP-IX DLUR node is a network node, it can also provide DLUR facilities for dependent LUs on downstream computers connected to the SNAP-IX node. These LUs can use DLUR on the SNAP-IX node to access the host across the network, in the same way as for LUs internal to the node.
Normally, a dependent LU session requires a direct communications link to the host computer. However, a node running SNAP-IX that has a direct communications link to the host can also provide PU concentration facilities to LUs on downstream computers, enabling them to access the host over the communications link from the SNAP-IX node.
The downstream computer must contain an SNA PU type 2.0 or 2.1 to support dependent LUs at the host. For example, it could be another computer running SNAP-IX in a stand-alone configuration.
An example of a node providing PU concentration is shown in PU Concentration Linking Multiple Downstream Workstations to a Host Computer.
When PU concentration is used, all the data transferred between the host and the downstream computer is routed through the SNAP-IX local node. This enables a downstream computer to share a host connection with SNAP-IX or with other downstream computers, instead of requiring a direct link. For example, you can set up several downstream computers connected to SNAP-IX over a local token ring network, so that they all access the same long-distance SDLC leased line from SNAP-IX to the host.
Using PU concentration also simplifies the configuration at the host, because there is no need to define the downstream computers and the communications links to them. The host configuration needs to include only the SNAP-IX computer and its host communications link; the LUs at the downstream computers are configured as part of the resources of the SNAP-IX computer. The host computer is not aware that PU concentration is being used.
3270 emulation programs that communicate over TCP/IP (rather than over
an SNA network) are referred to as TN3270 programs
(Telnet 3270 emulation programs).
TN3270 programs can also include support for TN3270E (Telnet 3270 standard extensions). TN3270E supports 3270 device emulation (including both terminals and printers) using Telnet. It enables a Telnet client to select a particular device (by specifying the LU name), and provides enhanced support for various functions, including the ATTN and SYSREQ keys and SNA response handling.
This book uses the term TN3270 to refer to information that applies equally to the TN3270, TN3287, and TN3270E protocols.
SNAP-IX TN server provides access to 3270 host computers for TN3270 users on other computers. TN server enables TN3270 users to share a host connection with SNAP-IX or with other TN3270 users, instead of requiring a direct link. TN server also enables TN3270 users to access hosts that are not running TCP/IP.
The SNAP-IX TN server function is shown in TN Server.
TN server provides an association between a TN3270 user and a 3270 LU on the SNAP-IX server. All data from the TN3270 user is routed to the LU. This means that the configuration for both the host and the TN3270 user is as though they were connected directly; neither needs to be aware that data is being routed through TN server.
SNAP-IX TN server supports all TN3270 client emulation programs that correctly implement the protocols defined in RFCs 1123, 1576, 1646, and 1647. The separate SNAP-IX TN3270 product supports 3270 and 3179G emulation over a TCP/IP network.
Computers running SNAP-IX can be configured to communicate using client/server
protocols. When client/server protocols are used in a network, all the computers
using client/server protocols to communicate in that network are referred
to as a domain.
Each computer in the network specifies the same domain name when SNAP-IX is installed.
The computers running SNAP-IX in a client/server configuration can take the following roles:
A server contains an SNA node and its associated connectivity components. The server provides SNA connectivity to applications on the local system or on other machines in the same domain. Servers must be Solaris systems.
A client does not contain SNA node components, but accesses them through a server. A client can access one or more servers at the same time, and can run concurrent applications as needed. Clients can be running Solarisor Windows.
Servers and clients communicate across the SNAP-IX domain using TCP/IP. The protocols used are different from those used by TN3270 and support a wide range of applications, including 3270, 5250, RJE(Solaris clients only), and applications using the SNAP-IX APIs.
You can have one or more separate SNAP-IX domains on the same physical network, using a unique name for each different domain. A single SNAP-IX domain can correspond to a TCP/IP subnet, can be part of a TCP/IP subnet (so that there are two or more separate SNAP-IX domains in the same subnet), or can span multiple subnets.
If the SNAP-IX domain has multiple servers, one server holds the master copy of the SNAP-IX configuration. This server is known as the master server. Other servers on the LAN can be identified as backup servers. The configuration is copied to backup servers-either when they are started, or when the master copy is changed-so that all backup servers hold a copy of the latest information.
A client computer does not contain an SNA node; it holds only the information it needs to access servers on the SNAP-IX LAN, and relies on a server to provide the necessary configuration information.
Most of the details of using Solaris clients are the same as those for a server, except that the client has no node resources to define and manage.
SNAP-IX enables machines running Windows 95 and Windows NT to act as clients in the SNAP-IX domain.
SNAP-IX provides API support for Windows clients. The following APIs are supported:
FMI (used by 3270 emulation programs)
APPC
CPI-C
LUA
CSV
All of these APIs are binary compatible with the WOSA APIs used by Microsoft SNA Server, so third-party applications supported by SNA Server (for example, 3270 emulation programs such as Attachmate Extra, NetSoft Dynacom Elite, and Wall Data Rumba) are also supported by SNAP-IX Windows clients.
For more information about managing Windows clients, refer to SNAP-IX Administration Guide. For information about Windows SNA APIs, refer to SNAP-IX Administration Guide or your Windows SNA product documentation.
|
|
|
 |
|