In article
<4f065429-003a-460c-b0b7-63ad8756f2cf@n20g2000hsh.googlegroups.com>, AEF
writes:

> On Dec 22, 6:26 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> remove CLOTHES to reply) wrote:
> > In article <476bda4f$0$22049$c3e8...@news.astraweb.com>, JF Mezei
> >
> > writes:
> > > > $define/system/exec/trans=(conc,terminal) $mydisk 'f$trnlnm("$DISK2")
> > > > $define/system/exec/trabs=(conc) $mydisk $DISK2
> >
> > > in cases where you want to:
> >
> > > > $define/system/trans=(conc,term) $myroot 'f$trnlnm("$mydisk")'[myroot.]
> >
> > > The first case will work. The second case won't work because $myroot
> > > will point to $disk2 which won't translate to whatever disk drive it is
> > > pointing to.
> >
> > Yes. However, if you really need to define a (CONC,TERM) logical name,
> > I would recommend writing a procedure which uses F$PARSE, NOCONCEAL etc
> > to define it properly whatever parameter is passed to it.
>
> WHY would you ever "really need" to do this? The purpose of "terminal"
> is to stop logical name translation when a "terminal" equivalence name
> is encountered. You don't need "terminal" in and of itself. You only
> need it when you have to stop logical name translation. If you're
> equivalence name contains a logical name, you need to NOT make that
> equivalence name "terminal".

Various software wants/needs terminal equivalence names for security
reasons, so a user can't redefine a logical name and thus change where
the logical name used by the software ends up (yes, there are other ways
to achieve the same effect). In such cases, the setup procedure for
this software could use such a procedure: the manager would enter the
target disk, and the procedure would translate it until it got to the
final translation and then use that for its own definitions.

On Dec 22, 10:27 am, AEF wrote:
> On Dec 22, 6:26 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> remove CLOTHES to reply) wrote:
>
>
>
> > In article <476bda4f$0$22049$c3e8...@news.astraweb.com>, JF Mezei
>
> > writes:
> > > > $define/system/exec/trans=(conc,terminal) $mydisk 'f$trnlnm("$DISK2")
> > > > $define/system/exec/trabs=(conc) $mydisk $DISK2
>
> > > in cases where you want to:
>
> > > > $define/system/trans=(conc,term) $myroot 'f$trnlnm("$mydisk")'[myroot.]
>
> > > The first case will work. The second case won't work because $myroot
> > > will point to $disk2 which won't translate to whatever disk drive it is
> > > pointing to.
>
> > Yes. However, if you really need to define a (CONC,TERM) logical name,
> > I would recommend writing a procedure which uses F$PARSE, NOCONCEAL etc
> > to define it properly whatever parameter is passed to it.
>
> WHY would you ever "really need" to do this? The purpose of "terminal"
> is to stop logical name translation when a "terminal" equivalence name
> is encountered. You don't need "terminal" in and of itself. You only
> need it when you have to stop logical name translation. If you're
> equivalence name contains a logical name, you need to NOT make that
> equivalence name "terminal".

Uh, I need to correct myself here. (Apologies if that bugs anyone --
responding to my own post, i.e.)

Actually, I have a case at work where I have one logical name
translate to another and stop there via the terminal translation
attribute as it is then plopped into a file-spec containing a node
name and I need it translated on the remote node specified in that
file-spec.

So still yet again, it's what you need to do, not that you need
conc,term for the sake of it being conc,term.

>
> Remember: CONC and TERM are attributes of equivalence names, not
> logical names. For example, SYS$SYSROOT translates to a search string
> containing a terminal equivalence name followed by a non-terminal one.
> So you can't say that SYS$SYSROOT is "terminal" or not. It translates
> to equivalence names of both types.
>
> AEF
>
> AEF

AEF

