HP OpenVMS Systems

ask the wizard
Content starts here

Programming with Mailboxes? (take III)

» close window

The Question is:

Subject : VMS Process to VMS Process communication via mailbox between an
 OpenVms Alpha and an OpenVms Vax using Decnet only not TCPIP .
Using SYS$CREMBX, how to connect to a mailbox on another node (OpenVMS)
(using Fortran preferrably)
or using regular OPEN Fortran statement in order to send mail box messages
that are quite long ?
The remote mailbox has been created on remote node (NODEB) also using
It has a logical name in system table, let's say NODEB_MBX and has been
assigned the physical pseudo device MBAxxxx:
It's size is let's say 3600 bytes per message and it is able to receive 5
 messages (that
is 3600 * 5 bytes totally).
NODEA wants to open that remote mailbox with SYS$CREMBX
A proxy on NODEB allows NODEA user (the one that wants to open remotely the
mail box) to use NODEB::
to reach NODEB defaults account (the one that has first created the
Using SYS$CREMBX ( CHANEL , NODEB::NODEB_MBX ) , on NODEA I keep getting
"Invalid device" as if NODEA was not able to decode the logical NODEB_MBX
into MBAxxxx:
The Fortran Open with mail box name NODEB::"NODEB_MBX" ( mail box logical in
between 2 double quotes) works.
I can send short messages (about 80 bytes) but I keep getting mail box is
too small when trying to send 3600 bytes.
The send message is done with regular QIO (not Fortran WRITE) on chanel (or
fortran opened unit) assigned to mail box by CREMBX or OPEN.
I played around with the OPEN statement (different options such as RECL =
different values, ACCESS, CARRIAGECONTROL,
RECORDTYPE, FORMATED/UNFORMATED, etc ...). I keep getting the mail box too
small problem or I get an invalid record length.
For info, I did try also the SYS$ASSIGN , but this gives same error as
Also I'm not interested in the Non-transparent methode explained in the
DECNET manuals . I tried this and that's too heavy for my purpose.
Help greatly appreciated (code example even more appreciated)
Thanks in advance

The Answer is :

  The OpenVMS Wizard would encourage the use of DECnet, IP, or the
  IntraCluster Communications (ICC) system service calls.  For this
  application, the OpenVMS Wizard would not use mailboxes.
  Remote mailbox access is somewhat of a misnomer, as remote access
  actually involves opening the remote mailbox using the file system
  and the File Access Listener protocol running over DECnet.  (With
  the added layers, care must be taken with RMS not to add record
  semantics onto the mailbox contents.)  Without using FAL or other
  network protocol, standard mailbox devices are not accessable
  from another node, whether remotely or within the same cluster.
  When you issue the $crembx, you will want to specify the message
  size and message quota arguments, and you must specify enough extra
  room for the mailbox data structures in addition to the data records
  you plan to write into the mailbox.  It is likely that these values
  were either defaulted in your tests, or were inadequately specified.
  Further, even if the system parameters that establish the defaults
  for these mailbox values are set appropriately for your specific
  requirements, the OpenVMS Wizard still strongly encourages the
  application requirements always be explicitly specified on the
  $crembx system service call.  For the upper limit, please see
  topic (6905).
  And again, the OpenVMS Wizard would likely use a DECnet server and
  DECnet connections, or an IP server process and clients, or ICC.
  Not mailboxes.  (For examples of DCL-based task-to-task network
  communications, please see topics including (159).  Also please
  see topics (5045), (7359) and (8746) for additional discussions
  of networks, networking, and mailboxes.)

answer written or last revised on ( 18-JUL-2003 )

» close window