HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Problem detected on temporary mailbox

 
SOLVED
Go to solution
Daniel Fernandez Illan
Trusted Contributor

Problem detected on temporary mailbox

Hello all,

We are migrating the application from an alpha machine (OpenVMS V7.3-2) to an Itanium machine (OpenVMS V8.4) and we have detected a mistake when intend to create a temporary mailbox to enable communication between processes in different jobs and appears this error:

%SYSTEM-F-NOLOGTAB, no logical name table name match

 

When we use this command:

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

create/mail mailtest

on produces the NOLOGTAB error message

But if we use the command:

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

The mailbox creation is successfully.

The command distinguishes between upper and lower cases.

 

Is this produced by an error on OpenVMS version distribution?

 

Saludos.

8 REPLIES
Richard Brodie_1
Honored Contributor

Re: Problem detected on temporary mailbox

What does SHOW PROCESS/PARSE say?

 

I suppose the command not working is unexpected, and arguably a bug. Whether logical names are case sensitive or not is up to the individual application.

Daniel Fernandez Illan
Trusted Contributor

Re: Problem detected on temporary mailbox

In effect, changing the value of parse to traditional the commando works properly.

But the lis bellow shows the commands and responses associated:

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

sho log /TABLE=LNM$PROCESS_DIRECTORY LNM$TEMPORARY_MAILBOX

LNM$TEMPORARY_MAILBOX" = "LNM$GROUP" (LNM$PROCESS_DIRECTORY)
1  "LNM$GROUP" = "LNM$GROUP_000120" (LNM$PROCESS_DIRECTORY)

In all cases shows upercase definitions (expected functionallity)

By other hand (using parse=extended)

define/table=exptbl testlog sys$login

dir testlog:*.*

Directory EXPUSR:[EXPAPLIC]

LOGIN.COM;4         LOGIN.COM;3         LOGIN.COM;2         LOGIN.COM;1

define/table=exptbl testlog SYS$login

dir testlog:*.*

Directory EXPUSR:[EXPAPLIC]

LOGIN.COM;4         LOGIN.COM;3         LOGIN.COM;2         LOGIN.COM;1

 

In my opinion, it is a bug in $CREMBX system service.

 

Saludos.

 

H.Becker
Honored Contributor

Re: Problem detected on temporary mailbox

In my opinion there is an incomplete, inconsistent or incorrect documentation of what the parameters for DEFINE are, that is how they are implemented. $CREMBX seems to work as expected.

 

VMS was not designed for case sensitivity, so unexpected behavior with parse=extended (and/or case=sensitive) is expected.

 

The parameter equivalence-name is defined as a file spec:

 

$ search SYS$COMMON:[SYSUPD]DCLINT.CLD "cliroutine define"/wind=(0,3)
        cliroutine define
        prefix cli$k_defi_
        parameter p1,prompt="Log name",value(required,type=$outlog)
        parameter p2,prompt="Equ name",value(required,type=$old_file,list)
$
So it is subject to upcasing, depending on the parse style.
In your case, the equivalence name  LNM$TEMPORARY_MAILBOX itself is looked up in a logical name table. The matching is (and as far as I know always was) done case sensitive. So LNM$group is not found while LNM$GROUP is.
At least the documentation in "help define" does not explain the matching and/or the dependence on the parse style.
John Gillings
Honored Contributor

Re: Problem detected on temporary mailbox

Saludos,

 

  I don't think this is a bug at all. You asked for case sensitivity, you got it.

 

   SET PROCESS/PARSE=EXTENDED refers to parsing of command lines. When set, case is preserved for (some) unquoted command line parameters, in this case the equivalence name of your logical name.

 

  There is a different flag to turn on case sensitivity of file name lookups, SET PROCESS/CASE_LOOKUP=SENSITIVE. Your problem is that the $CREMBX service doesn't uppercase the equivalence name of LNM$TEMPORARY_MAILBOX, performs a case sensitive translation to find the table, and fails because it doesn't find a matching table. All correct behaviour.

 

  Your example using SYS$LOGIN, it's the RMS $PARSE service doing the translation, which does a case blind logical name translation, either because of the process setting of CASE_LOOKUP, or because the device is ODS2. Example:

 

