SNAplus2 Components

SNAplus2 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 function.

SNAplus2 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, and LUA communications.

SNAplus2 can operate either as a LEN node or as an APPN end node, depending on its configuration. Certain functions are supported only on end nodes, as defined by the APPN architecture. These differences are indicated where necessary in this manual; where no differences are indicated, the information applies to both node types.

Passthrough services enable downstream computers on a LAN to access host resources through a server running SNAplus2. SNAplus2 provides the following passthrough services:

PU Concentration

In addition to providing direct access to a host computer, SNAplus2 can provide PU concentration facilities. This feature enables other computers to access a host computer through the SNAplus2 node, instead of requiring a separate connection to the host from each computer.

The PU concentration feature is shown in Figure 2-7 “PU Concentration”

Figure 2-7 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 SNAplus2 computer.

When the local SNAplus2 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 SNAplus2 or with other downstream computers, instead of requiring a direct link. For example, you could set up several downstream computers connected to SNAplus2 over a local token ring network, so that they could all access the same long-distance leased line from SNAplus2 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 SNAplus2 computer and its host communication link; the LUs at the downstream computers are configured as part of the resources of the SNAplus2 computer. The host computer is not aware that PU concentration is being used.

TN Server

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.

	NOTE: This guide uses the term TN3270 for information that applies equally to the TN3270, TN3287, and TN3270E protocols.

SNAplus2 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 SNAplus2 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 SNAplus2 TN server function is shown in Figure 2-8 “TN Server”

Figure 2-8 TN Server

TN server provides an association between a TN3270 user and a 3270 LU on the SNAplus2 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.

SNAplus2 TN server supports all TN3270 client emulation programs that correctly implement the protocols defined in RFCs 1123, 1576, 1646, and 1647.

When a TN3270 program communicates with TN server, SNAplus2 identifies the program by the TCP/IP address of the computer where the TN3270 program is running. SNAplus2 cannot distinguish between two different TN3270 programs being used by different users on the same computer. In the SNAplus2 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.

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 SNAplus2 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. SNAplus2 3270 emulation also enables you to use HLLAPI applications.

Refer to the HP-UX SNAplus2 3270/3179G Users Guide for information about using the 3270 emulation software to communicate with a host.

For more information about configuring support for 3270 emulation, see Chapter 8, "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.

	NOTE: SNAplus2 does not provide a 5250 emulation program; it just provides support for third party 5250 emulation software.

To use 5250 emulation with SNAplus2 , you need to define the 5250 users on your system. 5250 users are defined as domain resources, which simplifies the configuration required to support emulation across the domain.

Depending on the requirements of the 5250 emulation program you use, you may need to configure the emulation program with additional information.

For more information about configuring support for 5250 emulation, see Chapter 8, "Configuring User Applications."

SNAplus2 provides support for remote job entry (RJE), enabling you to submit jobs to a host computer for processing. The RJE workstation daemon is the SNAplus2 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 SNAplus2 configuration and to control the operation of the workstation.

Refer to the HP-UX SNAplus2 RJE Users Guide for information about using RJE to submit jobs to a host and about setting up the workstation style file.

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 SNAplus2 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:

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 SNAplus2 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:

For more information about the APPC API, refer to the HP-UX SNAplus2 APPC Programmers 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 SNAplus2 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 the HP-UX SNAplus2 CPI-C Programmers 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 the HP-UX SNAplus2 CSV Programmers Guide.

HLLAPI (high-level language application programming interface) enables applications that use the SNAplus2 3270 emulator program to communicate with a host.

For more information, refer to the HP-UX SNAplus2 3270 & TN3270 HLLAPI Programmers Guide or HP-UX SNAplus2 3270/3179G Users 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 the HP-UX SNAplus2 LUA Programmers 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. SNAplus2 performs any data conversion that is required.

For more information, refer to the HP-UX SNAplus2 MS Programmers Guide.

The NOF API can be used to write applications that administer SNAplus2 configuration and management resources. For more information, refer to the HP-UX SNAplus2 NOF Programmers Guide.

For Windows

The SNAplus2 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 SNAplus2 Windows client.

SNAplus2 supports the following WOSA APIs:

For more information about Windows SNA APIs, see the documentation provided with Microsoft SNA Server.

End of Section

Client/server configuration provides the following benefits:

If you are using SNAplus2 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 SNAplus2 servers, one server holds the master copy of the SNAplus2 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.

	NOTE: If the LAN is split by a network failure into two noncommunicating domains, each containing one or more backup servers, SNAplus2 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.

SNAplus2 stores information about the master server and backup servers in the 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, SNAplus2 provides administration facilities to access the file. (You can edit node configuration files directly when SNAplus2 is not running; but in general you should use SNAplus2 administration facilities to ensure that all configuration information is valid and internally consistent.)

For more information about the SNA network data file, refer to the HP-UX SNAplus2 Administration Command Reference.

For UNIX

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 SNAplus2 LAN. The client relies on a server to provide the necessary configuration information.

Most of the details of using HP-UX 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:

End of Section

For Windows

SNAplus2 enables machines running Microsoft Windows 3.1, Windows for Workgroups 3.11, Windows 95, Windows NT, and OS/2 to act as clients in the SNAplus2 domain. You can run either a 16-bit version of the SNAplus2 client software (referred to in this guide as “Win16”) or a 32-bit version (referred to in this guide as “Win32”):

For more information about the sna.ini file and the Windows Program Registry, and about managing Windows clients, see Chapter 11, "Managing SNAplus2 Clients." For information about Windows SNA APIs, see “Windows APIs”, or refer to the documentation provided with Microsoft SNA Server.

End of Section