On Dec 22, 2:53 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
remove CLOTHES to reply) wrote:
> In article
> <4f065429-003a-460c-b0b7-63ad8756f...@n20g2000hsh.googlegroups.com>, AEF
>
>
>
> writes:
> > On Dec 22, 6:26 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> > remove CLOTHES to reply) wrote:
> > > In article <476bda4f$0$22049$c3e8...@news.astraweb.com>, JF Mezei
>
> > > writes:
> > > > > $define/system/exec/trans=(conc,terminal) $mydisk 'f$trnlnm("$DISK2")
> > > > > $define/system/exec/trabs=(conc) $mydisk $DISK2
>
> > > > in cases where you want to:
>
> > > > > $define/system/trans=(conc,term) $myroot 'f$trnlnm("$mydisk")'[myroot.]
>
> > > > The first case will work. The second case won't work because $myroot
> > > > will point to $disk2 which won't translate to whatever disk drive it is
> > > > pointing to.
>
> > > Yes. However, if you really need to define a (CONC,TERM) logical name,
> > > I would recommend writing a procedure which uses F$PARSE, NOCONCEAL etc
> > > to define it properly whatever parameter is passed to it.
>
> > WHY would you ever "really need" to do this? The purpose of "terminal"
> > is to stop logical name translation when a "terminal" equivalence name
> > is encountered. You don't need "terminal" in and of itself. You only
> > need it when you have to stop logical name translation. If you're
> > equivalence name contains a logical name, you need to NOT make that
> > equivalence name "terminal".
>
> Various software wants/needs terminal equivalence names for security
> reasons, so a user can't redefine a logical name and thus change where
> the logical name used by the software ends up (yes, there are other ways
> to achieve the same effect). In such cases, the setup procedure for
> this software could use such a procedure: the manager would enter the
> target disk, and the procedure would translate it until it got to the
> final translation and then use that for its own definitions.

Then I misunderstood what you first said. I thought you wanted a
logical name to point to one equivalence name with concealed and
terminal attributes just for the sake of having conc and term because
the other one does. (That's what I thought you said.) But the example
you give here is not that. It is what I said: You do something because
you need it to work a certain way according to your needs.

In this example, how would it stop the user from simply redefining the
application logical names?

AEF

In article
<319ff94e-2a42-4f73-a808-5e533635b184@s48g2000hss.googlegroups.com>, AEF
writes:

> In this example, how would it stop the user from simply redefining the
> application logical names?

If they are terminal, then if one points to DSA425, he can't define
DSA425 himself. As for other logical names (and what would probably
work for disks as well), the application could insist explicitly on
executive-mode logical names or they could be defined with NOALIAS.

In article , helbig@astro.multiCLOTHESvax.de
(Phillip Helbig---remove CLOTHES to reply) writes:

> In article
> <319ff94e-2a42-4f73-a808-5e533635b184@s48g2000hss.googlegroups.com>, AEF
> writes:
>
> > In this example, how would it stop the user from simply redefining the
> > application logical names?
>
> If they are terminal, then if one points to DSA425, he can't define
> DSA425 himself.

Or, rather, he can, but it wouldn't affect an application using a
logical name pointing to DSA425 and specified as TERMINAL.

On Dec 24, 3:34 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
remove CLOTHES to reply) wrote:
> In article , hel...@astro.multiCLOTHESvax.de
> (Phillip Helbig---remove CLOTHES to reply) writes:
>
> > In article
> > <319ff94e-2a42-4f73-a808-5e533635b...@s48g2000hss.googlegroups.com>, AEF
> > writes:
>
> > > In this example, how would it stop the user from simply redefining the
> > > application logical names?
>
> > If they are terminal, then if one points to DSA425, he can't define
> > DSA425 himself.
>
> Or, rather, he can, but it wouldn't affect an application using a
> logical name pointing to DSA425 and specified as TERMINAL.

But he could just redefine the logical name that points to DSA425:
[something]. So you still need to ignore user and supervisor mode
logical names.

AEF

In article
<1384b006-7d60-4c3b-9dbc-0a0bc3254779@e6g2000prf.googlegroups.com>, AEF
writes:

> > > > In this example, how would it stop the user from simply redefining the
> > > > application logical names?
> >
> > > If they are terminal, then if one points to DSA425, he can't define
> > > DSA425 himself.
> >
> > Or, rather, he can, but it wouldn't affect an application using a
> > logical name pointing to DSA425 and specified as TERMINAL.
>
> But he could just redefine the logical name that points to DSA425:
> [something]. So you still need to ignore user and supervisor mode
> logical names.

