|
|
|
|
|
|
Introduction
This chapter provides an overview of the BEA MessageQ MVS Client software. It includes the following sections:
The BEA MessageQ MVS Client, Version 5.0, is a client implementation of the BEA MessageQ Application Programming Interface (API). The MVS Client relies on a BEA MessageQ server group to provide complete message queuing. The MVS Client uses an internal request/response protocol to communicate with a Client Library Server (CLS) running on a BEA MessageQ server system. The MVS Client is connected to the message queuing bus by a network connection between the BEA MessageQ MVS Client library and the CLS process in the remote BEA MessageQ server group.
The CLS is a BEA MessageQ application that runs as a background server to handle multiple MVS Client connections. The CLS performs all communication with the MVS Client application until the application detaches from the message queuing bus. The message queue operations and network activities of each client are isolated from other clients.
The CLS acts as a remote agent to perform BEA MessageQ message functions in the BEA MessageQ server group on behalf of the MVS Client. The MVS Client library establishes a network connection to the CLS when an application initiates an attach queue operation. The connection to the CLS is closed when the application performs a detach queue operation.
The BEA MessageQ MVS Client library allows multiple applications to connect to separate queues on the message queuing bus. This library creates a separate network connection to the CLS for each application using BEA MessageQ. The total number of applications that can connect to the message queuing bus is limited by the number of TCP/IP sessions.
The MVS Client provides a local store-and-forward (SAF) journal to store recoverable messages when the connection to the CLS is not available. When the connection to the CLS is reestablished, all messages in the SAF journal are sent before new messages are processed.
Benefits of Using the MVS Client
The BEA MessageQ MVS Client provides application developers a means to integrate their MVS mainframe environments with distributed heterogeneous systems through the use of BEA MessageQ message queuing middleware. The BEA MessageQ MVS Client, with support for MVS CICS and MVS batch, provides guaranteed message delivery between IBM mainframe applications and others running on any BEA MessageQ supported platforms by means of a direct TCP/IP network connection.
The BEA MessageQ MVS Client allows users to make BEA MessageQ calls from MVS mainframe applications, providing customers the ability to use a single API for all application environments. The wide range of platforms covered by BEA MessageQ offers developers a single, consistent programming interface to develop and deploy distributed applications across the entire spectrum of enterprise systems, including Microsoft Windows 95 desktops, Windows NT, all popular UNIX variants, OpenVMS, and IBM MVS mainframe environments.
The BEA MessageQ MVS Client can host its communications capabilities on a BEA MessageQ server implementation residing on any node in the network. The value of off-loading the BEA MessageQ communications capability to a non-IBM MVS node, while making BEA MessageQ calls and offering a recoverable link from the MVS environment, is important for companies looking to integrate the applications running on their MVS mainframes with applications running on UNIX, OpenVMS, and Windows NT servers.
Architectural Overview
The BEA MessageQ MVS Client, Version 5.0, is a client implementation of the BEA MessageQ Application Programming Interface (API). It relies on a BEA MessageQ server group to provide complete message queuing. If the network connection to the BEA MessageQ server group is lost or unavailable, the BEA MessageQ MVS Client optionally stores messages in a local journal file for later retransmission.
The BEA MessageQ MVS Client provides an object library (DMQ.V5R0.LIB) to support BEA MessageQ enabled applications. In addition, the media includes JCL procedures (DMQ.V5R0.CNTL) that are examples to be used in configuring and building your BEA MessageQ applications with the MVS Client. For a list of the JCL procedures, see Creating MVS Client Datasets in Chapter 2.
What Is the Client Library Server?
The Client Library Server (CLS) is a BEA MessageQ application that runs on a BEA MessageQ Server system as a background server to handle multiple MVS Client connections. The CLS performs all communication with the MVS Client library for each client task until the application detaches from the message queuing bus. The message queue operations and network activity of each client are isolated from other clients.
On server systems where both the operating system and the BEA MessageQ implementation support multithreading (such as BEA MessageQ on Windows NT), the CLS is multithreaded. On UNIX server systems, the CLS uses a separate process to handle each MVS Client connection. On OpenVMS server systems, the CLS can operate in the following modes:
When the server starts, it initializes a listener process (or thread) that establishes a network endpoint and waits for connections from MVS Clients. The endpoint on which the CLS listens is determined by the command-line arguments used to start the server. MVS Clients attempt to connect to the CLS when they initiate an attach queue operation.
The MVS Client library uses configuration information in the BEA MessageQ Server group configuration file to identify the location of the CLS. The CLS creates a server subprocess (or server thread with a client context variable) for each new client connection. The server process or thread terminates when the client detaches from the bus, or the network connection is closed.
How Do the MVS Client and CLS Work Together?
The BEA MessageQ MVS Client uses an internal request/response protocol to communicate with the CLS running on a BEA MessageQ Server system. The BEA MessageQ MVS Client provides a "lightweight" client connection to the BEA MessageQ message queuing bus.
The implementation is considered lightweight because:
The MVS Client connection to the message queuing bus is provided by a network connection between the BEA MessageQ MVS Client library and a CLS process in the remote BEA MessageQ server group. Figure 1-1 shows the relationship of the MVS Client and CLS to the BEA MessageQ message queuing bus.
Figure 1-1 BEA MessageQ Client and Server Components
The CLS acts as a remote agent to perform BEA MessageQ messaging functions in the BEA MessageQ Server group on behalf of the MVS Client. The MVS Client library establishes a network connection to the CLS when an application initiates an attach queue operation. The connection to the CLS is closed when the application performs a detach queue operation.
How the MVS Client Uses BEA MessageQ Function Calls
All BEA MessageQ API functions supported by the MVS Client are processed using the following sequence of events:
Figure 1-2 shows the communication layers used by a BEA MessageQ MVS Client application.
Figure 1-2 BEA MessageQ MVS Client Library Architecture
The BEA MessageQ MVS Client library allows only one BEA MessageQ function call from the same application to be in progress at a time, with the exceptions of pams_exit and pams_detach_q. For example, if an application calls pams_get_msgw and then calls pams_put_msg before the get message function call returns, the pams_put_msg function returns immediately with an error status value of PAMS__PREVCALLBUSY.
The BEA MessageQ MVS Client library allows multiple applications to connect to queues on the message queuing bus. The library creates a separate network connection to the CLS for each application using BEA MessageQ. The total number of applications that can connect to the message queuing bus is limited by the number of TCP/IP sessions. The Client library uses the Berkeley Socket API for network services.
Store-and-Forward Journaling
The MVS Client provides an SAF journal to store recoverable messages when the connection to CLS is not available. Local SAF journal processing is available when Message Recovery Services (MRS) are enabled in the MVS Client configuration.
When message recovery is enabled, the journal is turned on when the BEA MessageQ MVS Client application first initiates an attach operation. If the CLS is not available at the time of an attach, the operation completes with a return status of PAMS__JOURNAL_ON.
When the communications link to the designated server is down, and MRS is enabled, messages using the following delivery modes are written to a disk journal:
Messages sent with these recoverable delivery modes are written to the SAF file, which uses the VSAM KSDS format. A DD statement for DMQSAF must be included in the execution JCL and the name must be the same as the one created when the environment was configured. When the communications link to the designated server is restored, all journaled traffic is transmitted, maintaining FIFO order for recoverable messages.
When the journal is on, messages sent using a reliable delivery mode are saved to the journal. When the connection to the CLS is reestablished, all messages in the SAF journal are sent before new messages are processed.
Before you can use the MRS configuration option of the MVS Client, you must create the SAF journal. Refer to Configuring Message Recovery Services in Configuring the BEA MessageQ MVS Client, for information on how to create the SAF journal.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|