BEA Logo BEA MessageQ Release 5.0

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


   MessageQ Doc Home   |   Configuration Guide for OpenVMS   |   Previous Topic   |   Next Topic   |   Contents   |   Index

Configuring Cross-group Connections


To enable message queuing between different systems in a network, you must create Oracle MessageQ message queuing groups on each system and establish cross-group connections. This chapter discusses cross-group connections.

Note: For detailed information on creating message queuing groups using the Customize utility, refer to Oracle MessageQ Main Menu and Utilities.

The following topics are covered in this chapter:

Connecting to Other Message Queuing Groups

Messages can be exchanged between message queuing groups through:

Groups can exchange messages either directly or indirectly. Table 3-1 describes the message exchange methods.

Table 3-1





Between systems that share a network link

Cross-group connection table


Between nodes that do not share a network link

Message routing with either Oracle MessageQ routing table, DMQ$INIT.TXT, or dynamic tables

Message Exchange Methods

Configuring the Cross-group Connection Table

The following topics are covered in this section:

Cross-group Connection Table Overview

The cross-group connection table provides link drivers with the information needed to connect to other Oracle MessageQ message queuing groups through DECnet or TCP/IP network communications.

Loading the Configuration Data

You can load this static routing table either by using the startup or by running the DMQ$LOADER utility (refer to Chapter 9, "Oracle MessageQ Main Menu and Utilities").

When a queuing group is started, it parses the cross-group connection table and attempts to establish DECnet and TCP/IP links with all the other groups listed in the table. The link drivers maintain these links by reconnecting to them as specified by a timer that is set for each link.