Yes, that's why I mentioned NOALIAS. That, of course, will also cover
the case above, so arguably TERMINAL isn't needed for this reason. (Was
TERMINAL, or its functional equivalent, introduced before NOALIAS?
Probably, since the leading _ goes way back.)

Was the original function of TERMINAL to save CPU cycles by saving the
last translation attempt?

On Dec 24, 9:55 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
remove CLOTHES to reply) wrote:
> In article
> <1384b006-7d60-4c3b-9dbc-0a0bc3254...@e6g2000prf.googlegroups.com>, AEF
>
> writes:
> > > > > In this example, how would it stop the user from simply redefining the
> > > > > application logical names?
>
> > > > If they are terminal, then if one points to DSA425, he can't define
> > > > DSA425 himself.
>
> > > Or, rather, he can, but it wouldn't affect an application using a
> > > logical name pointing to DSA425 and specified as TERMINAL.
>
> > But he could just redefine the logical name that points to DSA425:
> > [something]. So you still need to ignore user and supervisor mode
> > logical names.
>
> Yes, that's why I mentioned NOALIAS. That, of course, will also cover
> the case above, so arguably TERMINAL isn't needed for this reason. (Was
> TERMINAL, or its functional equivalent, introduced before NOALIAS?
> Probably, since the leading _ goes way back.)
>
> Was the original function of TERMINAL to save CPU cycles by saving the
> last translation attempt?

I was trying to copy and paste a Google Groups thread here but for
some reason the paste operation screws up the entire input field. So
do this: Search for TERMINAL PURPOSE in comp.os.vms on Google Groups
(groups.google.com/group/comp.os.vms) and read the first thread that
pops up.

Also, run a command like

$ SHOW LOGICAL/FULL */TABLE=*

and check out logical names like

"LNM$STARTUP_TABLE" [exec,table] = "" [terminal]

Since you can't reDEFINE "", I suppose this would support the saving-
CPU-cycles theory. Also, I think it's just a precaution against a user
or system mangler from redefining the device or logical name portions
of equivalence names of important logical names.

So I think it's both: saving CPU cycles and preventing the define-a-
device-name-as-a-logical-name quick-and-dirty "fix" trick.

AEF

AEF wrote:

> So I think it's both: saving CPU cycles and preventing the define-a-
> device-name-as-a-logical-name quick-and-dirty "fix" trick.

consider the following:

$DEFINE/qualifiers SYSUAF $11$DQA0:[shared]sysuaf.dat

without a trans=terminal, someone could define a logical name $11$dqa0
to point to another drive (or one they created with the LDdriver).

On Dec 24, 4:12 pm, JF Mezei wrote:
> AEF wrote:
> > So I think it's both: saving CPU cycles and preventing the define-a-
> > device-name-as-a-logical-name quick-and-dirty "fix" trick.
>
> consider the following:
>
> $DEFINE/qualifiers SYSUAF $11$DQA0:[shared]sysuaf.dat
>
> without a trans=terminal, someone could define a logical name $11$dqa0
> to point to another drive (or one they created with the LDdriver).

Nope. You have to do

$ DEFINE $11$DQA0 /SYSTEM/EXECUTIVE_MODE
^^^^^^^^^^^^^^^

for this redirect to work. And if you can do that, well, you're
already well on your way to being able to cause trouble, no?

AEF

On Dec 24, 6:26 pm, AEF wrote:
> On Dec 24, 4:12 pm, JF Mezei wrote:
>
> > AEF wrote:
> > > So I think it's both: saving CPU cycles and preventing the define-a-
> > > device-name-as-a-logical-name quick-and-dirty "fix" trick.
>
> > consider the following:
>
> > $DEFINE/qualifiers SYSUAF $11$DQA0:[shared]sysuaf.dat
>
> > without a trans=terminal, someone could define a logical name $11$dqa0
> > to point to another drive (or one they created with the LDdriver).
>
> Nope. You have to do
>
> $ DEFINE $11$DQA0 /SYSTEM/EXECUTIVE_MODE
> ^^^^^^^^^^^^^^^
>
> for this redirect to work. And if you can do that, well, you're
> already well on your way to being able to cause trouble, no?
>
> AEF

Hell, if you already have access to the SYSTEM logical name table,
you're already well on your way to being able to cause trouble.

Just *specifically* what are you concerned about?

AEF

