|
|
Revision/Update Information: This document supersedes the MessageQ for OpenVMS Release Notes Version 3.2
Software Version:
BEA MessageQ for OpenVMS Alpha, Version 4.0A
BEA MessageQ for OpenVMS VAX, Version 4.0A
Copyright 1998 BEA Systems, Inc. All rights reserved.
This software and documentation is subject to and made available only pursuant to the terms of the BEA Systems License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from BEA Systems, Inc.
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the BEA Systems License Agreement and in subparagraph (c)(1) of the Commercial Computer Software-Restricted Rights Clause at FAR 52.227-19; subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, subparagraph (d) of the Commercial Computer Software---Licensing clause at NASA FAR supplement 16-52.227-86; or their equivalent.
Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems, Inc. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, AN WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA Systems DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIALS IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE.
BEA, BEA Builder, BEA Connect, BEA Jolt, BEA Manager, and BEA MessageQ,
are trademarks of BEA Systems, Inc. BEA ObjectBroker is a registered
trademark of BEA Systems, Inc. TUXEDO is a registered trademark in the
U.S. and other countries.
All other company names may be trademarks of the respective companies with which they are associated.
This chapter describes new and changed features of MessageQ for OpenVMS
Version 4.0A .
1.1 Before You Install MessageQ Version 4.0A
This section describes important information that you need to know before you install MessageQ for OpenVMS Version 4.0A .
1.2 New and Changed Features for MessageQ Version 4.0A
This section describes the new and changes features for Version 4.0A
release of MessageQ for OpenVMS:
Available in 4.0A
The installation procedure has been split into multiple parts so components can be independently installed. The installation menu displays the approximate number of blocks of disk space needed to install each component.
The following components are offered in the kit.
The base kit installation has been revised and simplified. The question relating to VAXC RTL linking, asked during a VAX/VMS installation, has been removed because DEC C is now used to build both the VAX and Alpha versions of MessageQ.
The online documentation for MessageQ for OpenVMS consists of the BEA MessageQ Introduction to Message Queuing , the BEA MessageQ Programmer's Guide , the BEA MessageQ Installation and Configuration Guide for each supported platform, and these Release Notes available in HTML format.
The OpenVMS Client kit installation installs the light-weight implementation of MessageQ which utilizes a MessageQ server to perform the queuing operations.
The MessageQ Demo kit has been removed from the installation procedure.
The MessageQ for OpenVMS installation now supports device size checking
for the Alternate Working Device (AWD) Option. Previously, the system
device was required to have the required amount of blocks in order for
an OpenVMS MessageQ installation to work correctly even when the AWD
option was specified. The installation has been updated to so that with
the AWD VMSINSTAL option selected, MessageQ may be installed with as
little as 1,000 blocks of system disk space (SYS$SYSDEVICE).
1.2.2 Changes to the MessageQ Include Files
The following changes have been made to the MessageQ include files:
The ability to distribute broadcast messages to any number of registered recipients is now available on all MessageQ server implementations. The default configuration for each MessageQ Version 4.0A group enables the use of Selective Broadcast Services (SBS). The SBS Server adds a new registration message API that uses RISC aligned fields. Endian translation of these new registration messages is automatically handled by the server. This API adds both significantly enhanced selection criteria and the ability to request statistics and state information. On OpenVMS, the prior message API will continue to be supported.
The following is a list of the supported interoperability between versions and platforms running the SBS Server in MessageQ for OpenVMS V4.0A.
In addition to the new SBS message API, the OpenVMS version of the SBS
Server adds a new Ethernet retransmission protocol which allows the
automatic recovery of lost message packets. This means that a receiving
SBS Server will be able to request lost message packet retransmission
up to a selectable depth of message packets. This feature allows the
SBS Server to attempt to recover lost messages identified by a sequence
gap. This feature combined with dual-rail support significantly
enhances the reliability of the optimized Ethernet broadcasting.
1.2.4.1 Configuring Optimized Ethernet Mode
The optimized Ethernet mode on the SBS server utilizes the hardware multicasting available with Ethernet controllers. Therefore, instead of simulating broadcasting by sending a message to each adjacent SBS server over the standard MessageQ links, it broadcasts one message to all listening systems on the bus. This mode has the advantage of scalability: a single copy of a message is transmitted across the network and is received only by those systems which have applications registered for the message's MOT. This facility thus improves network utilization by limiting the traffic per message placed on the network.
Because messages sent via direct Ethernet access are limited to 1500 bytes, the sending and receiving SBS servers handle the segmentation and reassembly of messages. This segmentation, coupled with network load, naturally increases the chance that a packet collision may result in a lost packet at one or more receiver systems. A lost packet, in turn, results in a lost message, which is reported to receiving applications as a broadcast sequence gap.
Note:
Although MQ V4.0A supports message sizes up to 4Mb, optimized Ethernet mode limits message sizes to 32000 bytes.
In the following discussion, refer to the Installation and
Configuration Guide, Chapter 7 on setting up Selective Broadcasting,
Example 7-2, which shows the Server initialization section of the group
initialization file template, as well as the Table 7-2, which describes
parameters and fields.
1.2.4.2 Dual-rail Mode
MessageQ provides two features to increase the reliability of messages sent using Optimized Ethernet Mode. The first is "dual-rail mode," which means that SBS supports up to two (2) Ethernet devices per system. Using two Ethernet devices increases the chance that a missed packet resulting from a network collision will not result in a missed message. In dual-rail mode, the sending system writes a copy of the message to the devices specified in the DEVICE_1 and DEVICE_2 parameters for COMM_SERVICE with a value of DG_OLD. Receiving SBS servers construct a single copy of the message from packets received from both Ethernet devices. If a packet contained in a particular message is not received from either rail, a sequence gap message is to receiving applications which have requested sequence gap.
To configure dual-rail mode: specify the "Prot/Xport" field of the COMM_SERVICE as DG_OLD. Specify a valid device addresses for both Ethernet devices on your systems, insuring that you specify device unit 0 (e.g., ECA0:, EWB0:, etc.) Be sure that the Ethernet devices specified in the DEVICE_1 field of various groups are actually connected on the same network (and likewise for DEVICE_2). The simplest method for insuring this is to build single-rail configurations for all groups (i.e., just specify DEVICE_1) and use the DMQ$EXE:DMQ$SBS_EXAMPLE program to verify broadcast reception in each group. Repeating this test using the devices specified for DEVICE_2 as DEVICE_1 will insure that the final dual-rail configuration is properly configured.
The only field in the REGISTER line which is user-settable with this
service is the MOT. The transmit and receive silos are forced to their
default values of 1 and 5, respectively; the heartbeat parameters do
not affect this service.
1.2.4.3 RP/ETH Retransmission Protocol
There are some applications where broadcast messages need a higher probability of delivery than is provided by simple dual-rail redundancy. SBS provides a retransmission protocol by which a receiving SBS server which cannot construct a complete message may request it from the sending SBS server. If the sender still has the message in its cache, it will resend it to requesting system.
It is important to understand that the SBS retransmission protocol is not a recoverable delivery protocol. That is, messages sent to a MOT whose COMM_SERVICE is the retransmission protocol (RP/ETH) may still result in sequence gap at one or more receiver systems. This protocol is best suited to broadcast traffic with a predictable delivery rate.
The RP/ETH communication services operates as follows. Any message sent to MOT whose service is RP/ETH are placed in cache called the transmit silo after they are sent. The transmit silo size is measured in Message Assembly Buffers (MABs). Each MAB contains a complete copy of the largest message (up to 32000 bytes) that this queuing group can send or receive. MABs also contain sequencing information used to control retransmission requests. Transmit silos are first-in-first-out: the oldest message in the transmit silo is removed when a new message requires storage. The transmit silo size is specified by the Transmit Silo parameter in the REGISTER statement used to define the MOT.
If a missing segment is detected by a receiving SBS Server, it requests retransmission of the message from the point at which the first missing segment was detected. This request is sent via a high-priority message (transmitted via the standard MQ cross-group transport [TCP/IP or DECnet]) to the sending SBS server. The requested message fragment (which can be an entire message) is returned via a high-priority message, which is also transmitted via the standard MQ cross-group transport. If the message has already been flushed from the sending group's transmit silo, a sequence gap notification will be delivered to the receiving applications.
Each MOT using RP/ETH also has a receiver cache called the receive
silo. The receive silo is used accumulate messages to insure in-order
delivery to registered applications. For example, a sender may have
broadcast messages 46, 47 and 48 to an RP/ETH MOT but the receiver may
have received only messages 46 and 48. It is necessary for the
receiving system to hold message 48 until it has been a retransmitted
copy of message 47 has been received. Receive silo size is also
measured in MABs. The receive silo size is specified by the Receive
Silo parameter in the REGISTER statement used to define the MOT.
1.2.4.4 RP/ETH Receive silo rules
Receive silos are emptied according to the following rules:
SBS servers using optimized Ethernet provide timely detection of missing messages. Consider the case where a sending group broadcasts message 26, which is short enough to be contained in a single packet. Assume that a receiving group does not receive this packet due to a network collision. The receiving group would not detect that is missed message 26 until message 27 was broadcast. To prevent this condition, SBS servers using RP/ETH protocol exchange status inquiries on a periodic basis. The minimum interval between these inquiries is called the heartbeat and is specified in 1-millisecond units. Thus, if the heartbeat parameter were set to 1000, status polling exchange will occur no more than once per second. The HEARTBEAT statement specifies this value for a particular group.
Recognizing that MOTs may vary with respect to their expected traffic rates, MQ allows you to control the polling on a per-MOT basis. It does so with three parameters specified with the MOT in a REGSITER statement: maximum heartbeat, poll interval and dead poll interval. These values are multiples of the heartbeat specified for the group. Thus, if the heartbeat were set to 2000 (i.e., 2 seconds) and the poll interval were set to 2, the actions associated with the poll interval would be executed after 4 seconds had elapsed. The following example will show these parameters interact.
Assume that you have 2 groups: 30 and 31 using RP/ETH for MOT 5101. To simplify things, assume that group 30 is only sending broadcast messages and group 31 is only receiving these messages. The relevant parameters in the SBS section in group 31's initialization file are:
HEARTBEAT 1000 COMM_SERVICE 0 RP/ETH ! Transmit silo Recv silo Max HB Poll Dead Poll REGISTER 5101 10 10 4 5 10
Let's follow a sequence of operations:
Use of RP/ETH protocol will be most effective if you limit it to a small number of MOTs for which you have predictable traffic pattern. Specify the "Prot/Xport" field of the COMM_SERVICE as RP/ETH Specify valid device addresses for both Ethernet devices on your systems, insuring that you specify device unit 0 (e.g., ECA0:, EWB0:, etc.) Be sure that the Ethernet devices specified in the DEVICE_1 field of various groups are actually connected on the same network (and likewise for DEVICE_2). The simplest method for insuring this is to build single-rail configurations for all groups (i.e., just specify DEVICE_1) and use the DMQ$EXE:DMQ$SBS_EXAMPLE program to verify broadcast reception in each group. Repeating this test using the devices specified for DEVICE_2 as DEVICE_1 will insure that the final dual-rail configuration is properly configured.
Set all parameters on REGISTER line for each MOT using RP/ETH. Sending groups should specify more Transmit Silo MABs, and Receiving Groups should specifiy more Receive Silo MABs, to increase the likelihood of retransmission requests being fuilfilled. Note that each MAB requires a buffer equal to the size of the group's maximum message (up to 32000 bytes) plus 150 bytes, so you should expect to increase the PGFLQUO parameter in SBS Section of DMQ$USER:SET_SERVER_QUOTAS.COM to reflect this increased virtual memory demand.
Expect the tuning of this service to be an iterative process. There is a message-based API call which allows you to retrieve statistics for traffic and retransmission activity by MOT: see the sbs_status_req and sbs_status_resp messages in the Programmer's Guide.