BEA Logo BEA MessageQ Release 5.0

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

 

   MessageQ Doc Home   |   Client for OpenVMS User's Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index

Using the BEA MessageQ Client

 

This chapter describes how to develop, run, and manage BEA MessageQ Client applications. It contains the following topics:

Developing Your BEA MessageQ Client Application

This section describes the following special considerations for developing applications to run on the BEA MessageQ Client:

BEA MessageQ API Support

Table 4-1 shows the API functions supported by the BEA MessageQ Client. A small number of BEA MessageQ API functions are available only for a specific environment and are not supported by the BEA MessageQ Client. For example, the pams_get_msga function is available only on OpenVMS systems. To learn about the BEA MessageQ API functions, see the BEA MessageQ Programmer's Guide.

Table 4-1 BEA MessageQ Client API Functions

API Function

Description

pams_attach_q

Connects a program to the BEA MessageQ bus by attaching it to a message queue

pams_bind_q

Binds a temporary queue with a specified queue name

pams_cancel_select

Cancels selection of messages using a selection mask

pams_cancel_timer

Deletes the specified BEA MessageQ timer

pams_confirm_msg

Confirms receipt of a recoverable message

pams_detach_q

Detaches a selected message queue, or all attached queues, from the bus

pams_exit

Terminates all attachments between the application and the BEA MessageQ bus

pams_extract_buffer

Extracts a message from a handle into a message buffer

pams_get_msg

Retrieves the next available message from a selected queue

pams_get_msgw

Waits until a message arrives in the selected queue, then retrieves the message

pams_locate_q

Requests the queue address for a specified queue name

pams_put_msg

Sends a message to a target queue

pams_set_select

Defines a message selection mask

pams_set_timer

Creates a timer that sends a message to the application when the timer expires

pams_status_text

Receives the severity level and text description of a user-supplied PAMS API return code

putil_show_pending

Requests the number of pending messages for a list of selected queues

BEA MessageQ Client Function Parameter Limits

The BEA MessageQ Client sets specific limits on function parameter values that allow very large arguments on BEA MessageQ Server systems. The limits for the function parameters reduces the size of network messages exchanged between the BEA MessageQ Client and the remote Client Library Server. Table 4-2 lists the functions, parameters and their maximum values on the BEA MessageQ Client.

Table 4-2 API Function Parameter Maximum Values

API Function

Parameter

Maximum Value

pams_attach_q
pams_locate_q

q_name_len

32

pams_attach_q
pams_locate_q

name_space_list_len

100

pams_put_msg
pams_get_msg

msg_area_size

32,700 (see Note)

pams_detach_q

detach_q options

32

pams_set_select

num_masks

20

putil_show_pending

count

100

Note: Messages larger than 32,700 bytes can be sent or received by using the semantics for large messages (PSYM_MSG_LARGE). Refer to the BEA MessageQ Programmer's Guide for information on how to send these kinds of messages.

Include Files for C and C++

The BEA MessageQ Client provides include files for C and C++ language programs. The include files contain the BEA MessageQ API function prototype declarations, return status codes, symbolic constants used for API parameters, and other declarations for using BEA MessageQ message-based services. Table 4-3 lists the standard BEA MessageQ include files, which are described in the BEA MessageQ Programmer's Guide. The default location for these include files is:

DMQ$DISK:[DMQ$V50.USER.CLIENT]

Table 4-3 C Language Include Files

Include File

Contents

p_entry.h

Function prototypes and type declarations for the BEA MessageQ API

p_group.h

Constant definitions for BEA MessageQ message-based services

p_msg.h

Constant definitions for message-based services

p_proces.h

Constant definitions for BEA MessageQ (for OpenVMS) processes

p_return.h

Return status values

p_symbol.h

Symbolic constants used for function parameters

p_typecl.h

Constant definitions of BEA MessageQ message type and class for message-based services

fml32.h

Constant definitions and type declarations for support of FML32 (Field Manipulation Language).

tmenv.h

Constant definitions for support of FML32 (Field Manipulation Language).

BEA MessageQ Client Return Codes

All BEA MessageQ return codes are defined in the include file, p_return.h. Some of the return codes are specific to the BEA MessageQ Client and are not returned to server-based applications.

Table 4-4 lists the return codes specific to the BEA MessageQ Client.

Table 4-4 BEA MessageQ Client Return Codes

Return Code

Description

PAMS__JOURNAL_FAIL

The MRS service could not add messages to the local journal because of an operating system I/O error.

