|
HP OpenVMS Systemsask the wizard |
|
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 SYS$CREMBX. 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 mailbox). 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 $CREMBX. 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 Jean 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.)
|