Phillip Helbig---remove CLOTHES to reply wrote:
>
> In article , helbig@astro.multiCLOTHESvax.de
> (Phillip Helbig---remove CLOTHES to reply) writes:
>
> > In article
> > <319ff94e-2a42-4f73-a808-5e533635b184@s48g2000hss.googlegroups.com>, AEF
> > writes:
> >
> > > In this example, how would it stop the user from simply redefining the
> > > application logical names?
> >
> > If they are terminal, then if one points to DSA425, he can't define
> > DSA425 himself.
>
> Or, rather, he can, but it wouldn't affect an application using a
> logical name pointing to DSA425 and specified as TERMINAL.

If the LNM in question exists in a Group or System table, but is aliased
in a Process or Job table, the alias can override, regardless of whether
the "real" translation has the TERMINAL attribute. NO_ALIAS would be
important here.

David J Dachtera
DJE Systems


Remember that LNMs can also be search lists.

Phillip Helbig---remove CLOTHES to reply wrote:
>
> In article
> <1384b006-7d60-4c3b-9dbc-0a0bc3254779@e6g2000prf.googlegroups.com>, AEF
> writes:
>
> > > > > In this example, how would it stop the user from simply redefining the
> > > > > application logical names?
> > >
> > > > If they are terminal, then if one points to DSA425, he can't define
> > > > DSA425 himself.
> > >
> > > Or, rather, he can, but it wouldn't affect an application using a
> > > logical name pointing to DSA425 and specified as TERMINAL.
> >
> > But he could just redefine the logical name that points to DSA425:
> > [something]. So you still need to ignore user and supervisor mode
> > logical names.
>
> Yes, that's why I mentioned NOALIAS. That, of course, will also cover
> the case above, so arguably TERMINAL isn't needed for this reason. (Was
> TERMINAL, or its functional equivalent, introduced before NOALIAS?

Be careful about how you think of /TERMINAL.

- /TERMINAL does NOT prevent the system form continuing to traverse a
search list.

- /NOALIAS means that a LNM can not be DEFINEd at a lower privilege
level. For example: a LNM DEFINEd /EXEC cannot be aliased in either
/SUPER or /USER. This is *NOT* the same as abandoning translation
recursion for any element of a search list.

David J Dachtera
DJE Systems

JF Mezei wrote:
>
> AEF wrote:
>
> > So I think it's both: saving CPU cycles and preventing the define-a-
> > device-name-as-a-logical-name quick-and-dirty "fix" trick.
>
> consider the following:
>
> $DEFINE/qualifiers SYSUAF $11$DQA0:[shared]sysuaf.dat
>
> without a trans=terminal, someone could define a logical name $11$dqa0
> to point to another drive (or one they created with the LDdriver).

Well, that depends. Unless "/qualifiers" includes /SYSTEM, the user may
have enough access to replace that definition (at the /GROUP, /JOB or
/PROCESS(default) level).

As Alan correctly points out, additional privilege requirements can
thwart such attempts.

David J Dachtera
DJE Systems

In article
<3f212454-ab83-4d30-8d8d-f3064dbce599@j64g2000hsj.googlegroups.com>, AEF
writes:

> Also, run a command like
>
> $ SHOW LOGICAL/FULL */TABLE=*
>
> and check out logical names like
>
> "LNM$STARTUP_TABLE" [exec,table] = "" [terminal]
>
> Since you can't reDEFINE "", I suppose this would support the saving-
> CPU-cycles theory. Also, I think it's just a precaution against a user
> or system mangler from redefining the device or logical name portions
> of equivalence names of important logical names.
>
> So I think it's both: saving CPU cycles and preventing the define-a-
> device-name-as-a-logical-name quick-and-dirty "fix" trick.

OK, I agree, but I admit I don't see the point of defining
LNM$STARTUP_TABLE to "".

In article <477012e2$0$25359$c3e8da3@news.astraweb.com>, JF Mezei
writes:

> AEF wrote:
>
> > So I think it's both: saving CPU cycles and preventing the define-a-
> > device-name-as-a-logical-name quick-and-dirty "fix" trick.
>
> consider the following:
>
> $DEFINE/qualifiers SYSUAF $11$DQA0:[shared]sysuaf.dat
>
> without a trans=terminal, someone could define a logical name $11$dqa0
> to point to another drive (or one they created with the LDdriver).