PAMS__JOURNAL_FULL

The MRS service could not add messages to the local journal because it is full.

PAMS__JOURNAL_ON

The link to the CLS is broken and the MRS service reports that journaling has begun.

PAMS__LINK_UP

The link to the CLS has been reestablished.

PAMS__NETERROR

The network connection to the CLS is broken.

PAMS__NETNOLINK

The network connection to the CLS is not available.

PAMS__PREVCALLBUSY

A previous BEA MessageQ function call is still in progress.

There are platform-specific differences in the numeric values for the p_return.h return codes. The OpenVMS version of p_return.h contains numeric values different from those used on Windows NT or UNIX. Client applications do not need to be concerned with these differences because the BEA MessageQ Client returns status codes as they are defined on the client system, regardless of the system where the CLS is running.

It is recommended that programs use the symbolic value when testing the return status codes, rather than a numeric value. For example,

if ( status == PAMS__NETNOLINK )

instead of

if ( status == -278 )

This improves code portability because of the platform-specific differences in the numeric values listed in p_return.h. It also makes code maintenance easier in the event that any status code numeric value is changed.

Byte Order Considerations for Application Developers

BEA MessageQ provides the capability to send and receive messages between many different types of operating systems and CPU architectures. The byte order used by different CPU architectures is referred to as either little endian (or right-to-left order) or big endian (left-to-right order). Application designers must take into account the differences in byte ordering when designing a distributed application with BEA MessageQ.

The byte order used on the BEA MessageQ Client system and the CLS platform may be different. For example, a Windows PC with an Intel x86 CPU is a little endian machine and an HP PA-RISC system is a big endian machine. This means that integer values sent in the message area from the client are represented differently when received by the application server on the host.

The BEA MessageQ Client and CLS handle differences in byte ordering by using network byte order when the Client and Server system are based on different representations (network byte order is big endian.). This ensures that the arguments to the BEA MessageQ API functions called on the client are passed correctly to CLS platform to initiate the messaging operation.

Note: The BEA MessageQ Client does not perform byte-swapping on the user data passed in the static buffer message area for pams_put_msg or pams_get_msg calls. Only BEA MessageQ self-describing messages, which use FML buffers, perform data marshaling between systems with unlike endian formats. Refer to the BEA MessageQ Programmer's Guide for more information about how to use self-describing messages.

There are various techniques for handling the byte order differences in the client or server application components:

The data marshaling routines can be implemented as a set of library routines designed specifically to support data format conversion. These routines are typically written so that each marshal routine performs one specific record conversion. Standard socket routines are available to support byte-order conversion. These routines are htonl, htons, ntohl, and ntohs. For example, htonl means host to network long (32-bit) conversion.

Building Your Client Applications

On OpenVMS systems, developers use the following syntax to compile BEA MessageQ Client C application programs:

$ cc MY_DMQ_PROGRAM/INCLUDE=DMQ$USER:

The /INCLUDE option for this command is used to specify the location of BEA MessageQ header files.

Client applications can be linked with either:

Linking applications with the BEA MessageQ RTL allows code sharing between numerous simultaneous users. It also saves memory, disk space, and link time. Applications linked with the BEA MessageQ for OpenVMS RTL can run in the BEA MessageQ for OpenVMS Server environment simply by redefining the DMQ$ENTRYRTL logical name.

Applications linked with the BEA MessageQ OLB must be relinked if they are moved to a BEA MessageQ Server system. The files required for linking are located in the DMQ$LIB and DMQ$USER directories.

Linking Applications with the BEA MessageQ Runtime Library

To link an application with the RTL, use the DMQ$LIB:DMQ/OPT switch in the linker command line. For example, to link a program called MY_DMQ_PROGRAM with the BEA MessageQ Client RTL you would use the following command:

$ link MY_DMQ_PROGRAM, DMQ$LIB:DMQ/OPT

The options file contains all the commands needed to build an application with the BEA MessageQ Client RTL. The DMQ$LIB:DMQ.OPT file uses the DMQ$ENTRYRTL logical to identify the RTL.

The choice of RTL will determine which network transports are available for the client application. For example, DMQ$EXE:DMQ$DECNET_CLRTLV50.EXE supports only DECnet.

If you have TCP/IP installed, the installation procedure will link an RTL supporting each TCP/IP stack and DECnet. The RTL names and supported transports are shown in the following table.

Table 4-5 BEA MessageQ Client for OpenVMS RTL Names

RTL Name

Transport Supported

