Anomalous (?) behavior of DEFINE/EXECUTIVE

[Jan van den Ende]

The normal behavior of VMS is, that commands that needs the issuer to have a certain privilege will simply fail when said issuer does not currently have that privilege.

I would not expect the command to silently do something else.

Why is DEFINE/EXEC an exception to that rule?

A not uncommon scenario:

$ DEFINE/EXEC LNM something /table=xyz
.
.
(later, from a process currently NOT holding CMEXEC)
$ DEFINE/EXEC LNM something /table=xyz
.. this command simply succeeds..
.
.
(later again, from process with CMEXEC enabled)
$ DEFINE/EXEC LNM somethingelse /table=xyz
.. command successful..

But. using LNM will NOT use the intended new definition, because most normal operations still see the supervisor-mode LNM that was never intended in the first place!

I have already seen weird and confusing results, especially when table XYZ is the system or cluster table!

Should a command that requires a priv (CMEXEC is this case) not FAIL if the priv is missing? Or at the very least issue an informational message?


I am looking forward for an explanation, but I wonder if any explanation exists that convinces me that this is how it should be.

Proost.

Have one on me.

jpe

[Graham Burley]

It's confused me in the past, but it is at least documented.

$ help define/exec

DEFINE

/EXECUTIVE_MODE

Requires SYSNAM (system logical name) privilege to create an
executive-mode logical name.

Creates an executive-mode logical name in the specified table.

If you specify the /EXECUTIVE_MODE qualifier and you do not have
SYSNAM privilege, the DEFINE command ignores the qualifier and
creates a supervisor-mode logical name. The mode of the logical
name must be the same or less privileged than the mode of the
table in which you are placing the name.

[Jan van den Ende]

Graham,

yes, I know it is documented. But it is the rationale behind it that I am so curious about..

Proost.

Have one on me.

jpe

[Jan van den Ende]

BTW,

I _KNOW_ of the NO_ALIAS name_attribute, which makes the behavior like what I would expect. I use it for that, but there are still many historical places that I have to find and modify.
The strange thing is that you need a qualifier to achieve anticipated behavior.
I consider qualifiers to modify expected behavior in ways that are described by the qualifier.

fwiw

Proost.

Have one on me.

jpe

[Jon Pinkley]

My guess is that it wasn't intended behavior, it probably started as a programming mistake, but then some customers started to rely on the behavior.

What I don't understand it why they couldn't at least return an informational message.

If you don't have privs turned on, and you do the following, the message that is displayed is very confusing.

$ show log foo/ful
"FOO" [exec] = "BAR" (LNM$PROCESS_TABLE)
$ deas /exec foo
%SYSTEM-F-NOLOGNAM, no logical name match
$

[Jan van den Ende]

Jon,

I agree that the message can be confusing the first time, but at least, you _GET_ the warning!

But consider the case I described in my initial example, and add yours to it.

LNM FOO is defined in EXEC mode as BAR,
and in supervisor mode as RAB.

NOW $ DEAS /EXEC FOO (without CMEXEC)
THAT is even more strange the DEFINE case!

Proost.

Have one on me.

jpe

[Hoff]

This particular (mis?)feature has the benefit of decades of use within various applications.

Whether or not it was intended, it's the way the code ended up and more than a little stuff has been coded to use it as (mis?)implemented.

There are several of these around.

The leading underscore notation is another that has a similar class of (mis?)feature lurking; where you can redirect a leading underscore logical name using (wait for it) a logical name.

I was one of the folks that got the existing doc changed to explicitly highlight this (un)expected behavior. I'd be surprised if HP decided to change this behavior, given the downside to applications that assume the current behavior...

[Jan van den Ende]

Hoff,

>>>
I was one of the folks that got the existing doc changed to explicitly highlight this (un)expected behavior.
<<<

At least thanks for that!

I am glad you agree on the unexpectedness.

It is probably true that changing now would break things, but, would an informational message be too much to ask? (not a warning, nor error, because THAT could/would change any ON ... behavior)

