These features are provided by the IRIS SNA SERVER:

The SNA Graphical User Interface for the IRIS SNA SERVER. It is an X Window and Motif-based network management tool that facilitates configuring and operating the IRIS SNA SERVER and managing IRIS SNA LU 6.2 sessions. The main window serves as the central information and operations panel. All of the pertinent information needed to configure and use the IRIS SNA SERVER is accessible through this window and its secondary windows and related dialog boxes.

The IRIS SNA SERVER can function as a PU 2.1 peer node, communicating with another peer node, or as a PU 2.0 peripheral node in an SNA network controlled by a Systems Services Control Point (SSCP). This function makes the product upwardly compatible with current SNA networks and provides support for LU 6.2 sessions with a host running Customer Information Control System (CICS). When multiple links (physical connections) are supported, the product simultaneously can act as a PU 2.0 node on one link and as a PU 2.1 node on another link.

The IRIS SNA SERVER supports communications through an SDLC link. The IRIS SNA SERVER is capable of performing either the primary or secondary link-station role. The link-station role can be pre-configured or negotiated with the partner when the link is activated. Switched lines are supported in either calling or answering mode.

The IRIS SNA SERVER supports communications over both 4 or 16 megabit token ring links (user selectable). It can be configured as a Downstream PU (DSPU) to connect to an IBM host or as a peer node to communicate with other ring stations that support peer communications protocol. Token ring supports IBM Source Routing.

The IRIS SNA SERVER supports multiple physical links. Each link can be connected to any combination of PU 2.1, PU 4, or PU 5 devices. Individual link activation and deactivation are independent of other physical connections.

The API provides you with the tools and routines to write applications that define network resources and control network operations. These verb-interface functions are implemented as C- language library functions. The libraries are installed as
/user/lib/libsna.a and /usr/lib/liblu03.a. Also, a directory of header files required for the verbs is installed in /usr/include/sna. See the IRIS SNA SERVER Programming Guide and the IRIS SNA LU 6.2 Programming Guide for additional information on programming with the API interface.

LUs can be configured to support different modes of service since transaction programs identify the desired mode of service when a conversation is requested. This means some sessions can be reserved for very short conversations. You can associate line characteristics with these modes. For example, you can configure some sessions to use a high-speed line and others to use a slower line.

This section summarizes the LU 0-3 API product features.

The PI verbs, as well as all the API verbs of SNA, are implemented so that the application using them does not have to execute on the same workstation or server as the IRIS SNA Scheduler. This functionality supports configurations in which the applications run in processors connected to an IRIS SNA Scheduler by a Local Area Network.

A logical unit session can be configured to utilize a specific address or any available address from a pool of addresses. If host security requires each end user to have a pre-defined network address, then this can be enforced by requiring the logical unit session to utilize the same network address for all host communications. If, however, network addresses can be shared among the end-user community, then the logical unit sessions can be configured to utilize the first available address on a network link.

An application can allocate an LU during execution and does not have to preconfigure itself to a particular LU.

Sessions may be brought up by one application, then used by other applications in turn, which enables cooperating applications to reduce the overhead associated with session establishment.

Data can be sent or received on both the SSCP-LU (System Service Control Point to Logical Unit) and LU-to-LU sessions.

The application can request that it receive the data when an entire chain has arrived, when a single Request/Response Unit (RU) has arrived, or as each segment arrives. This capability is a performance option, typically used by screen-emulation programs.

The application can obtain and set sync-point values.

An application can send and receive Function Management Data Network Server (Maintenance) or FMD NS(MA) request units on the SSCP-PU session. Sending and receiving data is similar to exchanging data on the LU sessions. Internal statistics are also maintained by the IRIS SNA Scheduler. These statistics can be retrieved by an application and reported to the appropriate network management facility.

Since the underlying PU 2.1 supports multiple links, the same IRIS SNA Scheduler can connect to several different hosts simultaneously, or appear as several Physical Units to the same host.

The IRIS SNA SERVER communicates with LU 0-3 application programs through sockets. An end user can run these application programs at a workstation other than the one on which the IRIS SNA SERVER is running.

This section describes the major features of IRIS SNA LU 6.2. For additional information, see the IRIS SNA LU 6.2 Programming Guide.

IRIS SNA LU 6.2 supports parallel sessions. The number of Logical Units that can be active within a single node is limited by the memory size established for the IRIS SNA SERVER. Each active LU is capable of initiating up to 254 sessions per physical link and accepting up to 254 sessions initiated by each partner LU. Each LU is configured to accept automatically, at LU start-up, a preset number of sessions with each partner LU. A maximum number of sessions is also configured. If a free session is not available when a transaction program requires one, the LU automatically initiates sessions up to the configured limit.