DMQ$DECNET_CLRTLV50.EXE

DECnet only

DMQ$UCX_CLRTLV50.EXE

Compaq TCP/IP

DMQ$TGV_CLRTLV50.EXE

Process Software Corporation (PSC) Multinet TCP/IP

DMQ$PSC_CLRTLV50.EXE

Process Software Corporation (PSC) TCPWare TCP/IP

Linking Applications with the BEA MessageQ Object Library

The syntax for linking an application with the BEA MessageQ Client OLB is shown in the following example:

$ link MY_DMQ_PROGRAM, DMQ$LIB:CL.OLB/LIBRARY/INCLUDE=(QIO TCPIP option)

In the previous command, the /INCLUDE=(QIO_TCPIP_option) is used to select the desired TCP/IP stack. The following table shows the possible choices for QIO_TCPIP_option.

Table 4-6 BEA MessageQ Client for OpenVMS TCP/IP Option Names

TCP/IP Option

Transport Supported

/INCLUDE=(QIO_TCPIP_STUB)

DECnet only

/INCLUDE=(QIO_TCPIP_UCX)

Compaq TCP/IP

/INCLUDE=(QIO_TCPIP_TGV)

Process Software Corporation (PSC) Multinet TCP/IP

/INCLUDE=(QIO_TCPIP_PSC)

Process Software Corporation (PSC) TCPWare TCP/IP

Sample Programs

The BEA MessageQ Client is distributed with a number of sample application programs that demonstrate many features of the BEA MessageQ API. If the sample programs were selected during installation, they will be located in the BEA MessageQ installation directory tree. The default location is:

DMQ$EXAMPLES

The sample programs consist of C language source modules. The sample programs are identical to the sample programs distributed with the BEA MessageQ Server products, which demonstrate the portability of the BEA MessageQ API across all supported platforms.

The command procedure DMQ$EXAMPLES:X_BUILD.COM is used to build the sample programs. Copy the X_*.C sample programs and X_BUILD.COM from DMQ$EXAMPLES to a personal development directory before modifying any of the files. Use the following command to compile and link the sample programs.

$ @x_build

Note that the command procedure DMQ$DISK:[DMQ$V50.EXE]DMQ$CL_SET_LNM_TABLE must be executed before developing or running a client application on OpenVMS. The syntax for this command is:

$ @DMQ$DISK:[DMQ$V50.EXE]DMQ$CL_SET_LNM_TABLE

This command procedure defines logical names to identify files or directories used in development and run-time environments. It also defines symbols for the BEA MessageQ Client utility programs. Users can execute this command procedure from their login procedure (LOGIN.COM). This procedure must also be executed for any client application that is run as a detached process or batch job.

Client applications are linked with the BEA MessageQ Client run-time library (RTL). Run-time libraries allow code sharing between numerous simultaneous users. It also saves memory, disk space, and link time. The files required for linking are located in the DMQ$LIB and DMQ$USER directories.

To link an application, use the DMQ$LIB:DMQ/OPT switch in your linker command line. For example, to link a program called MY_DMQ_PROGRAM with the BEA MessageQ Client, you would use the following command:

$ link MY_DMQ_PROGRAM, DMQ$LIB:DMQ/OPT

The options file contains all the commands needed to build an application with the BEA MessageQ Client RTL.

Running Your Application

This topic explains how to run your application with BEA MessageQ Client. Before attempting to run a BEA MessageQ Client application, verify that the TCP/IP or DECnet connection between the BEA MessageQ Client and Server is properly configured. Use the ping utility to check the TCP/IP connection (see the documentation for TCP/IP networking for your system for more information). Use the ncp tell command to check the DECnet connection.

To use the BEA MessageQ Client, your run-time environment must meet the following software requirements:

  1. The BEA MessageQ for UNIX, Windows NT, or OpenVMS product must be installed on a server system. A message queuing group must be configured to support the requirements of your messaging application environment. The BEA MessageQ Client applications use messaging resources, including message queues, message buffers, and system resources, on the server system. See the Installation and Configuration Guide for your BEA MessageQ Server system and review the system resource requirements for using BEA MessageQ in your environment.

  2. If you are planning to use the TCP/IP transport, the host names for the client and server systems must be properly identified in the hosts files on both the BEA MessageQ Client and Server. Table 4-7 shows the location of host files on all BEA MessageQ Servers.

    Table 4-7 Hosts File Location

    Systems

    Hosts File Location

    UNIX

    /etc/hosts

    Windows 95

    See your TCP/IP vendor documentation.

    Windows NT

    c:\winnt\system32\drivers\etc\hosts

    OpenVMS

    Use the TCP/IP for OpenVMS configuration utilities. Refer to your vendor documentation.

  3. If you are planning to use the DECnet transport for communication between the BEA MessageQ Client and the CLS, the DECnet node names must be defined on the client and server systems. The ncp tell command can be used to verify that the client and server systems are connected. Refer to the DECnet documentation for more information about how to configure DECnet networks.

