Prior to this release, cross group AVAIL/UNAVAIL messages only worked for adjacent groups that were directly linked to the subscribing group. In Version 4.0A , a process can register to receive AVAIL/UNAVAIL messages containing queue state information for queues that are on remote groups that have routing table entries and are not directly linked to the group of the subscribing process.
Note that the SBS Server must be enabled in order for the message
queuing group to provide AVAIL services services, this includes routing
groups. AVAIL and SBS services can only support routing if the routing
groups have the SBS Server enabled.
1.2.6 Self-Describing Messaging (SDM)
Self-describing messaging is a new form of MessageQ messaging that provides automatic data marshaling between platforms that have different data formats. SDM provides an API for building messages that carry both data content and description. The internal message format is opaque to user applications. Fields are inserted as TAG/VALUE pairs into an SDM message buffer using the SDM API, and then extracted by the receiver in a similar fashion.
The SDM API consists of the following new functions:
For information on how to use SDM, refer to the BEA MessageQ Programmer's Guide .
1.2.7 Support for Large Messages
MessageQ can now send and receive messages of up to 4MB using
buffer-style and handle-style messaging. For information on how to send
and receive messages larger than 32K, refer to the BEA MessageQ Programmer's Guide .
1.2.8 Changes to The Global Buffer Allocation Algorithm
The size of the largest message buffer has been increased from 32,000
to 65,000 bytes. Messages may now span global buffer pool buffers, a
feature that was added to support message sizes of up to 4MB. The
algorithm that fits a message into a buffer in global memory has been
changed so that all pools are searched to find buffers for a given
message. This changes the meaning of the return code PAMS:REMQUEFAIL to
mean that insufficient global memory buffers were found to contain a
particular message request.
1.2.9 Dynamic Binding of Queue Addresses to Local and Global Queue Name
MessageQ Version 4.0A adds a new API function called
pams_bind_q. This API function has been added to enable
applications to associate a queue address, including temporary queues,
with local and global queue names that may be referenced by
pams_attach_q and pams_locate_q. See the BEA MessageQ Programmer's Guide
for details.
1.2.10 Global Naming
Global naming enables MessageQ applications to refer to message queues in remote groups by name without having to define the name in each referring group's initialization file. With MessageQ V4.0A, global name lookups have been moved out of the process's context and into a Naming Agent (NA) Server. The Naming Agent Server can be configured to use a large distributed namespace such as DNS, or can be set up to use a MessageQ namespace based on flat configuration files.
If DNS is chosen, it need only be installed on the network nodes where the Naming Agent is located, reducing the licensing and configuration requirements associated with the namespace.
If a flat file namespace is chosen, it can reside on a system where files may be shared either via VAX cluster sharing or NFS. Multiple Naming Agents may share these files.
Note:
A %NAM section has been added to DMQ$INIT.TXT to specify access to a Naming Agent and a backup Naming Agent. In addition, a new field, DEFAULT_NAMESPACE_PATH has been added to the %PROFILE section.
See the BEA MessageQ Installation and Configuration Guide for OpenVMS for details on configuring the MessageQ Naming
Agent.
1.2.11 Changes to MessageQ Application Programming Interface (API) Functions
The following MessageQ API functions have been changed for Version 4.0A
. Refer to the BEA MessageQ Programmer's Guide for complete reference descriptions of
these new and changed programming functions.
1.2.11.0.1 PAMS_ATTACH_Q and PAMS_LOCATE_Q
These routines have changed to allow look up of global queue references. As a result, the first null argument has been replaced with a timeout argument so that the time allotted for this function to complete can be controlled. The data type for this argument has changed from char * to int32 * which should not affect the running of existing applications.
Depending upon the programming language and compiler you are using, you may receive warning or error messages. To eliminate these warnings or error messages during compilation or runtime, update your applications to use the correct data type for this argument and rebuild your application.
Beginning with Version 4.0A , the settings to the name_space_list argument have been changed as follows.
| Obsolete | New |
|---|---|
| PSEL_TBL_DNS_CACHE | PSEL_TBL_BUS |
| PSEL_TBL_DNS_LOW | PSEL_TBL_BUS_LOW |
| PSEL_TBL_DNS_MED | PSEL_TBL_BUS_MED |
| PSEL_TBL_DNS_HIGH | PSEL_TBL_BUS_HIGH |
The previous name_space_list settings are obsolete but are still supported for this release.
The maximum queue name length has been increased from 31 to 255 characters and names are now case sensitive.
Note:
This can impact your existing applications. Alias names can be set up in the %GNT section of the DMQ$INIT.TXT file to match all usages that your application's need. So "Freds_Queue" and "FREDS_QUEUE" can both refer to the same queue.
With this release, pams_locate_q can be called prior to
attaching to the MessageQ Bus. The pams_locate_q routine will
cause an attachment to the bus but will not assign a queue which means
that the process must either complete the attachment with
pams_attach_q at later time or call pams_exit to
detach from MessageQ.
1.2.11.0.3 Changes to The Messaging Routines to Enable SDM Encoded Messages
The pams_get_msg(a,w) routines have extended the meaning of
the len_data argument to allow a new setting of PSYM_MSG_HANDLE and the
pams_put_msg routine's meaning of msg_size. When this argument
is set to PSYM_MSG_HANDLE it indicates that the message buffer contains
a message handle and not a buffer. Message handles are used to send SDM
messages. Please see the BEA MessageQ Programmer's Guide for details on SDM messaging.
1.2.11.0.4 PAMS_PUT_MSG Eliminates The Restriction of an MRQ as a Response Queue
The pams_put_msg function has been enhanced to allow
multireader queues (MRQs) to be specified as response queues when a
WF_xxx delivery mode is used.
1.2.12 Enhancements to Message Recovery Services
Message Recovery Services on MessageQ for OpenVMS systems offer significant performance improvements over Version 3.2 in journal file creation (i.e. DQFs and SAFs). This change significantly reduces the chance of a message recovery stream having to wait for a journal file to be created.
Journaling file management has been enhanced in support of large
messages. If a message spans multiple chunks that cannot all fit into
the current journal file then the file will be extended to hold the
entire message. This applies DQF, SAF, PCJ, & DLJ journal files.
1.2.13 Automatic Synchronized Cluster Group Failover
Support has been added to allow automatic synchronized cluster group failover. The logical DMQ$GROUP_SYNCHRONIZE with the default of YES has been added to the COM section of DMQ$SET_SERVER_LOGICALS.COM. Setting this logical to "NO" will require that failover be managed by the system manager.
This new feature allows for a Primary group and up to two Secondary groups. The Primary group will startup normally posting a message in the EVL log indicating that this group is the primary group. The Secondary groups will only start the EVL and COM Servers, posting a message in the EVL log which indicates that this group is waiting to become the primary.
Secondary groups can perform local messaging while they are waiting to become the primary group. However, only the primary group is allowed to do cross group messaging.
When the primary goes down the Secondary group will gain the lock and start any necessary servers (i.e. LD, MRS, SBS, NA, etc) now becoming the primary. When the original primary group comes back up it will become a secondary group.
The name of the cluster lock used to control automatic synchronized
failover is DMQ$PRIMARY_GRP_bbbb_ggggg.
1.2.14 Distribution of Documentation Online
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 OpenVMS , and these release
notes available in HTML format. These books replace the standard
OpenVMS help file found in prior MessageQ kits. You can read MessageQ
Online Documentation with a World Wide Web browser. Two browsers,
Mosaic, and Netscape are available on the OpenVMS Internet Products
Suite CD that ships with along with OpenVMS.
1.2.15 Runtime Loading of PAMScript Symbols
The PAMScript Facility has been enhanced to allow the run-time loading
of script symbols rather than building them into the group specific RTL
DMQ$PSSRTL. This change results in the simplification of system
management, elimination of a group specific RTL, and utilization of the
group namespace for queue name lookups.
1.2.16 Start and Stop Commands for Queues
MessageQ Version 4.0A adds features for starting and stopping queues
using the DMQ$MGR_UTILITY program. This feature allows a system manager
to externally control the queuing activity in one or more queues on a
running system.
1.2.17 Start and Stop Commands for Client Library Services (CLS)
MessageQ Version 4.0A adds features for starting and stopping CLS using
the DMQ$MGR_UTILITY program. This feature allows a system manager to
externally control the Client Library Services on a running system.
1.2.18 Added Support For Process Software Corporation (PSC) TCPware
In this release, the MessageQ Link Drivers and Client Library Services
supports PSC TCPware TCP/IP network software. See BEA MessageQ Installation and Configuration Guide for OpenVMS for
details on how to select this support. The minimum version of PSC
TCPware supported is V5.0-4.
1.2.19 Changes to Group Initialization File
The following changes have been made to the group initialization file, DMQ$INIT.TXT:
MessageQ Version 4.0A provides a command procedure called DMQ$CVT.COM that converts a Version 3.2 group initialization file into a Version 4.0A group initialization file. Refer to BEA MessageQ Installation and Configuration Guide for OpenVMS for complete information on how to configure MessageQ and how to convert existing configuration files.
Note:
Refer to Section 3.1.1 for a information on a known problem with the DMQ$CVT.COM utility.
MessageQ Version 4.0A supports graceful group shutdown. During a graceful shutdown MessageQ waits until all queues have been drained before stopping the group.
A new parameter, "stop_fast", has been added to the DMQ$SHUTDOWN.COM procedure to support graceful group shutdown. Setting this parameter to NO will enable graceful shutdown. This parameter is optional with a default of YES.
$DMQ$EXE:DMQ$SHUTDOWN bus_id group_id [rtl_deinstall] [stop_fast]
Queue names are no longer padded with blanks. Instead they are NULL
terminated.
1.2.22 MessageQ Client for OpenVMS support
The MessageQ Client is now supported on OpenVMS and is automatically included in the MessageQ base kit installation. However, the MessageQ Client for OpenVMS may be installed independently of the MessageQ Server for OpenVMS kit.
The MessageQ Client is a light-weight implementation of the MessageQ Application Programming Interface that utilitizes a MessageQ Server to perform the queueing operations.
1.2.22.1 Using the OpenVMS MessageQ Client with the Server kit installed
The OpenVMS MessageQ Client users can easily co-exist with those using
the standard MessageQ Server installation however careful attention
must be paid to keeping the DMQ$LNM_TBL logical name tables separated.
If, for example, you are using the standard MessageQ and want to switch
to an application that has been linked with the MessageQ client, the
recommended way is to logoff your current process, then login again and
obtain the client logical names using DMQ$CL_SET_LNM_TABLE. An
alternate method is to use "@DMQ$SET_LNM_TABLE bus group
UNSET" to remove the standard logical names from your process before
executing DMQ$CL_SET_LNM_TABLE. Please refer to the OpenVMS MessageQ
Client Guide in the section called post-installation tasks, for
additional information on this subject.
1.2.23 PAMS V2.5 compatible DECnet object is no longer supported
The PAMS V2.5 compatible DECnet object is not supported in this release of MessageQ for OpenVMS. MessageQ groups must switch to using the default DMQ DECnet objects.
The PAMSV25_MODE parameter has been removed from the V4.0A group
initialization file.
1.2.24 Client Library Server no longer supports same-client reconnect
In previous version the CLS supported same-client reconnect to permanent queues. This allowed a client to attach multiple times to the same queue without receiving the PAMS:DECLARED error status. This capability has been removed from the CLS because it was non-standard behavior.
The primary impact of this change will be on Visual Basic developers who run their application in design mode, attach to a permanent queue,and then stop the application without detaching. They will receive PAMS:DECLARED the next time they run the application.
We recommend that Visual Basic developers always perform a
pams_exit from the Form_Load event before calling any other
MessageQ API functions. This action will terminate any previously open
connection and allow the pams_attach_q to succeed.
1.2.25 MessageQ for OpenVMS has been tested to be fully Year 2000 compliant
BEA MessageQ Version V4.0A has been fully tested to be Year 2000
compliant on the shipping versions of Unix, NT and OpenVMS.
1.2.26 CUSTOMIZE command procedure updated to ask before purging files
The CUSTOMIZE command procedure has been updated to prompt before purging. Previously, the CUSTOMIZE common procedure automatically purged the modified files without asking. It is recommended that modified configuration files not be purged until after they have been tested.
The corrections described in this chapter include all of the software
modifications, corrections, and updates that have been made to MessageQ
for OpenVMS since the original V3.2-00 kit.
2.1 Message Recovery Services (MRS)
This section describes corrections to the Message Recovery Services for
Version 4.0A .
2.1.1 Recoverable Messaging Intermittently Stops to Older MessageQ Versions
MessageQ for OpenVMS V2.x uses state notification and a "pull" protocol
to drive recoverable messaging to adjacent nodes. This protocol can be
fragile if control messages or state notification events are lost due
to insufficient queuing resources, causing recoverable messaging to
stop. While messaging usually starts after a link transition, in some
cases a group must be restarted to cause messages to flow properly.
Support has been added to allow deadlock detection and restart for
stopped message streams that are using the older protocol.
2.1.2 Corrections to Target Presentation Quota And Journal File Cleanup
This version of MessageQ for OpenVMS incorporates a change to the way the MRS Server calculates the Target Presentation Quota. First, this change allows the quota to be calculated based on the specified pool quota control, specifically:
Another MRS change facilitates faster startup of the MRS Server when large numbers of queues with DQFs exist which may have empty journals within a DQF file set. A new logical name, DMQ$MRS_CLEANUP_ON_CLOSE, has been added to request that the MRS Server perform the file cleanup on an explicit DQF close request.
When this logical is set to "YES" the MRS server will do file
cleanup (delete the journal file if it is empty) on an explicit close
request from the user. This request could be from the disable ALL
journaling command or from the DQF or SAF set CLOSE request. The MRS
section of the DMQ$SET_SERVER_LOGICALS.COM procedure in
[DMQ$V40.USER.TEMPLATE] has been updated to allow the setting of this
logical name. Valid settings are YES and NO.
2.1.3 Interoperability Problems with MessageQ for OpenVMS V2.X Systems
Corrected two MRS problems associated with the transfer of recoverable messages from a MessageQ for OpenVMS V2.X system that uses the older V1.0 MRS protocol, as follows:
%PAMS-E-BADSEQ, Message Sequence number unknown to MRS
Corrected the following two MRS problems associated with file access problems:
Corrected a problem which occurred when the DQF file quotas were
exceeded. This correction suppresses repetitive DQF write error
messages when the DQF file quota has been exceeded. It also causes the
sending MRS Server to reduce the flow of messages to the target MRS
Server until the receiving MRS Server is once again able to handle
incoming messages.
2.1.6 MRS Did not Close all Files When Journaling Was Disabled
Corrected a problem with hot failover in which free files were not
being disabled when journaling was disabled. This problem resulted in
file open errors showing a -37 status and with journal file extensions
being renamed to .DERR or .SERR.
2.1.7 SAF Message Traffic Stalled And Messages Lost Between OpenVMS and UNIX/Windows NT
Corrected a problem with the transfer of SAF message between message queuing groups running on OpenVMS systems and message queuing groups running on UNIX or Windows NT systems. The problem results in lost SAF messages. The problem also makes it appear as though recoverable message traffic is stalled if a large number of messages are already in the SAF. The problem stems from MRS Server's failure to properly switch its MRS-MRS protocol level correctly when a non-OpenVMS message queuing group connects. This problem only occurs under the following conditions:
Corrected a problem where UMA SAF messages were always getting marked
as PAMS:POSSDUPL when sending to a pre-V3.0 MessageQ for OpenVMS system.
2.1.9 SAF Messages Marked As PAMS__STALE
Corrected a problem with the checkpoint file logic associated with a
checkpointed time that was far into the future. Under certain
instances, this condition resulted in the target MRS Server believing
that the message had already been delivered and the status PAMS:STALE
was returned back the sender of the message.
2.1.10 SAF Messages Delivered Out Of Order
Corrected a problem which caused SAF messages to be delivered out of
order when switching between the older V1.0 and the current V2.0
recovery protocols (i.e. MessageQ V3.0 or higher).
2.1.11 SAF Messages Incorrectly Flagged As Incomplete
Corrected a problem where the MRS Server was incorrectly detecting incomplete SAF messages which resulted in those messages not getting delivered to to the target queue.
The side effects of this problem result in a failure to properly clean
up empty SAF files and a probable loss of one or more SAF messages
within the SAF stream. This problem appears to occur only under heavy
load with varying message sizes.
2.1.12 Internal MRS Traffic Caused User Message Sends To Timeout
Corrected a problem which occurred under heavy SAF load conditions that
would cause the SAF transfer control messages to shut-out normal user
message traffic. This would be seen as PAMS:TIMEOUT being returned by
pams_put_msg of recoverable messages.
2.1.13 MRS Server Sometimes Failed To Unblock Senders
Corrected a problem where the MRS Server failed to unblock senders of SAF messages that were directed to pre-V3.0 groups. This condition required multiple source streams all sending SAF messages to the same target queue.