True, but in this case they can't do any damage or, rather, if they can
define the logical name so that it is dangerous, they have enough
privileges to wreak havoc in other ways as well.

On Dec 24, 3:12*pm, JF Mezei wrote:
> consider the following:
>
> $DEFINE/qualifiers *SYSUAF $11$DQA0:[shared]sysuaf.dat
>
> without a trans=terminal, someone could define a logical name $11$dqa0
> to point to another drive (or one they created with the LDdriver).

In addition to the other comments about how a malicious user would
need SYSNAM to really have an impact, and how /TRANS=TERMINAL doesn't
necessarily stop iterative translation, this definition would be a
sign of a bad systems manager. Using a physical device name like this
is just bad style and can make transitioning to other disk interfaces
a nightmare. Given the $MOUNT syntax of

$ MOUNT /SYSTEM _$11$DQA0: volume_label logical_name

then the worst-case reference to this drive should be either through
the "logical_name" on the $MOUNT command line or the DISK$volume_label
logical that gets created by OpenVMS. I'll give you the benefit of
the doubt, though, that this was just an example from you and not
something you really do on a production system.

If a physical device name is really what one wants (despite all the
valid reasons to avoid doing that), then the more appropriate syntax
would be:

$ DEFINE /qualifiers SYSUAF _$11$DQA0:[SHARED]SYSUAF.DAT

That would preclude a redefinition from interfering with the system
managers intention. I'll leave the "/qualifiers" open since that's
how you show it.

On Dec 25, 5:34 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
remove CLOTHES to reply) wrote:
> In article
> <3f212454-ab83-4d30-8d8d-f3064dbce...@j64g2000hsj.googlegroups.com>, AEF
>
>
>
> writes:
> > Also, run a command like
>
> > $ SHOW LOGICAL/FULL */TABLE=*
>
> > and check out logical names like
>
> > "LNM$STARTUP_TABLE" [exec,table] = "" [terminal]
>
> > Since you can't reDEFINE "", I suppose this would support the saving-
> > CPU-cycles theory. Also, I think it's just a precaution against a user
> > or system mangler from redefining the device or logical name portions
> > of equivalence names of important logical names.
>
> > So I think it's both: saving CPU cycles and preventing the define-a-
> > device-name-as-a-logical-name quick-and-dirty "fix" trick.
>
> OK, I agree, but I admit I don't see the point of defining
> LNM$STARTUP_TABLE to "".

Because that's how logical name tables work.

Example:

$ CREATE/NAME AEF
$ SHOW LOG AEF/TABLE=*DIR*/FUL
"AEF" [super,table] = "" [terminal] (LNM$PROCESS_DIRECTORY)
$ DEFINE LNM EQV /TABLE=AEF
$ SHOW LOG /FULL /TABLE=AEF

(AEF) [super]
[no protection information]

"LNM" [super] = "EQV"
$

Also, you can't explicitly define a logical name to be null. Being
null apparently means it's really a logical name table:

$ DEFINE NULL ""
%SYSTEM-F-IVLOGNAM, invalid logical name

AEF

Phillip Helbig---remove CLOTHES to reply wrote:
>
> In article
> <3f212454-ab83-4d30-8d8d-f3064dbce599@j64g2000hsj.googlegroups.com>, AEF
> writes:
>
> > Also, run a command like
> >
> > $ SHOW LOGICAL/FULL */TABLE=*
> >
> > and check out logical names like
> >
> > "LNM$STARTUP_TABLE" [exec,table] = "" [terminal]
> >
> > Since you can't reDEFINE "", I suppose this would support the saving-
> > CPU-cycles theory. Also, I think it's just a precaution against a user
> > or system mangler from redefining the device or logical name portions
> > of equivalence names of important logical names.
> >
> > So I think it's both: saving CPU cycles and preventing the define-a-
> > device-name-as-a-logical-name quick-and-dirty "fix" trick.
>
> OK, I agree, but I admit I don't see the point of defining
> LNM$STARTUP_TABLE to "".

What, in your thoughts, would be an appropriate value, if not ""?

(Hint: Note "[exec,table]".)

David J Dachtera
DJE Systems