[Info-vax] Porting logical name applications to Unix

[John Wallace]

On Sep 30, 2:30 pm, koeh... at eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <icSdnWlrjO48rVzXnZ2dnUVZ_hqdn... at earthlink.com>, "John Reagan" <johnrrea... at earthlink.net> writes:
>
>
>
> > Alan is talking about the CRTL's caching of getenv() calls and whether it
> > should do another $TRNLNM behind your back.  For certain things, a single
> > translation once is all you need.  For other things, you'd actually want to
> > translate again so be careful.
>
> >        Performance Optimizations:         default setting
>
> >           DECC$ENABLE_GETENV_CACHE        DISABLE
> >           DECC$LOCALE_CACHE_SIZE          0
> >           DECC$TZ_CACHE_SIZE              2
>
>    OK, that's an advantage of logical names that AFAIK can be emulated on
>    UNIX only through links:  the file system automatically finds the target
>    without an explicit getenv().
>
>    getenv() looking at both DCL symbols and logical names on VMS does provide
>    some capabilities that it doesn't have on UNIX, but that can lead to
>    confusion.  Since VMS' getenv() looks at logical names first, the
>    following example shows how setting up a both has the documented behaviour,
>    which might not be what a newbie from UNIX land would expect when
>    translating a shell script that set an environment variable to a DCL
>    script that sets a DCL symbol:
>
> eisner> type a.c
> #include <stdio.h>
> #include <stdlib.h>
>
> main ()
> {
>    char *a = getenv("A");
>    if (a) printf("%s\n",a);
>
> }
>
> eisner> define a b
> eisner> r a.exe
> B
> eisner> a:=c
> eisner> r a.exe
> B
> eisner> deass a
> eisner> r a.exe
> C

" the file system automatically finds the target without an explicit
getenv()."

A limited implementation of this concept was introduced as part of the
TruCluster support in Tru64 UNIX V5.0; in a link to
../clusters/members/{memb}/blah or similar, the Virtual File System
layer automagically substitutes {memb} with something that uniquely
identifies the path appropriate for the cluster member doing the
lookup, if you see what I mean.

I have no idea where that code lives these days. Oracle RAC?
Sourceforge? (if only).

There must also be a similar concept in NonStop Clusters for SCO UNIX,
which also was property of CPQ at one point. I don't know the details
of that one at all.