|
|
|
|
The components of SNAP-IX and their relationships are shown in Components of SNAP-IX.
The local node-including its associated connectivity resources (DLCs, ports, and link stations)-is implemented as a set of STREAMS components in the kernel of the Solaris system.
The 3270 emulation program, 5250 emulation program, RJE workstation, APPC transaction programs, CPI-C applications, LU0 applications, LUA applications, and the remote command facility (RCF) are user-space programs. SNAP-IX supports multiple copies of the 3270 and 5250 emulation programs, and multiple APPC TPs, CPI-C applications, LU0 applications, and LUA applications running concurrently.
A server running SNAP-IX implements an SNA node. It can also provide passthrough services between an SNA host and computers in an APPN or TCP/IP network.
SNAP-IX provides SNA node type 2.0 and 2.1 (LEN node) support for communicating with host and peer computers; it also implements an APPN node, providing end node, branch network node, or network node function according to its configuration.
SNAP-IX implements an APPN node to communicate with other nodes on the SNA network. This provides logical unit (LU) 6.2 support for APPC and CPI-C capabilities and for 5250 emulation, in addition to LU 0, 1, 2, and 3 support for 3270, RJE, LU0,and LUA communications.
SNAP-IXcan operate as any of the APPN node types (LEN, end, network, or branch network node), depending on its configuration. Certain functions are supported only on particular node types, as defined by the APPN architecture. These differences are indicated where necessary in this manual; where no differences are indicated, the information applies to all node types.
Passthrough services enable downstream computers on a LAN to access host resources through a server running SNAP-IX, or enable computers to access SNA resources across mixed SNA and IP networks. SNAP-IX provides the following passthrough services:
PU concentration (see PU Concentration).
Dependent LU requester (see Dependent LU Requester).
TN server (see TN Server).
Enterprise Extender (see Enterprise Extender (HPR/IP)).
In addition to providing direct access to a host computer, SNAP-IX can provide PU concentration facilities. This feature enables other computers to access a host computer through the SNAP-IX node, instead of requiring a separate connection to the host from each computer.
The PU concentration feature is shown in PU Concentration.
The downstream computer must contain an SNA PU type 2.0 or 2.1 to support dependent LUs. For example, the downstream computer could be a PC running Microsoft SNA Server for Windows NT, or another SNAP-IX computer.
When the local SNAP-IX node uses the PU concentration feature, all the data transferred between the host and the downstream computer is routed through the 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 could set up several downstream computers connected to SNAP-IX over a local token ring network, so that they could all access the same long-distance leased line from SNAP-IX to the host.
Using PU concentration also simplifies the configuration at the host, because you do not need to define the downstream computers and the communication links to them. The host configuration needs to include only the SNAP-IX computer and its host communication 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.
This section does not apply to LEN nodes.
In addition to providing direct access to a host computer, SNAP-IX can provide dependent LU requester (DLUR) facilities. This feature enables sessions for dependent LUs to span multiple nodes in an APPN network, instead of requiring a direct connection to the host.
DLUR on the SNAP-IX node works in conjunction with dependent LU server (DLUS) at the host. Together, they route sessions across the network from dependent LUs in 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.
If the local node is a network node, dependent LUs on downstream computers connected to the SNAP-IX node can also use passthrough DLUR on the SNAP-IX node-in the same way that LUs internal to the node do-to access the host across the network.
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 guide uses the term TN3270 for 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.
SNAP-IX TN server supports all TN3270 client emulation programs that correctly implement the protocols defined in RFCs 1123, 1576, 1646, and 1647.
The SNAP-IX TN server function is shown in TN Server.
The SNAP-IX TN server feature provides an association between a TN3270 user and SNAP-IX 3270 LU. 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.
When a TN3270 program communicates with TN server, SNAP-IX identifies the program by the TCP/IP address of the computer where the TN3270 program is running. SNAP-IX cannot distinguish between two different TN3270 programs being used by different users on the same computer. In the SNAP-IX manuals, the term TN server user refers to the computer where a TN3270 program is running, not to an individual user of that program.
Each TN server user is normally configured to access a single 3270 LU, and so is restricted to one host session at a time. However, you can also configure a TN server user to access a pool of 3270 LUs, instead of having a single dedicated 3270 LU for each user. This enables the user to access as many sessions as there are available LUs in the pool.
Enterprise Extender (HPR/IP) provides a mechanism for integrating SNA applications with an IP network.
SNA applications are designed to use SNA protocols to communicate over SNA networks with other SNA applications. When installed in a TCP/IP network using Enterprise Extender, SNA applications can still communicate; the Enterprise Extender function provides a mechanism for transporting SNA protocols over the IP network. In particular, it provides APPN High-Performance Routing (HPR) functionality, giving the applications the benefits of both APPN and IP connectivity.
Enterprise Extender in SNAP-IX is implemented simply as a communications link. To connect two SNA applications over IP, you define an Enterprise Extender link, in the same way as for any other link type such as SDLC or Ethernet.
SNAP-IX supports the following user applications:
3270 emulation programs (see 3270 Emulation).
5250 emulation programs (see 5250 Emulation).
RJE workstation daemon (see RJE Workstation Daemon).
NetView DM Agent (see NetView DM Agent)
APPC Application Suite (see APPC Application Suite)
You can use 3270 emulation software to log on to and use SNA host systems from your computer, control display and printer emulation sessions, and to transfer files between the local and host computers. 3270 emulation uses the node's LU type 0-3 resources.
To use 3270 emulation, you need to define the 3270 users on your system, identified by their login IDs, and the 3270 features available to each user or group of users. 3270 users and sessions are defined as domain resources, which simplifies the configuration required to support emulation across the domain.
The SNAP-IX 3270 emulation program provides session control and file transfer capabilities. In addition, you can customize some 3270 emulation features, such as key-mapping and display attributes. SNAP-IX 3270 emulation also enables you to use HLLAPI applications.
Refer to SNAP-IX 3270 User's Guide for information about using the 3270 emulation software to communicate with a host.
For more information about configuring support for 3270 emulation, see Configuring User Applications.
Using 5250 emulation software, you can log on to and use AS/400 systems from your computer. You can use emulation software to control display and printer emulation sessions and to transfer files between the local computer and the AS/400. 5250 emulation uses the node's LU type 6.2 resources.
To use 5250 emulation with SNAP-IX, you need to define the 5250 users on your system, identified by their login IDs, and the 5250 features available to each user or group of users. 5250 users and sessions are defined as domain resources, which simplifies the configuration required to support emulation across the domain.
For more information about configuring support for 5250 emulation, see Configuring User Applications.
The SNAP-IX 5250 emulation program provides session control and file transfer capabilities. In addition, you can customize some of the 5250 emulation features, such as key-mapping and display attributes.
Refer to SNAP-IX 5250 User's Guide for information about using the 5250 emulation software to communicate with an AS/400 system.
SNAP-IX provides support for remote job entry (RJE), enabling you to submit jobs to a host computer for processing. The RJE workstation daemon is the SNAP-IX component that handles transfer of jobs to the host, and also handles the output returned from the host.
You 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 any outstanding jobs to the host (in the order in which they were submitted). It also routes any output received from the host to the appropriate destination, as determined by the configuration.
The RJE workstation uses the node's LU type 0-3 resources. In addition, you need to define (as domain resources) the RJE workstations on your system.
The users of an RJE workstation can define workstation style files to supplement the SNAP-IX configuration and to control the operation of the workstation.
Refer to SNAP-IX RJE User's Guide for information about using RJE to submit jobs to a host and about setting up the workstation style file.
The NetView Distribution Manager Agent (NDMA) is an application running on the SNAP-IX computer that runs in conjunction with the NetView Distribution Manager (NetView DM) program at a host. This application enables a NetView DM operator at the host to manage files on the Solaris computer using NetView DM commands. NDMA can also work with the earlier host program DSX (distributed system executive), which was replaced by NetView DM.
For a list of the operations supported by NDMA, see Using NetView DM Agent. For detailed information, refer to SNAP-IX NDMA Administrator's Guide.
SNAP-IX includes the IBM APPC Application Suite, which provides the following set of APPC applications using independent LU 6.2: ACOPY, AFTP, ANAME, APING, APPC Remote EXECution (AREXEC), and APPC Tell (ATELL). For more information, refer to SNAP-IX APPC Application Suite User's Guide.
SNAP-IX provides several standard programming interfaces that you can use to develop application programs:
APPC API for peer-to-peer communications between application programs (see APPC API).
CPI-C (Common Programming Interface for Communications) for platform-independent communication using independent LU 6.2 (see CPI-C API).
CSV (Common Service Verb) API for utility functions such as character translation and application trace control (see CSV API).
HLLAPI (high-level language application programming interface) for application programs that interact with the 3270 emulation program to automate standard 3270 tasks (see HLLAPI).
LUA API for communications with host applications (see LUA API).
In addition, SNAP-IX includes the following proprietary programming interfaces:
LU0 API for communications with host applications (see LU0 API).
MS (Management Services) API for network messaging functions (see MS API).
NOF (Node Operator Facility) API for applications that configure and manage SNAP-IX resources (see NOF API).
Windows client APIs (see Windows APIs).
For more detailed information about an API, refer to the programming guide for the API (see SNAP-IX Publications).
An APPC application uses 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.
If the TP on the SNAP-IX computer is the invoking TP (the TP that starts the APPC conversation), the additional node resources required depend on the APPC features used by the TP, and on the type of remote system it is communicating with:
If the local node or the remote system with which the TP communicates is a LEN node, you need to define directory entries for the remote node and its LUs.
If the TP specifies its local APPC LU using an LU alias, you need to define the partner LU in order to associate this alias with a fully qualified LU name.
If the TP uses a dependent local LU to communicate with a host, you need a partner LU definition on the local node that specifies the uninterpreted name for the LU on the host. When the TP requests a conversation from the local LU, the local LU sends the host a session initialization request that contains the uninterpreted name for the host LU.
In the Motif administration program, directory entries and partner LUs
are not shown explicitly, but are included under the Remote Systems
heading in the Node window for the local node.
If the TP on the SNAP-IX computer is the invoked TP (the TP that accepts a conversation started by the invoking TP), the additional resources required depend on the APPC features used by the TP, and on how it is to be started:
To restrict the TP to using particular options for conversation security, confirm synchronization, or conversation type (mapped or basic), or to restrict the number of instances of the TP that can be running at any time, you must define the TP as a node resource.
To start the TP automatically when another TP requests a conversation with it, you must provide the information that SNAP-IX needs to start the TP. For more information, see Defining TPs.
If the TP is operator-started (not started automatically by SNAP-IX), and the use of the TP does not need to be restricted, you do not need to define any additional resources. The only exceptions are when you want to do the following:
Change the default timeout for a RECEIVE_ALLOCATE issued by the TP.
Specify that the TP is a broadcast queued TP (which means that incoming conversation requests can be routed dynamically to the TP wherever it is running).
For more information about TP configuration, see Defining TPs.
For more information about the APPC API, refer to SNAP-IX APPC Programmer's Guide.
A CPI-C application uses 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. You define the same resources for a CPI-C application as for an APPC application, as described in APPC API.
In addition, if the TP on the SNAP-IX computer is the invoking TP (the TP that starts the conversation), you may need to define one or more side information entries for it. Each of these entries provides information about a partner TP, the LU and mode resources used to access the partner TP, and any security information required.
For more information, refer to SNAP-IX CPI-C Programmer's Guide.
The Common Service Verb (CSV) API provides utility verbs that enable an application program to perform functions such as character set conversion and trace file control.
For more information, refer to SNAP-IX CSV Programmer's Guide.
HLLAPI (high-level language application programming interface) enables applications that use the SNAP-IX 3270 emulator program to communicate with a host.
For more information, refer to SNAP-IX HLLAPI Programmer's Guide or SNAP-IX 3270 User's Guide.
The LUA API enables application programmers to write applications that communicate with host applications at the request unit and response unit (RU) level, and to send and receive data on both the SSCP-LU session and the PLU-SLU session. This API can be used to support LU 0, 1, 2, or 3 communication with the host.
An LUA application uses the node's LU type 0-3 resources to communicate with a host application. You do not need to define any additional resources.
For more information, refer to SNAP-IX LUA Programmer's Guide.
The LU0 API enables application programmers to write applications that communicate with host applications. LU0 provides a simple and easy-to-use interface, but (unlike LUA) operates only with LU type 0 and does not provide access to the SSCP session.
An LU0 application uses the node's LU type 0-3 resources to communicate with a host application. You do not need to define any additional resources.
For more information, refer to SNAP-IX LUA Programmer's Guide.
The Management Services (MS) API enables an application to communicate with other MS products in an APPN network. 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.
For more information, refer to SNAP-IX MS Programmer's Guide.
The NOF API can be used to write applications that administer SNAP-IX configuration and management resources. For more information, refer to SNAP-IX NOF Programmer's Guide.
The SNAP-IX client software includes API libraries that are fully compatible with Microsoft SNA Server and the Windows Open Systems Architecture (WOSA), enabling applications written for SNA Server to run unchanged on the SNAP-IX Windows client.
SNAP-IX supports the following WOSA APIs:
Windows APPC
Windows CPI-C
Windows LUA
Windows CSV
3270 Emulator Interface Specification
For more information about Windows SNA APIs, see the SNAP-IX API manuals (which contain information about the Windows APIs as well as the Solaris APIs).
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.
A client does not contain SNA 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.
Servers must be Solaris computers; clients can be running Solarisor Windows. Servers and clients communicate across the SNAP-IX domain using TCP/IP.
You can configure one or more separate SNAP-IX domains on the same physical network, using a unique name for each different domain. Use the same domain name for all SNAP-IX servers and clients that belong the same 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.
Each server maintains information about its own node configuration in a node configuration file. You can use the SNAP-IX administration tools, described in Administration Tools, to examine and modify the node's configuration. You can configure a node from any other computer in the domain, as long as the SNA software is running on the node where the configuration is performed (whether or not the node being configured is started).
Information about the configuration of domain resources for the complete SNAP-IX LAN is held in a domain configuration file. If you have more than one server on the LAN, SNAP-IX ensures that this domain configuration information is consistent across all servers.
Client/server configuration provides the following benefits:
Concentrating SNA resources on servers reduces the load on clients, improving client performance and minimizing the storage needed to provide SNA services to clients.
Sharing a single data link among multiple users on different machines eliminates the need for each machine to have a physical SNA network connection.
Having multiple servers provides redundant connectivity (for example, by having multiple servers providing access to the same host). Having multiple paths to an SNA resource enables load balancing across the different servers and provides immediate backup in the event that a particular server or link fails.
Using LU pools across multiple servers makes it easy to configure and add servers and users.
Having fewer links and PUs for host connectivity reduces the size of the host VTAM definition.
Using SNAP-IX administration utilities makes it easy to configure and manage both node resources (for any specific computer in the domain) and shared resources (across the domain). The client/server support provided by SNAP-IX administration tools enables transparent administration of all domain resources from any computer in the domain.
If you are using SNAP-IX with all programs on one computer, or on a LAN that contains only one server, you do not need to read this section.
In a domain with multiple SNAP-IX servers, one server holds the master copy of the SNAP-IX domain configuration file. This server is known as the master server. You can define other servers on the LAN to be backup servers. The domain configuration file 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.
In general, you should define at least one backup server in addition to the master server. Any remaining servers can be defined as additional backup servers, or they can be left as peer servers. A peer server obtains domain configuration information from the master server as required, but cannot act as a backup server.
If the master server fails, the first backup server on the list of servers defined for the domain takes over as the master. The domain configuration file on this server is used as the master copy, and is copied to other servers as necessary. When the master server is restarted, it receives a copy of the domain configuration from the backup server currently acting as master, and then takes over as the master.
If at any time the master server and all backup servers are inactive, a node on a peer server can still operate, and you can still change the node's configuration. However, you cannot access the domain configuration file, and therefore cannot access the configuration of domain resources (as opposed to node resources). This means that you cannot start the 3270 emulation program, start the RJE programs, or allocate CPI-C conversations using symbolic destination names defined in the configuration file.
If the LAN is split by a network failure into two noncommunicating domains, each containing one or more backup servers, SNAP-IX cannot maintain a consistent configuration of domain resources across the LAN. In this situation, each domain has an acting master server, each tracking changes made to the domain configuration file in its own domain but unaware of any changes made in the other domain. When the LAN connection is re-established, the domain configuration file from the original master server becomes the domain configuration file across the LAN, and any domain resource files on other servers are overwritten. (If the master is inactive at this point, the domain configuration file from the highest backup server available in either of the two domains is used.) Because changes to a domain configuration file are not necessarily preserved when the connection is re-established, do not make any changes to the file in either domain while the LAN connection is broken. Changes can still be made to the configuration of individual nodes.
SNAP-IX stores information about the master server and backup servers in the binary file sna.net, known as the SNA network data file. The master copy of this file is stored on the master server; any changes made to it are automatically copied to all other servers in the same way that changes to the domain configuration file are copied to backup servers. You cannot edit the contents of the SNA network data file directly; instead, SNAP-IX provides administration facilities (see SNAP-IX Administration) to access the file. (You can edit node configuration files directly when SNAP-IX is not running; but in general you should use SNAP-IX administration facilities to ensure that all configuration information is valid and internally consistent.)
For more information about the SNA network data file, refer to SNAP-IX Administration Command Reference.
A client computer does not contain a configuration file or SNA network data file. Instead, the client has a client network data file that holds the information it needs to access servers on the SNAP-IX LAN. The client relies on a server to provide the necessary configuration information.
Most of the details of using Solaris client computers are the same as those for a server, except that the client has no node resources to define and manage. The following references provide more details about using a client:
To start and stop the SNAP-IX software, see Administering SNAP-IX.
To set up information required to support invokable TPs on the client, see Defining TPs.
To manage the SNA network information required to access servers on the SNAP-IX LAN, see Managing SNAP-IX Client/Server Systems or refer to SNAP-IX Administration Command Reference.
To manage diagnostics information (logging and tracing), see Diagnostic Tools, or for more detailed information, refer to SNAP-IX Diagnostics Guide.
SNAP-IX enables machines running Microsoft Windows 95 and Windows NT to act as clients in the SNAP-IX domain.
The SNAP-IX Windows Client software can be installed on machines running Windows 95 or Windows NT (32-bit Windows operating systems), and is also known as the Win32 Client. Configuration information required by Windows Clients is managed through the Windows Program Registry.
For more information about the Windows Program Registry, and about managing Windows clients, refer to the SNAP-IX Administration Guide. For information about Windows SNA APIs, see Windows APIs, or refer to the documentation provided with Microsoft SNA Server.
|
|
|
 |
|