$ create SYS$SYSDEVICE:[TCPIP$FTP]testfile.txt
^Z
$ dir/size SYS$SYSDEVICE:[TCPIP$FTP]

Directory SYS$SYSDEVICE:[TCPIP$FTP]

LOGIN.COM;1                1
TCPIP$FTP_RUN.LOG;24
                         102
TCPIP$FTP_RUN.LOG;23
                           0
TCPIP$FTP_RUN.LOG;22
                           2
TCPIP$FTP_RUN.LOG;21
                           0
TCPIP$FTP_RUN.LOG;20
                           1
testfile.txt;1             0

Total of 7 files, 106 blocks.

$ define testlog sys$sysdevice:[tcpip$ftp]
$ show log testlog
"TESTLOG" = "sys$sysdevice:[tcpip$ftp]" (LNM$PROCESS_TABLE)

$ dir testlog
%DIRECT-E-OPENIN, error opening SYS$SYSDEVICE:[tcpip$ftp]*.*;* as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

 This shows that RMS does case blind logical name translations, but case sensitive file lookup on ODS5 devices when CASE_LOOKUP=SENSITIVE

 

  Bottom line here is if you're going to have extended parsing enabled, you need to expect case sensitive behaviour, and therefore make sure you specify the correct case at all times for all parameters.

A crucible of informative mistakes
Hoff
Honored Contributor

Re: Problem detected on temporary mailbox

If OP asked for case preservation, and not for case sensitivity, then this is a bug.  Albeit with an easy work-around.

 

Had this been an RMS parsing operation, the parsing and the filename matching would have matched irrespective of casing when case-preserving, and the match failed when case-sensitive.  These character-matching cases were found all over the place in applications, when RMS switched.

 

If you want to imagine an even worse case for finding these, consider what would happen with the addition of native UTF-8 filename support and not the current "storage-only" UTF-8 implementation.

 

As for what HP classifies this case as, OP will have to ask them.

 

Daniel Fernandez Illan
Trusted Contributor

Re: Problem detected on temporary mailbox

Hello

I have found a difference in the documentation (OpenVMS DCL dictionary) that it could explain the no expected operation of the command DEFINE

 

Version 7.3.2

 

DEFINE

 

Associates an equivalence name with a logical name.

Format

DEFINE logical-name equivalence-name[,...]

 


Parameters logical-name

Specifies the logical name string, which is a character string containing from 1 to 255 characters. The following rules apply:

  • If the logical name is to be entered into the process or system directory logical name tables (LNM$PROCESS_DIRECTORY, LNM$SYSTEM_DIRECTORY), then the name can only have from 1 to 31 alphanumeric characters, including the dollar sign ($) and underscore (_).

And Version 8.4

 

DEFINE

 

Associates an equivalence name with a logical name.

Format

DEFINE logical-name equivalence-name[,...]

 


Parameters logical-name

Specifies the logical name string, which is a character string containing from 1 to 255 characters. The following rules apply:

  • If the logical name is to be entered into the process or system directory logical name tables (LNM$PROCESS_DIRECTORY, LNM$SYSTEM_DIRECTORY), then the name can only have from 1 to 31 alphanumeric characters, including the dollar sign ($) and underscore (_). If the logical name translates to a logical name table name, any alphabetic characters in the name should all be uppercase.

In my opinion the unexpected of DEFINE loginal name operation would have to be remarked.

Thanks to all

Saludos.

 

Hoff
Honored Contributor
Solution

Re: Problem detected on temporary mailbox

So it's a documented bug.  OK.

Daniel Fernandez Illan
Trusted Contributor

Re: Problem detected on temporary mailbox

Thanks Hoff

Saludos