Introducing BEA MessageQ LU6.2 Services

 

The BEA MessageQ LU6.2 Services for OpenVMS product allows users to communicate with IBM application programs using Advanced Program-to-Program Communications (APPC) over System Network Architecture (SNA) LU6.2 sessions. APPC/LU6.2 communications are connection-oriented and half-duplex. This means that before two partners can exchange messages, they must first establish a connection (connection-oriented), and that one partner is sending when the other is receiving (half-duplex).

This chapter includes the following topics:

• Basic Terms and Concepts

• SNA APPC/LU6.2 Fundamentals

Basic Terms and Concepts

This section provides general information about BEA MessageQ applications, APPC, the Port Server, and other application components.

The BEA MessageQ LU6.2 Services Product

The BEA MessageQ system is a connectionless, stateless communications system. This means that a connection need not be established before programs can communicate with each other. It also means that communicating programs do not care what state their partner is in.

Using BEA MessageQ LU6.2 Services is like using the postal mail system-you can send a letter to anyone whose address you know, whether or not the addressee is home and regardless of the addressee's desire to speak to you. Addressees can check their mailboxes at their convenience.

The BEA MessageQ system supports network-independent addressing and makes use of an application programming interface (API) common to all platforms that support the MessageQ system.

SNA LU6.2 Sessions

SNA is connection-oriented systems networking architecture. Connections are established between network-addressable units. Applications are interested in logical units (LUs) that are the "end users" of a network. The connection between LUs is an SNA session.

The LU that requests a session is called the primary logical unit or PLU. The LU that accepts the session is called the secondary logical unit or SLU. The capabilities of an LU are defined by the LU type. Only one type of LU supports APPC: LU type 6.2 (also known as LU6.2).

An LU6.2 session is the type of SNA connection used by APPC applications for communications with each other. The session is like the telephone connection received when you dial another number-if the other number does not answer, you cannot speak.

Without an SNA session, APPC conversations cannot take place. An LU is the software equivalent of a telephone-it has a specific address in the network, and other LUs have to know that address in order to establish sessions with it.

Advanced Program-to-Program Communications (APPC)

A program that wants to communicate with other programs must first establish a connection to each potential partner, and the communicating programs must be aware of each other's state (for example, ready to receive, ready to send, and shutting down). This requirement is similar to the requirements of the telephone system: before you can talk to someone, you must call someone up; the call recipient must answer the phone, and agree to listen to you; after you have finished speaking, the other party can speak to you; and so on.

BEA MessageQ LU6.2 Services for OpenVMS applications use Advanced Program-to-Program Communications (APPC) to establish connections to partners and communicate state information before initiating conversations. APPC is a connection-oriented, half-duplex, state-oriented communications system. It uses the following concepts:

• Conversation-a structured exchange of messages between two partners, conducted over a previously established LU6.2 session.

• Allocation-the act of establishing a conversation.

• Deallocation-the act of terminating an existing conversation.

• Sync-level-the highest degree of synchronization permitted on a given conversation. Sync-level parameters are 0 (None), 1 (Confirm), and 2 (Syncpoint). The BEA MessageQ LU6.2 Services for OpenVMS product uses only sync-levels 0 and 1.

  APPC provides a set of functions called APPC verbs to manage conversations. (See Chapter 6 for more information on APPC verbs.)

BEA MessageQ LU6.2 Services Application Components

Figure 1-1 shows the components of a typical BEA MessageQ LU6.2 Services application.

Figure 1-1 BEA MessageQ LU6.2 Components

The components are:

• The BEA MessageQ client that communicates with the BEA MessageQ LU6.2 Port Server by sending and receiving messages over the BEA MessageQ message bus. By sending specific, predefined message types, the BEA MessageQ client can ask the Port Server to:

  • Establish a connection to an IBM LU6.2 application (a Connect request)

  • Send traffic received from incoming connections to a specific BEA MessageQ client (a Register Target request)

  • Send or receive data over a previously established connection (a data message)

  • Manage a previously established connection (a Change Direction request or a Connection Terminated notice)

• The BEA MessageQ LU6.2 Port Server that establishes and maintains SNA sessions for use by BEA MessageQ clients and applications residing on remote IBM systems.

  The LU6.2 Port Server is a connection point manager: a software process that understands the "language" of network applications located in different networks on opposite sides of a "connection point," the place where the two networks attach to each other.

  A Port Server manages communication resources on behalf of client processes (resource sharing), reduces application complexity by "hiding" the details of resource management, and optionally provides other value-added services (like multithreading).

  The SNA sessions are created using the services of the SNA Gateway (either a DECnet/SNA Gateway, a Domains Gateway, or a Peer Server). SNA sessions are assigned to BEA MessageQ clients on a first-come, first-served basis when the clients send Connect requests.

• The SNA Gateway that performs the lower-level protocol and message format translations required to connect a DECnet network with an SNA network.

• NCP and VTAM, software components crucial to the operation of the networked SNA systems. SNA Gateways, communications lines, and LUs must be properly defined to NCP and VTAM before communication with the IBM applications is possible.

