Operating System - OpenVMS
1753765 Members
5626 Online
108799 Solutions
New Discussion юеВ

Problem with logicals and tables

 
SOLVED
Go to solution
Not applicable

Problem with logicals and tables

Hi,

Can anyone help me to know how can I get the value of table LNM$TEMPORARY_MAILBOX, and how can I change its value.

Regards,
ajaydec
11 REPLIES 11
Hein van den Heuvel
Honored Contributor

Re: Problem with logicals and tables


LNM$TEMPORARY_MAILBOX is defined / descripted in the OpenVMS Systems Syrvice Ref Manual under $CREMBX (converniently next to $CRELNT and $CRELNM)

It should (ultimately) point to a loginal name table like LNM$GROUP

It does not have to be defined, in which which LNM$JOB is used.

You just use SHOW LOGICAL or F$TRNLNM to get the value and DEFINE or ASSIGN to set a value.

Why? Do you get an error? What error/behaviour?
Usinf DCL or a programming language?

Hein.
Hein van den Heuvel
Honored Contributor

Re: Problem with logicals and tables

Also... just google : LNM$TEMPORARY_MAILBOX [lucky]

There will eb a ton of useful references, the first one the relevant manual page.

Hein
Not applicable

Re: Problem with logicals and tables

Hi Hein,

I am trying to solve the problem of the following link:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1173679

I think, it can be due to some syncronization problem with LNM$TEMPORARY_MAILBOX table.

"It should (ultimately) point to a loginal name table like LNM$GROUP"
I want to know how can I point it to LNM$GROUP or LNM$SYSTEM using DCL command and I also want to know where it is pointing right now. Can you help me in knowing this.

Regards,
ajaydec
Kris Clippeleyr
Honored Contributor
Solution

Re: Problem with logicals and tables

ajaydec,

LNM$TEMPORARY_MAILBOX is defined in LNM$SYSTEM_DIRECTORY.
You can verify this by:
SHOW LOGICAL/TABLE=LNM$SYSTEM_DIRECTORY LNM$TEMPORARY_MAILBOX
This gives (at least on my system):
"LNM$TEMPORARY_MAILBOX" = "LNM$JOB" (LNM$SYSTEM_DIRECTORY)

Be however very careful in manipulating this logical. We have over here some legacy software that redefines it to LNM$GROUP, and because of that ran into trouble with Apache.

Regards,
Kris (aka Qkcl)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Robert Gezelter
Honored Contributor

Re: Problem with logicals and tables

ajaydec,

A small note of warning, as I write this, I am getting ready for a conference call and thus do not have the time to verify this.

From the OpenVMS System Services Reference Manual, $CREMBX section:

"For permanent mailboxes, the $CREMBX service enters the specified logical name, if any, in the LNM$PERMANENT_MAILBOX logical name table and, for temporary mailboxes, into the LNM$TEMPORARY_MAILBOX logical name table."

With all due respect to the OpenVMS Documentation group, perhaps a better phrasing would be "... the logical name table specified by LNM$TEMPORARY_MAILBOX.

As I said earlier, I do not have the time to verify with a code sample, but I would expect that the search list for logical names is used, since most users do not have access to the system logical name table.

I would recommend creating a simple test program and run it after having done:

$ ASSIGN/USER LNM$PROCESS LNM$TEMPORARY_MAILBOX

If my reading of the documentation is correct, then the logical name for the mailbox should appear in the Process logical name table.

Note that if multiple subprocesses within a single job were to use the default behavior, and use a single logical name for the newly created mailboxes, the timing behavior could become highly unpredictable.

For examples of some diagrams and discussions of how to use and exploit hierarchical defaulting with logical names (and some diagrams of how this can be used), please see my OpenVMS Technical Journal paper: " Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters", abstract and reprint available at: http://www.rlgsc.com/publications/vmstechjournal/inheritance.html

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com
Jan van den Ende
Honored Contributor

Re: Problem with logicals and tables

ajaydec,

temporary mailboxes are a means to communicate between processes.
However, the communicating processes must agree about WHICH mailbox. That is made known by defining the name of that mailbox in LNM$TEMPORARY_MAILBOX.
(which itself is a name pointing to a logical name table).
For the cooperating processes to be able to translate the mailbox name into the correct MBA device, they must all agree upon WHICH table it is defined in, AND, must have it in their LNM loopup list. By default, LNM$TEMPORARY_MAILBOX is the LNM$JOB for the process. That means, a process and all its sub-processes, and noone else, can communicate via temporary mailboxes of that process tree. Normally the processes have read and write access to that table, so no extra measures needed.
_IF_ processes are to communicate with other processes, _THEN_ LNM$TEMPORARY_MAILBOX must be a table shared between them, and the process creating the mailbox must have WRITE access to that table.
Most common is the use of LNM$GROUP:
$ DEFINE LNM$TEMPORARY_MAILBOX LNM$GOUP/TABLE=LNM$PROCESS_DIRECTORY
Remember, the process creating the mailbox needs GRPNAM privilege, OR, the table needs an ACL allowing write access.

If users of different UIC groups are to share LNM$TEMPORARY_MAILBOX, then you should create a (application-) LNM table, regulate access via an identifier based ACL, and UAF GRANT that identifier to the relevant users.
(you, and several layered products, mention using LNM$SYSTEM as LNM$TEMPORARY_MAILBOX, but I have to MOST STRONGLY discourage that use (abuse!).

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
John Gillings
Honored Contributor

Re: Problem with logicals and tables

I've had a bit of trouble following all the text here, so I'll try to simplify it...

The logical name associated with a mailbox needs to be placed somewhere. OpenVMS uses logical names LNM$TEMPORARY_MAILBOX and LNM$PERMANENT_MAILBOX to point to the logical name tables in which mailbox logical names are defined.

By default, the definitions are in LNM$SYSTEM_DIRECTORY:


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

(LNM$SYSTEM_DIRECTORY)

"LNM$PERMANENT_MAILBOX" = "LNM$SYSTEM"
"LNM$TEMPORARY_MAILBOX" = "LNM$JOB"

You can override the system defaults by defining the logical name in LNM$PROCESS_DIRECTORY. The most common redefinition I've seen is to place the logical names in LNM$GROUP. That conforms with the VMS V3 behaviour (meaning there is still code that hasn't been fixed for the changes made in V4, more than 20 years ago? ;-) On the other hand, using LNM$GROUP makes it easier to share mailboxes between detached processes in the same group, but as Jan mentioned, you need at least GRPNAM privilege.

To see all definitions use:

$ show log/table=lnm$*directory lnm$*mailbox

(LNM$PROCESS_DIRECTORY)

"LNM$TEMPORARY_MAILBOX" = "LNM$GROUP"

(LNM$SYSTEM_DIRECTORY)

"LNM$PERMANENT_MAILBOX" = "LNM$SYSTEM"
"LNM$TEMPORARY_MAILBOX" = "LNM$JOB"
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Problem with logicals and tables

aside... when dealing with "global" mailboxes, I think I read a comment by Hoff recently warning against using permanent mailboxes because of the cleanup issue.

Here's a way around that. You'll need PRMMBX and SYSNAM privilege. Sample MACRO32 code:

; Create a permanent mailbox, then immediately delete it.
; This means it will be deleted when the last channel is closed,
; BUT the logical name will be created in the system table.

$crembx_s prmflg=#1 chan=mbx_chn,-
maxmsg=#mbxmsgsiz, bufquo=#mbxbufquo, -
lognam=mbxlognam
blbc r0,exit
$delmbx_s chan=mbx_chn


This gives a globally visible mailbox that cleans itself up, without fiddling around with LNM$TEMPORARY_MAILBOX.
A crucible of informative mistakes
Robert Gezelter
Honored Contributor

Re: Problem with logicals and tables

ajaydec,

There is an errata in my posting from earlier today. John's point is well taken, and my example command omitted the /TABLE=LNM$PROCESS_DIRECTORY.

- Bob Gezelter, http://www.rlgsc.com