For a complete description of BEA MessageQ Server and TCP/IP transports supported by the BEA MessageQ Client, see the BEA MessageQ Release Notes.

Run-time Files

The run-time configuration file, dmq.ini, is required to run a client application. This file can be located in the application's working directory, or in a location identified by the DMQCL_INI_FILE logical name. The definition of DMQCL_INI_FILE must include the file name. For example, if several users want to share a dmq.ini file located in a directory called TEST$DISK:[TEST_ENV.DMQ], they would each define DMQCL_INI_FILE as follows:

$ define   DMQCL_INI_FILE    TEST$DISK:[TEST_ENV.DMQ]DMQ.INI

Managing Your Application

The BEA MessageQ Client includes several utility programs for testing client applications and managing the BEA MessageQ Client environment. The default location for the utilities is:

DMQ$EXE

Refer to Table 4-8 for a list of the BEA MessageQ Client utilities.

Table 4-8 BEA MessageQ Client for OpenVMS Utility Programs

Utility Program

Filename

Description

Test utility

dmq$cltest.exe

An interactive application for sending and receiving messages. Refer to Chapter 3, "Configuring the BEA MessageQ Client" for a description of how to run the Test utility.

MRS utility

dmq$clmrsu.exe

Displays the contents of the local store-and-forward (SAF) journal. Refer to MRS Utility for information on how to run the MRS utility.

Configuration Utility

dmq$clconf.exe

Allows configuration of the BEA MessageQ Client. Refer to Chapter 3, "Configuring the BEA MessageQ Client" for detailed configuration information.

MRS Utility

The BEA MessageQ Client MRS utility lets you view the contents of local SAF journals. When a sender program running on the BEA MessageQ Client sends a message marked as recoverable, it is written to the SAF journal on the client system. In the event that the recoverable message cannot be delivered to the CLS on the BEA MessageQ Server and stored by the BEA MessageQ message recovery system, it can be resent at a later time from the SAF journal on the BEA MessageQ Client using this utility.

The MRS utility is started with the following command:

$ dmqclmrsu [-h | -v | -d | -l | -n message | -t message]
[-f saf_path]

Table 4-9 MRS Utility Command Line Parameters

Command Switch

Description

-h

Displays a brief help message

-v

Display MRS utility version number

-d

Display journal file header details

-l

Brief display of all messages in the journal

-n message

Display detail for the specified message

-t message

Transmit the specified message

-f saf_path

Specifies the full file path to the desired journal file. The default is ./dmqsaf.jrn

Listing 4-1 shows the BEA MessageQ Client MRS utility using the -l and the -n options.

Listing 4-1 BEA MessageQ Client MRS Utility


$dmqclmrsu -l

SAF journal: dmqsaf.jrn
Msg Source Target Class Type Pri Size Data...
----- ----------- ----------- ------ ------ --- ------ ------------
1 0.0 5.300 66 99 0 13 'first mess'
2 0.0 5.300 66 99 0 14 'second mes'
3 0.0 5.300 66 99 0 13 'third mess'
4 0.0 5.300 66 99 0 14 'fourth mes'
5 0.0 5.300 66 99 0 13 'fifth mess'
6 0.0 5.300 66 99 0 13 'sixth mess'
7 0.0 5.300 66 99 0 15 'seventh me'
8 0.0 5.300 66 99 0 14 'eighth mes'
9 0.0 5.300 66 99 0 13 'ninth mess'
10 0.0 5.300 66 99 0 13 'tenth mess'

$dmqclmrsu -n 7

SAF journal: dmqsaf.jrn
Detail of message: 7

Source: 0.0 Priority: 0 Size: 15 Large_Size: 0
Target: 5.300 Class: 66 Type: 99
Resp Q: 0.0 Delivery: 29 UMA: 5 Timeout: 100

Contents of message buffer:
XB 73, 65, 76, 65, 6E, 74, 68, 20, 6D, 65 ! 'seventh me'
XB 73, 73, 61, 67, 65 ! 'ssage'