The link drivers also attempt to reconnect to all the groups defined in the cross-group connection table. A request for reconnection can be sent to the link drivers using the MONITOR utility (see Chapter 10, "Using Oracle MessageQ System Management Utilities") or link management messages (see the Oracle MessageQ Programmer's Guide ).

Note: Before running the DMQ$LOADER to load Cross-group Connection Table, make sure you have configured an available DNS server and the node specified in such table is in the DNS; otherwise, some LinkDriver links may be broken unexpectedly as the address translation may delay for a long time to reconnect DECnet and TCP/IP links

Using Cross-group Connection Table Fields

The cross-group connection table in Listing 3-1 begins with %XGROUP and contains the fields shown in Table 3-2. Note that you can enter -1 in any field to designate the default entry.

Listing 3-1 Cross-group Connection Table

%XGROUP ***** Cross-Group Connection Table ******
* gen buf buf recon dly win transport
*gname gnumber node cnt warn pool sec sec msg type endpt
*--------- ------ ------------------- --- --- --- --- --- --- ----- -----
*GR1_TCP 1 Y -1 175 -1 -1 -1 TCPIP 2001
*GR1_TCP 1 Y -1 175 -1 -1 -1 TCPIP 2001
*GR1_DECNET 1 daddr1 Y -1 -1 -1 -1 -1 DECNET
*GR1_DECNET 1 daddr4 Y -1 -1 -1 -1 -1 DECNET
*GR2_TCP 2 Y -1 175 -1 -1 -1 TCPIP 2002
*GR1_TCP 1 Y -1 175 -1 -1 -1 TCPIP 2002
*GR2_DECNET 2 daddr4 Y -1 -1 -1 -1 -1 DECNET
*GR2_FAILOVER 2 daddr5 Y -1 -1 -1 -1 -1 DECNET

Table 3-2




Specifies the Oracle MessageQ internal group name that is used to generate the include files. The Oracle MessageQ group name is a 1- to 16-character name.


Specifies the Oracle MessageQ internal number of the group. This number must be between 1 and 32000. The group number must be unique on the Oracle MessageQ bus. Multiple groups can be defined in this table with the same group number for the purpose of failover; however, only one, unique group number can be active on the Oracle MessageQ bus at any one time. See Managing Failover, for information on failover configuration.


Specifies the name of a system to connect to. Successive lines with various system names specify the backup systems for the group. A total of three lines for each transport may be specified. The first entry for each group determines the type of network transport used as the outgoing link.

For DECnet software, the system name is a 1 to 6-character node name that is not case sensitive.

For TCP/IP software, the system name is a 1 to 64-character node name that is case sensitive.

Gen Cnt

Specifies the generate connection field that indicates how cross-group connections are reestablished after a network failure.

N-Never generate an outgoing connection.

Y-Automatically attempt to reconnect using the reconnect timer.

D-Connections are disabled. No connection can occur until explicitly enabled using the LINK_MGT message. Refer to Oracle MessageQ Programmer's Guide.

Buf Warn

Also known as Threshold. Specifies the value for dynamic memory consumption at which congestion control will begin for this cross-group connection. This is not supported in MessageQ for OpenVMS version 4.0A or version 5.0.

Buf Pool

Specifies the optional parameter that overrides the default write buffer pool size for a communications link. It is specified in 1024-byte increments and the default value is 256 (giving a total of 256 x 1024 bytes). This value may need to be changed to accomodate large messages (up to 4MB) as described in Sizing and Tuning the Oracle MessageQ Environment, under Buffer Pool Parameter.


Specifies how often the link drivers attempt to reconnect to a communications link. You can specify separate time values for each network link. This parameter is specified in seconds. The following are valid settings for this parameter:

  • -1 Default-Default time of 30 seconds

  • 0 OFF-Only attempts to connect during startup and when explicitly requested

  • 15 Timer-Time, in seconds, to retry the remote link connection


Specifies the delay, in seconds, that a sender must wait before using a new window when the receiver is congested. The default value for this field is 1. Its minimum value is 0 and maximum is 2147483647.


Specifies the maximum transmission window size, in messages, for this cross-group link. The default value for this field is 250.

Transport Type

Indicates the transport mechanism used for cross-group connections. Valid entries are DECNET and TCPIP.


For transport type TCPIP, this field is the TCP/IP socket address (port number) endpoint. This port number ranges from 1024 to 65535 inclusive. Using endpoint numbers under 5000 is recommended. For DECNET transport this field is unused.

Cross-group Connection Table Fields

Table Entry Guidelines

The local group in the cross-group connection table must have data entered for each transport mechanism used within the group. You can use DECnet or TCP/IP as transport mechanisms. When TCP/IP is defined as the transport for the local group that is booting, the COM Server automatically starts up the TCP/IP link driver. When DECnet is specified, the COM Server automatically starts up the DECnet link drivers.

There are two types of DECnet transports:

Under normal situations, the Oracle MessageQ protocol handshake correctly chooses between these two transports and establishes the link. Specify DECNET as the transport section of the Cross-group Connection table to allow Oracle MessageQ to determine which DECnet link driver to use.

You can explicitly choose a specific driver for a Cross-group connection by specifying DECNETV2 or DECNETV3 as the transport type rather than DECNET. DECNETV2 selects the COM Server for the transport, while DECNETV3 selects the DECNET link driver (DECNET_LD). DECNETV2 is not supported when attempting to connect to a non-VMS platforms.

There can be a maximum of three entries for the same group/transport pair. Listing 3-2 shows the cross-group connection table for a group named CENTRAL with a group number of ten. There is a maximum of three possible hosts for a group named GROUP1.

Listing 3-2 Maximum Entries in Cross-group Connection Table

%XGROUP ***** Cross-Group Connection Table ******
* gen buf buf recon dly win transport
*gname gnumber node cnt warn pool sec sec msg type endpt
*--------- ------ ------------------- --- --- --- --- --- --- ----- -----
CENTRAL 10 myhost Y -1 -1 -1 -1 -1 TCPIP 10010
GROUP1 1 host1 Y -1 -1 -1 -1 -1 TCPIP 10001
GROUP1 1 host2 Y -1 -1 -1 -1 -1 TCPIP 10001
GROUP1 1 host3 Y -1 -1 -1 -1 -1 TCPIP 10001

Remote groups that are not listed in the Cross-group Connection Table can connect to your group if the XGROUP_VERIFY parameter in the Profile section is set to NO. In the previous example, if cross-group verify is disabled, connections from GROUP1 on any host will be accepted by CENTRAL. To limit access by unlisted groups, set XGROUP_VERIFY to YES. (Refer to Oracle MessageQ Security, for more information on security.)

Using Message Routing

Oracle MessageQ uses message routing to exchange messages between systems that do not have a direct network link.

The following topics are covered in this section:

Routing Tables

Oracle MessageQ message routing uses either static or dynamic tables as shown in the following table:

Table 3-3



Static tables

These are the cross-group connection table and routing table of the DMQ$INIT.TXT file.

Dynamic tables

These tables are built out of the incoming cross-group messages from previously unknown groups. Through the process of route discovery, the local system learns the return path of a message sent from an unknown group.

Message Routing Methods

Figure 3-1 shows a sample configuration requiring full message routing capabilities. It describes the next hop that a message must take to reach the target group. It contains three message server groups capable of performing message routing. Each server group has a direct connection to each of the other server groups. The client groups each have a single connection to a server group. They depend on the server group to route all message traffic to the correct target group and learn the backlink from the route messages they are sending back.

Figure 3-1 Sample System Routing Configuration

Groups 3, 4, and 5 are server groups that provide message routing services to the other groups.

Configuring and Loading the Tables

Groups can be defined in either the cross-group connection table or the routing table but not both. Duplicated entries are automatically deleted from the routing table.

All routing information entered in cross-group connection table and the routing table is loaded when the group starts up. There are two ways the routing table is loaded: using either the DMQ$LOADER or route discovery.

Once you have determined your routing configuration, you can create the appropriate entries in the cross-group connection and routing table sections of the DMQ$INIT.TXT file. Create a routing table for each group by editing the routing table section of the DMQ$INIT.TXT file.

All routing information entered in the cross-group connection and routing table sections is loaded when the group starts up.

DMQ$INIT Routing Section

The %ROUTE section of the DMQ$INIT.TXT file is used to load the initial routing configuration. This section contains two columns of information as described in Table 3-4.

Table 3-4 %ROUTE Section Column Definitions



Target group

Specifies the number of the remote group that is the intended destination of messages.


Lists the group number which forms the network link between the local group and the remote target group.

Note: Refer to Editing DMQ$INIT to Configure a Group on how to access and edit the cross-group connection table of the DMQ$INIT.TXT file.

For example, in order to build a DMQ$INIT.TXT file for the group 3 (configuration shown in Figure 3-1), entries are needed for all groups directly connected to it. All other groups will require an entry in the Routing Table in order to compute the next hop for the message.

Figure 3-3 shows a sample of the cross-group connection and routing table sections.

Listing 3-3 4-3 Sample Routing Table

-------------------------------------------------------------------------------%XGROUP      ***** Cross-Group Connection Table ******
* gen buf buf recon dly win transport
*gname gnumber node cnt warn pool sec sec msg type endpt
*--------- ------ ------------------- --- --- --- --- --- --- ----- -----
Server_1 3 Moe Y -1 -1 -1 -1 -1 DECNET
Server_2 4 Larry Y -1 -1 -1 -1 -1 DECNET
Server_3 5 Curly Y -1 -1 -1 -1 -1 DECNET
*Client_1 1 Sleepy N -1 -1 -1 -1 -1 DECNET
*Client_2 2 Doc N -1 -1 -1 -1 -1 DECNET
*Client_3 6 Dopey N -1 -1 -1 -1 -1 DECNET
*Client_4 7 Grumpy N -1 -1 -1 -1 -1 DECNET
%ROUTE * initial routing table
* Target Route-Thru
* Group Group
* ------ ----------
1 3 * Group 1 is routed thru Group 3
2 3 * Group 2 is routed thru Group 3
6 5 * Group 6 is routed thru Group 5
7 5 * group 7 is routed thru Group 5

Selecting the TCP/IP Link Driver

Oracle MessageQ for OpenVMS offers link drivers for several popular TCP/IP products including:

TCP/IP link drivers are mutually exclusive; therefore, you must select one driver. The DMQ$TCPIP_LD logical name indicates the selection and must exist prior to starting the group. This logical can be defined manually, or is defined automatically by the DMQ$BOOT.COM procedure. Define the DMQ$TCPIP_LD logical name as DEC to start the DEC/UCX link driver, PSC to start the TCPware link driver, or TGV to start the MultiNet link driver.

You can edit the DMQ$BOOT.COM procedure to start any of these drivers by changing the value associated with the DMQ$TCPIP_LD logical name. Access the DMQ$BOOT.COM procedure using the CUSTOMIZE option on the Oracle MessageQ main menu. Refer to Oracle MessageQ Main Menu and Utilities, or the DMQ$STARTUP procedure in Defining the Message Queuing Environment.

Edit the DMQ$BOOT.COM file, changing the commenting in the following lines:

$ tcpip_ld       = "DEC"   ! Use the DEC/UCX  TCP/IP LinkDriver
$!*** tcpip_ld = "TGV" ! Use the Multinet TCP/IP LinkDriver
$!*** tcpip_ld = "PSC" ! Use the TCPware TCP/IP LinkDriver
$!*** tcpip_ld = "" ! Select TCP/IP LD at SYSTEM level

The default setting for DMQ$TCPIP_LD is DEC. Change the commenting in the file to change the setting. Use a pair of quotation marks with no value ("") to suppress the creation of the logical name in the Oracle MessageQ logical name table. This allows the logical to be created at the system level, thereby, controlling multiple groups simultaneously.

For example, you select link drivers at the system level as follows:




Sharing Group Configuration Files

Groups can share the same configuration, log, and MRS directories. Sharing configuration files is convenient when many groups have the same configuration. This is common in VMScluster environments, where there are groups running on each cluster member.

Note that the names of the log and MRS files of each group contain the bus ID and group ID of each message queuing group. These tags in the file names allow you to distinguish the files even if they are in the same directory as another group's files.

Listing 3-4 shows how to start a group with group ID 5, bus ID 4 with the same configuration, log and script files as a group with group ID 6, bus ID 4.

Listing 3-4 Sharing Configuration Files

%DMQ-S-SETLNM, Set to MessageQ
LNM table DMQ$LNM_0004_00006
$ sho logical DMQ$USER
"DMQ$USER" = "DMQ$DISK:[DMQ$V50.USER.0004_00006]" (DMQ$LNM_0004_00006)
$ sho logical DMQ$LOG
"DMQ$LOG" = "DMQ$DISK:[DMQ$V50.LOG.0004_00006]" (DMQ$LNM_0004_00006)
$ @DMQ$EXE:DMQ$STARTUP 4 5 "" Y "" -
DMQ$DISK:[DMQ$V50.USER.0004_00006] -

When message queuing groups share the same DMQ$USER area, they execute the same DMQ$BOOT.COM command procedure that defines all the logical names. If you make no changes to DMQ$BOOT.COM file, the logical name DMQ$MRS is the same for those groups, and the MRS files of the groups will be on the same disk.

Note: Locating MRS files of multiple groups on a common disk can have significant performance impact. Refer to Configuring Message Recovery, for more information.

Suppressing DECnet Intrusion Alarms

If you attempt a cross-group connection to a nonactive group using the DECnet transport, Oracle MessageQ attempts to start a default DECnet object. If the DECnet default account has been eliminated from the system on which the group is running, DECnet intrusion alarms are generated every time a Oracle MessageQ group attempts to connect to a nonactive group.

You can eliminate DECnet intrusion alarms by creating a dummy DECnet object to handle the connection attempt. The dummy DECnet object is configured to accept and then immediately drop the connection.

The following steps describe how to create a dummy DECnet object:

  1. Use the OpenVMS AUTHORIZE utility to create an account for the dummy DECnet object. This account should be set up for network-only access, with TMPMBX and NETMBX privileges.

    When Oracle MessageQ binds to the named object, it is going to use its own security information (for example, that of the current process). Use the user, password, and file name of this process when the COM Server is not available.

  2. Add an entry to the NCP database.

    The Oracle MessageQ DECNETV3 protocol object is of the form DMQ_bbbbggggg and the DECNETV2 protocol object is in the form of DMQbbbbggggg, where bbbb is the bus number, zero-filled to the left, and ggggg is the group number, also zero-filled to the left. The DECNETV3 protocol object indentifies the bus and group number in hexidecimal format. The DECNETV2 protocol object is represented in decimal format.

    For example, for bus 50 group 35, the DECNETV2 protocol object name is DMQ005000035.

  3. Load the dummy object into the permanent database using the following NCP command:


    _  USER     user_id - 


  4. While Oracle MessageQ is not running, load the object into the volatile database using the following NCP command:

    NCP> SET OBJECT DMQ005000035 ALL 

  5. Restart Oracle MessageQ so that it can bind itself to the predefined DECnet object. When the target group is not running, inbound DECnet connection requests are handled in a valid account by the REJECT.COM command procedure. You must create REJECT.COM and supply the following content:

    $ CLOSE X
    $ EXIT

    When this command procedure executes, the inbound connection is established and the link is dropped immediately. This procedure allows the remote system to know you are not accepting new Oracle MessageQ connects immediately, but rather you are waiting for the outgoing timer on the remote end to expire. You can change the contents of the REJECT.COM command procedure to contain only the $ EXIT statement, however, connection timeouts will take longer.

Configuring DMQ$GMT_OFFSET for Network Communications

If you are using networking software, set the value of the Oracle MessageQ logical name DMQ$GMT_OFFSET. DMQ$GMT_OFFSET is defined as the difference in hours between the time zone of the local system and Greenwich mean time (GMT). This value is used by the cross-group protocol and can seriously affect throughput if set improperly. Table 3-5 lists the GMT offsets for most time zones around the world.

Table 3-5 GMT Offsets

Geographic Area


Daylight Offset

Western Europe


- 1

Central Europe

- 1

- 2

Eastern Europe

- 2

- 3

Eastern U.S.



Central U.S.



Mountain U.S.



Pacific U.S.



Alaska U.S.



Hawaii U.S.




- 9


Hong Kong

- 8



- 8


For example, to configure a system set to the Eastern Standard Time (EST), enter the following command: