From: briggs@encompasserve.org
Sent: Monday, January 07, 2002 10:43 AM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: logicals pointing to files opened by DCL

In article <u3c9mlk6o6td86@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:
> The RMS IFI is kept in the first longword of the logical name value.  Show
> logical knows to skip this.  Here's a program that will get the full
> filespec from the IFI in the logical:
[...]
>     **  Translate SYS$OUTPUT
>     **  The format of the result is:
>     **     word - length
>     **     word - IFI
>     **     char - device name string

I'm sure the code is correct.  John Vottero knows his stuff in this
regard.  But this comment is not.

The first two bytes are not the string length.  They are hard coded
as <ESC><NUL>:  %x1b %x00

The next word and the remaining characters are indeed the RMS IFI
and the device name string.

Interestingly, the device name string has mixed relevance.  For the
purposes of RMS (e.g. accessing a PPF through $OPEN), the device name
is largely ignored.  The IFI tells RMS which device to use.  For the
purposes of other system calls (e.g. assigning a channel with $ASSIGN)
the 4 byte PPF prefix is ignored and the device name string is used.

For 99.44% of all practical purposes, this tidbit of information is
unimportant.  But you can sometimes get a discrepancy between the device
pointed to by the IFI and the device pointed to by the device name
string...

$ open q lta0: /read
$ show log q
   "Q" = "_ALPHA$LTA5221" (LNM$PROCESS_TABLE)
$ show dev lta5221
%SYSTEM-W-NOSUCHDEV, no such device available
$ show dev lta5222 /fu

Terminal LTA5222:, device type unknown, is online, record-oriented device,
    carriage control.

    Error count                    0    Operations completed                  0
    Owner process           "VAXS09"    Owner UIC                      [VAXS09]
    Owner process ID        00032083    Dev Prot              S:RWPL,O:RWPL,G,W
    Reference count                1    Default buffer size                  80

(That's the device I just successfully opened).

A PPF $OPEN on a template device clones the device once to get the
device name string.  And then it clones it again to actually open a
channel to the device.

It took me quite a bit of head scratching to deduce what was going on
when I first encountered this behavior.  (I first saw it with TWA0 on
the original flavor of DEC Windows).  I think I SPR'd it way back when,
but it's a low enough profile issue that I'm unsurprised to find the
behavior unchanged today.

With network devices, you may well find that the device name component
of the PPF logical name is entirely missing.

$ open q 0::login.com /read
$ show log q
   "Q" = "" (LNM$PROCESS_TABLE)

	John Briggs