Consistency of iterative logical name translation in OpenVMS?

[Mark_Corcoran]

I was trying to use logical names to work around a problem a problem until I could get time to fix it properly in the code, only to find that the workaround wouldn't work.

Application A will communicate with application B using mailbox #1 when an order is placed into any logical location other than X.

When orders are ready to be moved to location X, the order is placed onto an application "queue" (not a queue in the sense of being managed by the OpenVMS queue manager, nor a queue in the sense of using the $INSQTI/$INSQHI/$REMQHI/$REMQTI RTL LIB$ routines).

The placement of the order into location X causes application A to communicate with application B using mailbox #2 rather than mailbox #1.

When the application "queue" is empty, an order that moves into location X-1 (triggering a message from application A to application B via mailbox #1) immediately becomes eligible for moving to location X, triggering a message from application A to application B via mailbox #2.

The problem with this is that the database record for the order in application B is still being processed by the message that was sent to mailbox #1, and can't be updated, resulting in application B not being told that the order is now in location X (and not then triggering a number of other messages to interested parties).

I was looking at changing the code so that mailbox #1 is used under both conditions - I may need to check the size of the mailbox that is created, to allow for additional messages to be stored in the mailbox until application B reads them, but this would enforce a strict FIFO order, and avoid application B trying to process messages from two different mailboxes in what is effectively two different threads - i.e. no more lock contention.

The turnaround time for me finding a bug, fixing it, getting it tested and producing the install/test/regress documentation, and getting a change request raised & approved means that code changes are infrequently implemented.

I was therefore considering trying to implement a workaround in configuration instead...

Application B creates mailboxes #1 and #2, and specifies values for the lognam parameter on the $CREMBX call, where the name to be used is specified in an application configuration file.

I thought that if I defined the logical name for mailbox #2 with an equivalence name that was the logical name for mailbox #1, then $CREMBX would find that it actually translated to mailbox #1, and would not create another mailbox device, but that's not what happens.

The System Services Reference Manual says this:
If a logical name is specified and a mailbox with the specified name already exists, the $CREMBX service assigns a channel to the existing mailbox.

It says this about the lognam parameter:
The equivalence name for the mailbox is MBAn. The equivalence name is marked with the terminal attribute. Processes can use the logical name to assign other I/O channels to the mailbox.

If I define the logical name for mailbox #2, $CREMBX creates a new mailbox, and redefines the logical name  with the name of the new mailbox device it creates as the new equivalence name.

It strikes me that $CREMBX may well check to see if "the specified name already exists", but it is either:

a) checking to see whether or not the terminal attribute (i.e. LNM$M_TERMINAL, as would be set when you use DEFINE /TRANSLATION_ATTRIBUTES=TERMINAL) is set, and only if it is set, will it even look at the equivalence name to see if it is in the form of a mailbox device name
b) not checking to see if the terminal attribute is set, but simply checking to see if the equivalence name is in the form of a mailbox device name, and if not, then it does not perform iterative translation.

What would your expectation be of the behaviour for $CREMBX under these circumstances?  (even if this behaviour were considered by most folks to be "wrong", I can't see the behaviour being changed, because it wouldn't then be backwardly compatible).

Are there other places (other system services, RTL routines, DCL verbs) where iterative translation is not performed (or is this a longer list than places where it is performed)?

Mark

[tsgdavid2]

Just a guess, but...

$CREMBX creates the logical names and may assume that it knows how this is done and that it is a certain type of logical name that translates directly to an MBAn device name.  The code may simply translate the logical and determine if the translation is a valid MBAn device that exists.

I would try this as a work around:

1) After application B starts, DEASSIGN the logical name for mailbox #2

2) Define a new logical name for mailbox #2 that is identical to the logical name for mailbox #1

[Mark_Corcoran]

Thanks for your reply, David.

It reminded me that when I was going through the change documentation last week for the code change, I found that I have found and documented the cause of the apparent lack of iterative logical name translation since my original post (which I've just edited to correct a couple of typos and to make queue references slightly simpler).

Unfortunately, I can't for the life of me recall now how it was that I determined this, but it was probably pulled together from a number of places.

My documented explanation (and I'm - for the moment, anyway - sticking to it) is as follows:

"This is because when the underlying code of the $CREMBX system service checks to see if there is another mailbox with that logical name in existence, it scans the entries for mailbox devices in the OpenVMS I/O device database (equivalent to the command MC SYSGEN SHOW /DEVICE=MBDRIVER).

For each mailbox device, it looks at the UCB$L_LOGADDR element of the device's Unit Control Block (UCB) structure to determine if the mailbox was created with a logical name, and if so, whether or not the Logical Name Block (LNMB) pointed to by the UCB$L_LOGADDR value, matches the value passed as the lognam parameter to the $CREMBX system service.

In SDA, this would be equivalent to doing:
SDA> READ SYS$SYSTEM:SYSDEF.STB
SDA> SHOW DEVICE MBAnnnn:
SDA> FORMAT ucb_address /TYPE=UCB
SDA> !ucb­_address above is given in the top right hand side of SHOW DEVICE output
SDA> FORMAT lnmb_address /TYPE=LNMB
SDA> !lnmb_address above is given to the right of the UCB$L_LOGADR in the previous command

It would then compare the LNMB$T_NAME value against the value passed as the lognam parameter.

Therefore, if there is no mailbox device in the OpenVMS I/O database with the specified logical name when the device was created with the $CREMBX system service, then $CREMBX will end up creating a new mailbox device, and defining the specified logical name (possibly redefining any existing logical name, depending on the qualifiers you used to create it (specifically if you used /GROUP /USER /TRANSLATION_ATTRIBUTES=TERMINAL))."

Mark

[Mark_Corcoran]

>Unfortunately, I can't for the life of me recall now how it was that I determined this, but it was probably pulled together from a number of places.

I subsequently came across the information of this when looking at comments I had placed in some code - I got the information from the VMS Internals and Data Structures v5.2 book (EY-C171E-DP, 1991) - mailboxes are covered under chapter 23 starting on page 655.

The information in my previous post is a paraphrased version of information that appears in the chapter.

On having looked at & thought about my question further, I'm not sure why I thought there should be iterative translation of the logical name - F$TRNLNM and SYS$TRNLNM don't do it, only SHOW LOGICAL "does" (and mentions this in HELP SHOW LOGICAL):

$ DEFINE /PROCESS A B
$ DEFINE /PROCESS B C
$ DEFINE /PROCESS C D
$ SHOW LOG A
   "A" = "B" (LNM$PROCESS_TABLE)
1  "B" = "C" (LNM$PROCESS_TABLE)
2  "C" = "D" (LNM$PROCESS_TABLE)

The System Services reference manual indicates for $TRNLNM that if the table name parameter is specified and is not the name of a logical name table, it is assumed to be a logical name and translated iteratively until a logical name table is found or the number of translations have reached the maximum iterations defined by the system (I'm not sure how/where this is defined, or if it is hard-coded;  a quick check of SYSGEN parameters doesn't yield any likely candidates), but there is no such iterative translation performed for the logical name itself.

Mark