Problem with group mailboxes on OpenVMS 8.4

[C. Mom]

Hi,

At the moment I am porting an Alpha application from OpenVMS V7.1-2 to OpenVMS 8.4 for Integrity Servers. We use inter-process communication with mailboxes and of cource I have set the next logical:

DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$TEMPORARY_MAILBOX LNM$GROUP

The application consists of one main process with a bunch of subprocesses. When the main process has started, I can see the logical name pointing to its mailbox in the group table, as expected. When I start the subprocesses the logical names pointing to their mailboxes are not located in the group logical name table, but in the job logical name table. So no mailbox communication will be possible with processes outside the job tree. The main process is running in a batch job.

Does anybody recognize this? Please let me know if you have a solution.

Regards,
Cor Mom

I do have some problems with mailb

[abrsvc]

More information required here. For example, how are the subprocesses created? Are you using $CREPRC or LIB$SPAWN? What language are you using for the application?

Can you create a small reproducer and post it here? Having something concrete to work with makes providing a solution much easier.

Dan

[Shriniketan Bhagwat]

Hi,

Do you have the GRPNAM privilege? To place a logical name for a mailbox in the group logical name table requires GRPNAM privilege.

Regards,
Ketan

[C. Mom]

Processes are created using $CREPRC. Code is written in HP C 7.1. This application has been running for years on VAX and Alpha. No new code here.

[C. Mom]

Yes, all required privileges are there

[abrsvc]

Do you have or can you create a small reproducer? The behavior should not have changed. I have used similar techniques without problems on both V71-2 and V8.4.

Dan

[Hoff]

From your original problem statement, you appear to have all the information you need. Main is working. The subprocesses either don't have GRPNAM or GRPPRV or SYSNAM or SYSPRV, or the subprocesses don't have the translation of the logical name needed to redirect the creation of that pesky logical name into the group logical name table. That's a pretty narrow target area for a multi-process application, too.

Your error appears to be a simple one: you believe the code works, and that "something else" other than the code is at fault. Classic debugging mistake, that.

Do not ever assume that "working code" is "correct code."

Do not fear logging.

Do not fear the debugger.

An application bug is always assumed to be the programmer's bug, until the DRI (designated responsible individual) either does prove that the bug is within the code and then fixes it, or until the DRI proves the bug is somebody else's, and provides the new DRI with information and preferably a reproducer.

As for this case...

Check the process quotas on the created processes, check the privileges within the created processes, check the translation of the associated logical names within in the context of the processes, check the run-time logs that the processes are (or should be) creating for themselves and (if the processes are not creating logs either directly under program control or somewhat less desirably as an artifact of the output for the process) add logging to the processes.

The next round of checks are for programming bugs that seemingly inevitably lurk in code that is referred to as "working code" in a forum posting.

These can include failures to check status and IOSB consistently, failure to declare an IOSB in non-volatile storage, failure to specify an IOSB whereever it is an available or optional argument, failure to handle shared memory correctly and particularly within multiprocessors, colliding access to IOSBs or event flags across asynchronous code, failure to correctly allocate event flags for use, and there exist a wide variety of other potential bugs in this particular zoo.

Variations that can arise when porting code can involve not propagating ACLs or protection masks from previous system environments, file ownership and file protection differences, differences in privileges in the default context, and subsystem identifiers.

The core of the debugging effort for these cases typically involves the aforementioned application-integrated logging, and building with and using the OpenVMS debugger, and there are various (easy) ways to implement that. What follows is an example of how a detached process can use a DECterm X Window display (on the local box or a remote X Window Server system) to display debugging activity:

http://labs.hoffmanlabs.com/node/803

Application-implemented debug logging and the OpenVMS Debugger are going to be two of the most useful approaches here.

[Hein van den Heuvel · Accepted solution]

You checked the privs, and surely the group UIC got the created processes.

>> I can see the logical name pointing to its mailbox in the group table

How? Using the LNM extension to SDA?

>> DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$TEMPORARY_MAILBOX LNM$GROUP

How is that made effective in the children?
Are they started with loginout and a command file?

The old system would not have had that definition in LNM$SYSTEM did it?

And how about LIN$FILE_DEV.
Is that defined correctly ( same as on the old system ). From the sys serv ref man:

"If you redefine either LNM$TEMPORARY_MAILBOX or LNM$PERMANENT_MAILBOX, be sure that the name of the new table appears in the logical name table LNM$FILE_DEV. "

fwiw,
Hein

[abrsvc]

With the definition in the process table, you need to be sure that the subprocess has the copied process table. This is the default when using lib$spawn.

Realizwe that the redirection that you are defining is within the process table NOT the group table.

Dan

[C. Mom]

Hein:

The old system would not have had that definition in LNM$SYSTEM did it?

Look what I found on the old system:

$ sh log/table=lnm$process_directory *mailbox*

(LNM$PROCESS_DIRECTORY)

"LNM$TEMPORARY_MAILBOX" = "LNM$GROUP"

$ sh log/table=lnm$system_directory *mailbox*

(LNM$SYSTEM_DIRECTORY)

"LNM$PERMANENT_MAILBOX" = "LNM$SYSTEM"
"LNM$TEMPORARY_MAILBOX" [super] = "LNM$GROUP"
"LNM$TEMPORARY_MAILBOX" [kernel] = "LNM$JOB"

That means I was searching for something that wasn't there. Of cource those subprocesses are using the system logical.

Thanks for your eye opener.

With kind regards,
Cor Mom

[John Gillings]

Cor,

You need to decide if you want LNM$TEMPORARY_MAILBOX => LNM$GROUP system wide or just for a select group of processes.

For system wide, define it in LNM$SYSTEM_DIRECTORY in EXEC mode. You don't need to do anything in the processes themselves, BUT remember that other software may assume the VMS default of LNM$JOB (even implicitly).

For per-process, you need to execute:

$ DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$TEMPORARY_MAILBOX LNM$GROUP

in every process that needs to create a mailbox which other processes need to be able to see. They will need GRPNAM privilege.

Since the VMS default is LNM$JOB, my advice would be to NOT make it system wide.

Also note that if you go system wide, all processes which ever create a temporary mailbox will need GRPNAM privilege, your group tables may crowded, and you may need to manage duplicate names.


Depending on how much control you have over your application, you may be able to change the model. You "main" process can create the mailbox, then make a copy of its logical name in the group table:

$ CREATE/MAILBOX GRPMAILBOX
! logical name is now in LNM$JOB

$ DEFINE/GROUP GRPMAILBOX 'F$TRNLNM("GRPMAILBOX")
! now there's another copy in the group table

You'll have to remember to remove the group table copy when the mailbox is deleted.

So your subprocesses don't need GRPNAM, they can create their mailboxes locally. When they contact the main process through its group mailbox, the first message can identify their return mailbox:

$ CREATE/MAILBOX MYMAILBOX
$ OPEN/WRITE GRP GRPMAILBOX
$ WRITE GRP 'F$TRNLNM("MYMAILBOX")

the main process can keep track of the return mailbox name. The code is probably already there, just substitute the actual mailbox name for the logical name.