I think I will push forward with implementing NO_ALIAS in the potentially problematic situations. :-(

Proost.

Have one on me.

jpe

[David Jones_21]

The behavior is consistent with the underlying system services, which followed the convention of silently 'maximizing' the access mode argument against the access mode of the caller.
There are now innumerable instances of SS calls that depend upon this behavior since they were coded with an acmode argument of zero.

[Willem Grooters]

It may be weird, it makes sense.
The default mode with DEFINE is /SUPERVISER - not so strange because DCL runs in SUPERVISOR mode. ANY user that is capable to DEFINE will do so /MODE=SUPER(VISOR). I don't think you would like ordinary users to overrule that setting with /MODE=EXEC. It might be the background of that once made decision.

[Hein van den Heuvel]

Yeah, sure seems like a documented bug.
I also never liked how an logical can be hiding behind a user/super logical for simple DCL show logical commands.
There is $SHOW LOG/ALL to check all tables.
I wish there was a $SHOW LOG/ACC=ALL to check all modes.
The help for /ACC shows:

"The default value for this qualifier is USER_MODE; by default any definitions in all four access modes are displayed."

So this bit about default=USER_MODE is meaningless really. As it is caught be the second line. And the second line should really ready "The lowest access mode".
But I'd like the any to be 'all' somehow.


Anyway...
The command itself can not be blamed, as the system service behind it also silenty ignore the mode request if not authorized.
That's really really a bug.
It should at the very least return an informational.
$ write sys$output f$mess(35)
%SYSTEM-I-NOPRIV, insufficient privilege or object protection violation


I'll append two little C test programs in case anyone ever wanted a quick test skeleton for CRELNM

Cheers,
Hein.


$ type crelnm*.c

CRELNM_EXEC.C;1

#include
#include
#include
#include
typedef struct { short len, cod; void *address; short *retlen; } item;
main()
{
$DESCRIPTOR (lognam,"ABCD");
$DESCRIPTOR (tabnam,"LNM$JOB");
char logval_1[] = "aap", logval_2[] = "noot";
item crelnm_items[] = {
sizeof logval_1 - 1, LNM$_STRING, logval_1, 0,
sizeof logval_2 - 1, LNM$_STRING, logval_2, 0,
0, 0, 0, 0 };
int stat, SYS$CRELNM(), SYS$CMEXEC(), mode=PSL$C_EXEC;
void *crelnm_args[] = {NULL, NULL, &tabnam, &lognam, &mode, &crelnm_items};
*(int *) crelnm_args = sizeof crelnm_args / sizeof crelnm_args[0] - 1;
stat = SYS$CMEXEC ( &SYS$CRELNM, crelnm_args);
printf ("Stat = %d = %%x%04X\n", stat, stat);
}

CRELNM_USER.C;1

#include
#include
#include
#include
typedef struct { short len, cod; void *address; short *retlen; } item;
main()
{
$DESCRIPTOR (lognam,"ABCD");
$DESCRIPTOR (tabnam,"LNM$JOB");
char logval_1[] = "aap", logval_2[] = "noot";
item crelnm_items[] = {
sizeof logval_1 - 1, LNM$_STRING, logval_1, 0,
sizeof logval_2 - 1, LNM$_STRING, logval_2, 0,
0, 0, 0, 0 };
int stat, mode = PSL$C_EXEC, SYS$CRELNM();
stat = SYS$CRELNM(0, &tabnam, &lognam, &mode, &crelnm_items);
printf ("Stat = %d = %%x%04X\n", stat, stat);
}
$




If anyone ever

[Hoff]

>>>It is probably true that changing now would break things, but, would an informational message be too much to ask? (not a warning, nor error, because THAT could/would change any ON ... behavior)<<<

Toss a request at HP.

I'd tend to assume not, since tossing out diagnostics on stuff that works is just asking for increases in the numbers of support calls. Or a request from some other customer to suppress their gazillions of diagnostics that are now arising from their previously-functional application, and that are now mucking up DCL menu displays and log files and such.

And this in addition to the classic software engineering trade-offs involved with all of the competing requests for engineering changes. Having a DCL "questionable code" flag that causes these sorts of diagnostics to be issued might be a useful design one-plus, but that's not a trivial project.

As for corollaries to these sorts of changes, ask long-time OpenVMS C programmers what happens as the compiler has tightened up its syntax checks, and as the C standards evolved. A number of folks simply wanted a way to shut these diagnostics off.

But again, this is fodder for HP to decide.

[Jess Goodman]

Hein,

You said,
"There is $SHOW LOG/ALL to check all tables."

As far as I can tell using either /ALL or /NOALL has no effect whatsoever on the SHOW LOGICAL command.

[John Gillings]

Jan,

IMHO this is a bug.

I elevated it to engineering in the early 1990's. The conclusion at that time was the behaviour had been around too long to break. I pushed back, but the best they would do was document it - hence the HELP entry. (Even issuing an information message was deemed to be too much of a change to implement.)

It may be worth raising again. Perhaps the responsible engineer will have a different opinion.

Good Luck!