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
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
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
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.)