|
HP OpenVMS Systemsask the wizard |
|
The Question is:
Hi,
We have a system running under VMS wich uses the
mailboxes to exchange data between processes.
There is only one read process which is a detached process which reads from the
mailbox and one interactive write process .But the write process can be
acessed by many users on the network simultaneously.So the mailbox can have
more than one processes wri
ting to it.However the read process would be only one which keeps running
throughout the day.The programming language is COBOL and we have a common
routine called by the read process and the write process.
recently we have started facing a problem , that In case the read process(being
a detached process) stops abruptly and then some user starts the write process
,so that the write process creates a mail box first, write failure occurs on
the mailbox with an
I/O status return
SS$_MBTOOSML.Now if the read process is started late to read the messages from
the mailbox , it does not do so.Now with the read process running , new
messages are still not being read/written to the mail box.Same SS$_MBTOOSML
occurs everytime.
However if the read process was the first to create the mail box and then write
process are assigned the channels later on, if the read process now stops.It
does not create any problem and the error SS$_MBTOOSML does not occur.
To get a normal situation we have to stop the read process and logout all users
so that no write process is running as a result of which the temperory mailbox
is deleted and then we have to restart the read process first and then the
write processes are s
tarted.
I have tried searching most of documentation to find out what actually happens
with the mailbox if SS$_MBTOOSML is coming , but i did not get much.
We are using COBOL as the programming language.
The bit of code which is used to create and assign the maiil boxes is
CALL "SYS$CREMBX" USING
BY VALUE 0
BY REFERENCE SY-CHANNEL
BY VALUE MBXCB-MESSAGE-LENGTH
BY VALUE MBXCB-BUFFER-SIZE
OMITTED
OMITTED
BY REFERENCE WS-FILE-NAME-DESCRIPTOR
GIVING SY-STATUS
To write to the mailbox
ADD WK-IO$_WRITEVBLK WK-IO$M_NOW GIVING IO-FUNCTION
CALL "SYS$QIOW" USING
BY VALUE 0
BY VALUE MAILBOX-CHANNEL(MBX-IND)
BY VALUE IO-FUNCTION
BY REFERENCE SY-IOSB
BY VALUE 0 0
BY REFERENCE MBX-MESSAGE
BY VALUE MBXCB-MESSAGE-LENGTH
0 0 0 0
GIVING SY-STATUS.
To read from the mailbox
MOVE WK-IO$_READVBLK TO IO-FUNCTION
CALL "SYS$QIOW" USING
BY VALUE 0
BY VALUE MAILBOX-CHANNEL(MBX-IND)
BY VALUE IO-FUNCTION
BY REFERENCE SY-IOSB
BY VALUE 0 0
BY REFERENCE MBX-MESSAGE
BY VALUE MBXCB-MESSAGE-LENGTH
0 0 0 0
GIVING SY-STATUS.
Please suggest what should be done so that the read process atleast reads again
when it is restarted without asking all the users to log off and stop all the
write processes.
The Answer is : Your application is likely using RMS and the File Access Listener (FAL) and DECnet to write into the mailboxes remotely, as there is no such thing as a network mailbox. (What is confusingly refered to as a network mailbox on OpenVMS is a local mailbox used to communicate with network software.) Mailboxes are only accessable directly -- without using RMS and FAL or other similar networking connection -- on the local node or (for a cluster-accessable mailbox) within the local OpenVMS Cluster. The OpenVMS Wizard generally recommends direct use of DECnet or IP connections when networking is required, as using RMS and FAL adds another layer of complexity -- and the record semantics and I/O assumptions may not entirely agree or entirely match with local application requirements. With a native, direct network connection, you can acquire and utilize the features required for the application. Your COBOL listener contains one or more latent errors, and these should be resolved BEFORE continuing forward on your current path. With the listener down, the writers will eventually fail as the amount of buffer space is finite. If resource-waiting is enabled, the local writers should eventually stall, but back-pressure from these stalls can and eventually will stall the entire application environment. (Much as a clogged drain continues to back up and to flood when more water is added.) Please check the code that creates and connects to the mailbox in both the and the writer. In particular, please use the OpenVMS Debugger to confirm the actual run-time values of the variables MBXCB-MESSAGE-LENGTH and MBXCB-BUFFER-SIZE. The OpenVMS Wizard also views any application that utilizes the defaulting for any quota-related arguments -- on $crembx, on $creprc, or other similar services -- as containing one or more latent bugs, as the defaults are derived from system parameters and can change and can introduce errors into the run-time. Based solely on your message, it appears that the MAXMSG and/or BUFQUO arguments used when the writer process creates the mailbox are inadequate, whereas the values from the reader are adequate. (This also tends to point to the existence of multiple mailbox creation routines when common code would be more appropriate.) It is also possible that the reader's unintended downtime has allowed the readers to fill the mailbox. For application debugging information, please see topics (7552) and (1661). For debugging detached processes, please see topics including (1017), (1314), (3031), and (4129). For information on creating and using shareable images and common code, please see the Shareable Image Cookbook link available at the main webpage of the Ask The Wizard website.
|