  Debugging Mailbox Communications? 
 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.
 
 Answer written or last revised on  19-MAY-2003 
