HP OpenVMS Systems

Ask the Wizard

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Quick Links

» Non-javascript page
» Ask the Wizard

Test Drive OpenVMS

» OpenVMS I64 test drive
» Java test drive

Other information resources available to you include:

» OpenVMS freeware
» ECO kits, software and hardware support, prior version support
» Alpha SRM, ARC, and AlphaBIOS firmware updates
» ENCOMPASS - HP user group
» OpenVMS software downloads, OpenVMS freeware CD-ROM
» OpenVMS firmware locations
» DECconnect passive adaptor charts
» Cables reference guide
» MicroVAX console commands
» OpenVMS student research

Select a topic below to see Questions Frequently Asked by partners

» Using the online documentation library(installing BNU from the asap SDK)
» Global sections(how to create and use.)
» xx$CREATE_BUFOBJ system service(usage)
» Ethernet address(methods of determination)
» Shareable images(cookbook approach to creating one)
» Sharing data/code at absolute addresses(a guide with examples)
» Determining the Alpha microprocessor
» Using GETSYI to get hardware status

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Ask the Wizard Questions

Problems with one process communicating with its subprocess through a mailbox

The Question is:

I am facing one serious problem. I have one process communicating with its subprocess through a mailbox. Communication basically involves huge data transer from main process to subprocess. Subprocess carries out processing on each set of data, read through the mailbox.

This works fine for small data file transfer. While transfering large file data, sometimes, main process hangs and the process state shows as RWMBX.

I increased the DEFMBXBUFQUO ( sygen parameter ) value, as well as, the bufquo argument (in sys$crembx call) to sufficiently large value (ie, 8192 from 1024 ). This works out fine for only few large files and not for all. Increasing the bufquo value to very huge value, (say, 20480 ) is causing the subprocess to get killed.

Can anyone help me by suggesting the suitable solution to solve my problem. Also, inform me about different conditions, on which the process goes to RWMBX state.

I am having Alpha-Axp system, running Open VMS 6.1.

Thanks in Advance,

The Answer is:

The root cause of the problem you are running into is that mailboxes are a good inter-process communication mechanism, but are not suitable for buffering large amounts of data. Unlike a Unix pipe, in which data in the pipe is stored on a file in the file system, an OpenVMS mailbox stores all buffered data in real memory. The mailbox buffer quota that you specified with either DEFMBXBUFQUO or the bufquo argument sets the limit on the amount of data you can buffer in the mailbox.

When you create the mailbox, the buffer quota you specify is deducted from your job's non-paged dynamic memory (pool) quota. (This is the quota AUTHORIZE shows as BYTLM.) This quota governs pool usage by the main process and all subprocesses in your job; most system services require some amount of pool quota. So if you give too much of your job's pool quota to the mailbox, your job won't have enough quota left to run.

The reason the main process is going into RWMBX state is that it is getting ahead of the subprocess's ability to read and process the messages from the mailbox. When the mailbox is full, further attempts to write the mailbox will put the process into RWMBX state until the subprocess reads from the mailbox.

Depending on the requirements of your application, there a couple of choices you have to deal with this problem:

  1. Do nothing. If there is nothing else for the main program to do while it is piping the data to the subprocess, letting it go into RWMBX is harmless. The system is providing automatic flow control for you on the mailbox.
  2. Use synchronous I/O. Write each message with IO$_WRITEVBLK *without* the IO$M_NOW modifier. Wait for the write I/O to complete, either by using the $QIOW service for a fully synchronous write, or by using $QIO to initiate the write and later waiting on its completion with $SYNCH. Without the IO$M_NOW modifier, each write will complete only when the subprocess has read that message from the mailbox. By using $QIO and $SYNCH, you can keep a limited number of messages in the mailbox at all times without stalling the process in RWMBX.
  3. Buffer the messages in the subprocess. In the subprocess, use an asynchronous $QIO with a completion AST to read the mailbox. In the AST routine, put the buffer you just read onto a work queue. Then allocate another buffer and issue a new read $QIO before returning to your data processing. This way the subprocess will drain the mailbox as fast as it can issue and complete read $QIOs, and process the data in the background.