This chapter describes all known problems or restrictions with MessageQ for UNIX Version 4.0A.
If the GROUP_MAX_BYTES parameter in the %PROFILE section of the group initialization file is set too high (such that it exceeds the maximum virtual memory size of a single process), the queuing engine incurs "out of memory" errors and will stop accepting enqueue requests until the condition is cleared. Setting the GROUP_MAX_BYTES parameter to 8MB is sufficient for most environments and can prevent this problem from occurring.
Applications using MessageQ AVAIL services to determine the availability of a queue may sometimes incorrectly receive an initial notification of UNAVAIL for a queue that is available. This message is followed promptly by an AVAIL notification indicating that the queue is available.
The MessageQ Version 3.2 journal file format is not compatible for use with MessageQ Version 4.0A Message Recovery Services. Therefore, you must empty your Version 3.2 journal files and delete them before starting a Version 4.0A message queuing group which uses the same journal file directory.
The MessageQ for UNIX Monitor utility does not allow monitoring of remote OpenVMS groups. Currently, the Monitor utilities running on UNIX and OpenVMS systems do not provide full interoperability because they do not support the same set of functions. This problem will be corrected in a future version of the MessageQ for OpenVMS product.
The pams_get_msg function does not currently allow selection of timers using a selection mask returned by the pams_set_select function.
If you are running HP-UX Version 10.20 on a system that has removed the transition links for compatibility with future versions of the operating system, (for example, using the tl_remove utility), you must execute the following commands in order to install and run MessageQ for HP-UX:
/bin and add a link within it to a directory called
/usr/bin/sh as follows:
mkdir /bin
ln -s /usr/bin/sh /bin/sh /lib and add a link within it to /usr/lib/dld.sl as
follows:
mkdir /lib
ln -s /usr/lib/dld.sl /lib/dld.sl
The Version 4.0A SBS for UNIX and Windows NT is capable of full interoperation using the MessageQ transport between all MessageQ Version 4.0 server platforms.
Note:
Interoperation between Version 4.0A SBS for UNIX and Windows NT and older SBS systems running on OpenVMS Version 3.2 (and earlier) is not supported.
On systems using MessageQ for UNIX prior to Version 4.0A, the log file may contain the following error message:
************ dmqgcp (12244) 11-SEP-1996 14:57:02 ************
gcp, unsupported PAMS message type
This message is generated by the Version 4.0 SBS server during its handshake with other potential SBS servers and can be ignored.
MessageQ for UNIX Version 4.0A AVAIL services do not interoperate with versions of MessageQ for OpenVMS prior to Version 3.2A. MessageQ for OpenVMS Version 3.2A is the minimum level for interoperation with UNIX Version 4.0A AVAIL Services.
All systems which will participate in AVAIL Services must have the SBS Server enabled, including routing groups. In addition, older UNIX Version 3.x systems wishing to use AVAIL Services with Version 4.0 systems must be adjacent nodes.
If you are running MessageQ on a system running HP-UX Version 10.20, the Monitor utility will not display properly unless you install patch number PHCO_11342 called the "Xcurses library cumulative patch". You can download this patch from the Hewlett Packard Electronic Support Center Patch Database at http://us-support.external.hp.com/. You can also obtain this patch via ano
When multiple applications perform a pams_bind_q operation to bind a queue address to a queue name, only the first application to perform this function will receive a success message. Subsequent applications receive the return status PAMS_BOUND indicating that the name is already in use. However, these applications can ignore the message and continue processing since the multireader queue has been successfully bound to the name.
In addition, when multiple applications are using a queue name to refer to a multireader queue, the first application to per-form the pams_bind_q function must remain running to provide the name server to the queue. Otherwise, when this application exits, the association of the name with the MRQ is terminated and the other applications in the environment will be unable to locate the queue.
For security reasons, the default behavior of MessageQ for UNIX systems requires all application processes that attach to a selected message queuing group have the same GID and UID as the user who started the group. Processes with a different UID or GID than that of the process starting the group can attach to the group. However, all subsequent calls will fail when the queuing engine attempts to check the existence of processes with a different UID or GID.
This problem can be eliminated by granting the queuing engine (dmqqe) set-user-id status and changing the ownership to root as shown below:
# chown root /usr/kits/DM*vvv/bin/dmqqe
# chmod u+s /usr/kits/DM*vvv/bin/dmqqe
where:
* is the platform you are on as follows:
A = Digital UNIX
Q = all other UNIX platforms
vvv is the current version of the product
(i.e. 202, 30A, 310, 400).
Note that the Queuing Engine spawns no child processes, creates no files, writes only to the designated log file for a given group, has no interactive user interface, and uses the "suid" privilege only for determining whether application processes are still active. Assigning suid privilege to the Queuing Engine poses no threat to overall system security beyond allowing all GIDs and UIDs access to the MessageQ message queuing groups on the machine in question.
Manual reference pages do not display properly on AIX systems.
MessageQ for UNIX places key files that allow processes to locate shared memory, semaphores, and other IPC resources in a directory called /var/tmp/dmq. On some UNIX systems, most notably Digital UNIX (formerly DEC OSF/1) and AIX, the operating system is configured with a crontab entry that periodically deletes files that have not been accessed for a preselected time interval. This delete operation can include the key MessageQ files placed in the /var/tmp/dmq directory. If these files are deleted, both MessageQ processes (such as the link drivers and the Monitor utility) and user application processes will no longer be able to attach to a MessageQ group.
To prevent the deletion of these key files while MessageQ is running, the crontab entry must be modified to avoid deleting the files in /var/tmp/dmq or removed completely. A typical crontab entry which removes files after they have not been accessed for two days appears as follows:
20 4 * * * find /var/tmp -type f -atime +2 -exec rm -f {}\;It is important to note that MessageQ script processing on UNIX systems does not begin until the target process issues a pams_get_msg or pams_get_msgw procedure call. So, for example, if you send a script to a target application that contains commands to start script processing and capture message input, script processing does not begin until the target application issues the pams_get_msg function and obtains the script messages.
The UNIX client library sets specific limits on MessageQ
function parameter values that may have very large values on MessageQ server systems. The limits for the function parameters reduce the network message size for messages transmitted between client applications and the remote Client Library Server running on the MessageQ server group.
The limits implemented for the functions are as follows:
In all other respects, the MessageQ function calls implemented by the UNIX Client library are identical to those provided by MessageQ V3.1 or higher on other platforms.