• CICS, TSO, and IMS, application subsystems that run on the MVS operating system and support the use of APPC over LU6.2 sessions.

  BEA MessageQ LU6.2 Services are most frequently used to communicate with application programs that run under these application subsystems.

SNA APPC/LU6.2 Fundamentals

The information that follows is a short summary of SNA APPC LU6.2 fundamentals. For more detailed information, refer to SNA Transaction Programmer's Reference Manual for LU Type 6.2.

Logical Unit Type 6.2 Overview

LU6.2 is a general-purpose architecture that enables IBM products to communicate with each other. The LU6.2 architecture defines a set of protocols. To communicate with each other, products must implement LU6.2 according to these protocols. There are two general implementations of LU6.2:

• The "open-box" protocol provides a programming interface to allow customized solutions.

• The "closed-box" protocol provides no programming interface but does offer turnkey solutions.

Transaction programs (TPs) are programs that can process a specific set of input data, trigger specific job executions, or produce specific output data. Distributed transactions within an SNA network communicate by exchanging information during a conversation, which is a temporary logical path established between two cooperating TPs. This path is treated as a shared resource between TPs.

IBM's architectural definition for LU6.2 provides a set of procedures called verbs that is used to design distributed transactions. CICS ISC implements the verb functions with EXEC CICS commands and OpenVMS TPs implement the verb functions with OpenVMS procedures.

The APPC verb set consists of function verbs that are implemented as BEA MessageQ messages. The logic of how these verbs are used (verb flow) is the same regardless of whether you are programming in an OpenVMS environment or an IBM environment. Refer to LU6.2 User Callback Services, for detailed information on User Callback Services and APPC verbs.

Inbound and Outbound Conversations

Conversation allocations may be initiated either by the OpenVMS TP (inbound) or by the IBM TP (outbound). Figure 1-2 illustrates a typical SNA conversation session. The LU6.2 type of SNA LUs can be configured as independent or dependent. The BEA MessageQ LU6.2 Services for OpenVMS product uses dependent LUs.

Figure 1-2 SNA Session for Dependent LUs

Inbound allocation causes the gateway to transmit an INIT SELF to the IBM SSCP that builds a suggested BIND and passes it to the application subsystem (which may modify it). The application passes the BIND back to the gateway. If the gateway accepts the BIND, the session is established and the OpenVMS and IBM TPs are in a "session."

Outbound allocation causes the gateway to wait in the active-listening mode for the IBM TP to send a BIND followed by an ATTACH. If the gateway accepts this ATTACH, the session is established and the OpenVMS and IBM TPs are in a session. They are also in a state of conversation (also called "between brackets").

Contention for session resources occurs when both partners attempt to begin conversation simultaneously on the same session. The contention is resolved according to the polarity agreed upon when the session was established. The contention winner (first speaker) always receives the session resources, and the contention loser (bidder) always has to wait. The contention winner/loser is negotiated in the BIND.

Using the LU6.2 Port Server for Applications Connections

Exchanging information between the connectionless, stateless environment of the BEA MessageQ system and the connection-oriented, state-oriented environment of APPC (a task similar to that of connecting systems as different as the postal mail and the telephone) requires the services of an intermediary that understands both. The intermediary provided by BEA MessageQ LU6.2 Services is the LU6.2 Port Server.

The LU6.2 Port Server understands how to:

• Get connections to APPC applications when asked to do so by BEA MessageQ applications (inbound connections)

• Convert data messages from one network into the form required by the other network

• Accept connections from APPC applications and deliver the incoming data to BEA MessageQ applications (outbound connections)

• Detect errors from one network and deliver the proper error notifications to the other network

In addition, the LU6.2 Port Server performs numerous "housekeeping" tasks (such as error recovery, automatic restart of communication links, and error and trace logging) that are desirable in distributed applications.

Refer to Configuring the LU6.2 Port Server, for more information on the LU6.2 Port Server.

The BEA MessageQ LU6.2 Services product uses the Stream Output Facility for logging and tracing. This facility provides time stamps on both the logging and tracing output as well as dynamic tracing. See the BEA MessageQ Installation and Configuration Guide for OpenVMS for more information on dynamic tracing and the BEA MessageQ for OpenVMS Event Logger Utility.

Writing Your Own Port Server

When installed, the BEA MessageQ LU6.2 Services software provides a typical LU6.2 Port Server that uses seven predefined messages to simplify setting and managing the application connections of the BEA MessageQ clients to remote partners.

However, if the standard LU6.2 Port Server programming interface does not meet the needs of an application, does not offer a function required by all client applications, or does not meet some other unusual requirements, a specialized Port Server may be developed using the LU6.2 User Callback Services.

The BEA MessageQ LU6.2 Services provide you with the option of writing your own Port Server using 21 BEA MessageQ messages that map to the APPC verb set.

Note: Refer to Configuring the LU6.2 Port Server, and Port Server Messages, for LU6.2 Port Server information. Refer to LU6.2 User Callback Services, for LU6.2 user callback information.