The LU has the capability to start processes at the request of its partner and to pass Program Initialization Parameter (PIP) data. The new process is connected to its partner program at the initiating LU by the conversation that carried the initiation request.

The Application Program Interface (API) provides tools and routines that enable programmers to write Advanced Program-to-Program Communication (APPC) programs that use the resources of IRIS SNA LU 6.2. The verb-interface functions are implemented as C-language library functions. These functions are fully documented in Appendix C, Man Pages, in the IRIS SNA LU 6.2 Programming Guide.

It is possible to configure an LU to support different modes of service. Transaction programs identify the desired mode of service when a conversation request is made. This feature can be used to reserve some sessions for very short conversations. You can associate line characteristics with these modes. For example, some sessions can be configured to use a high-speed line while others use a slower one.

The partner LU does not have to reside in another node, or even be a different LU, which is advantageous for server programs. For instance, a transaction program can be written to access a database server using the LU services. Whether that database server happens to be physically located on the same node, or is on another node is transparent to the transaction program.

The LU can initiate and maintain sessions that are not in current use by any transaction program. When a transaction program requests a session, the LU allocates a session to it. When the transaction program is through with it, the session is returned to the list of free sessions. Each session use by a transaction program is considered a conversation. (A conversation is a logical connection between a pair of transaction programs that permits them to share an LU-LU session serially from transaction to transaction.) This use of conversations eliminates the need to initiate and terminate a session each time a program needs one, thereby reducing system overhead.

IRIS SNA LU 6.2 provides mapped conversation, as well as basic conversation capabilities. With mapped conversations, application programs do not need to be concerned with any specialized data streams used by a specific product. All data that is sent is converted into a standard format and original form at the receiving end. No automatic conversion is performed with basic conversations.

A transaction program can obtain a conversation and begin to use it while delaying the acquisition of a session until it is needed.

The IRIS SNA SERVER communicates with IRIS SNA LU 6.2 transaction programs by means of the TCP/IP socket. An LU 6.2 transaction program can be executed from a TCP/IP node and can engage a conversation with another SNA LU 6.2 transaction program, using an IRIS SNA SERVER workstation as a gateway.

IRIS Token Ring software provides token-ring connectivity for the IRIS-4D system at either 4 or 16 megabits per second, compliant with IEEE 802.2 and 802.5 standards. IRIS Token Ring software also provides:

IRIS SDLC communications connectivity provides these features:

The following PU Type 2.1 base set capabilities are supported:

The following PU Type 2.1 options sets are supported:

The following additional node-level capabilities are supported:

A listing of the SNA RU support by category follows.

Session Control

Data Flow Control

A list of the unnumbered and supervisory commands and responses follow:

SNRM Set Normal Response Mode

RR Ready to Receive

RD Request Disconnect

RNR Receiver Not Ready

DISC Disconnect

UA Unnumbered Acknowledgment

DM Disconnect Mode Information Frames

FRMR Frame Reject

TEST Test Information

XID Exchange Identification (XID Format 3)

FM Profile 0: SSCP-PU and SSCP-LU Sessions
Profile 0 specifies the following session rules:

FM Profile 3: LU-LU Sessions
Profile 3 specifies the following session rules:

These FM usage fields define the options for Profile 3:

Product exceptions to the profile are:

FM Profile 4: LU-LU Sessions
Profile 4 specifies the following session rules:

These FM usage fields define the options for Profile 4:

Product exceptions to the profile are:

TS Profile 1: SSCP-PU and SSCP-LU Sessions
Profile 1 specifies the following session rules:

This profile does not require the use of the TS usage field.

TS Profile 3: LU-LU Sessions
Profile 3 specifies the following session rules:

These TS usage subfields define this profile's options:

The product exception to the profile is:

TS Profile 4: LU-LU Sessions
Profile 4 specifies the following session rules:

These TS usage subfields define this profile's options:

The product exception to the profile is Session-level cryptography.

Table A-1 shows the SNA RUs supported by the interface and the type of support provided. The word SEND indicates that the RU can be sent by an application; RECEIVE indicates that the SNA Scheduler forwards the RU to the application untouched (the application is responsible for the response); and NOTIFIED indicates that the SNA Scheduler creates and sends a response to the RU, then forwards the RU to the application.

Interface Send Receive Notified

Session Control RQR BIND ACTLU
UNBIND ACTPU
CLEAR
DACTLU
DACTPU
STSN
SDT
UNBIND

Data Flow Control CANCEL BID CANCEL
CHASE CHASE LUSTAT
LUSTAT SIGNAL QC
QC QEC
QEC RELQ
RELQ SHUTD
RSHUT
RTR
SHUTC
SIGNAL

FMD INITSELF ECHOTEST NOTIFY
NMVT NMVT NSPE
NOTIFY REQMS
RECFMS
REQECHO
TERMSELF

SNA RU Support