|
|
|
|
|
|
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
|
Method |
Description |
Using |
|
Direct |
Between systems that share a network link |
Cross-group connection table |
|
Indirect |
Between nodes that do not share a network link |
Message routing with either Oracle MessageQ routing table, DMQ$INIT.TXT, or dynamic tables |
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 ipaddr1.company.com Y -1 175 -1 -1 -1 TCPIP 2001
*GR1_TCP 1 ipaddr2.company.com 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 ipaddr3.company.com Y -1 175 -1 -1 -1 TCPIP 2002
*GR1_TCP 1 ipaddr3.company.com 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
*
*
%EOS
Table 3-2
|
Field |
Description |
|
Gname |
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. |
|
Gnumber |
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. |
|
Node |
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. |
|
Recon |
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:
|
|
Dly |
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. |
|
Win |
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. |
|
Endpt |
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. |
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
*
*
%EOS
---------------------------------------------------------------------------
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:
Oracle MessageQ message routing uses either static or dynamic tables as shown in the following table:
Table 3-3
|
Method |
Description |
|
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. |
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.
|
Column |
Purpose |
|
Target group |
Specifies the number of the remote group that is the intended destination of messages. |
|
Route-thru-group |
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
*
%EOS
*
%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
%EOS
-------------------------------------------------------------------------------
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:
$ DEFINE/SYSTEM/EXEC DMQ$TCPIP_LD "DEC" ! DEC TCP/IP
or
$ DEFINE/SYSTEM/EXEC DMQ$TCPIP_LD "PSC" ! TCPWARE
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
$ @DUA1:[DMQ$V50.EXE]DMQ$SET_LNM_TABLE 4 6
%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] -
DMQ$DISK:[DMQ$V50.LOG.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:
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.
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.
NCP> DEFINE OBJECT DMQ005000035 NUMBER 0 -
_ USER user_id -
_ PASSWORD password FILE REJECT.COM
NCP> SET OBJECT DMQ005000035 ALL
$ OPEN X SYS$NET
$ 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.
|
Geographic Area |
Offset |
Daylight Offset |
|
Western Europe |
0 |
- 1 |
|
Central Europe |
- 1 |
- 2 |
|
Eastern Europe |
- 2 |
- 3 |
|
Eastern U.S. |
+5 |
+4 |
|
Central U.S. |
+6 |
+5 |
|
Mountain U.S. |
+7 |
+6 |
|
Pacific U.S. |
+8 |
+7 |
|
Alaska U.S. |
+9 |
+8 |
|
Hawaii U.S. |
+10 |
+9 |
|
Japan |
- 9 |
. |
|
Hong Kong |
- 8 |
. |
|
Singapore |
- 8 |
. |
For example, to configure a system set to the Eastern Standard Time (EST), enter the following command:
$ DEFINE/SYSTEM DMQ$GMT_OFFSET "+5"
|
|
|
Copyright © 2000 Oracle Systems, Inc. All rights reserved.
|
15 Timer-Time, in seconds, to retry the remote link connection