[fa.info-vax] the continuing saga of process permanent files

info-vax@ucbvax.ARPA (03/26/85)

From: Provan@LLL-MFE.ARPA


Well, since no one volunteered an answer to the async problem with
process permanent files, I'll try our latest discovery.  We tried
to translate Sys$Input using the recommended $TrnLNm system service
and found that it translated it correctly except is prepended the
longword 8101001B (hex) (approximate) to the beginning of the translated
string.  Anyone know what that means?  We assume it's some sort of
flag indicating information about the process permanent file, but
it sure does get in the way.

info-vax@ucbvax.ARPA (03/26/85)

From: Mark Johnson <MHJohnson@HI-MULTICS.ARPA>

Well, the translation of process permanent files ALWAYS have had some
nonsense tacked onto the start of the equivalence string.  In my VMS
System Services Manual (for V4, page 6-9;for V3.x, page 5-7) it talks
about the header being <ESC>, <NUL>, followed by a word holding the RMS
Internal File Identifier.  Presumably, you could use the IFI yourself
instead of opening the file for performance.

The text in both books follows with something like "If any of your
program applications must translate system-assigned logical names, the
program must be prepared to check for the existence of this header and
then to use only the desired part of the equivalence string".  There is
also an example in MACRO.  Bleah.  I hope this helps.

  --Mark <MHJohnson @ HI-MULTICS>

info-vax@ucbvax.ARPA (03/26/85)

From: LEICHTER <Leichter@YALE.ARPA>

    
    Well, since no one volunteered an answer to the async problem with
    process permanent files, I'll try our latest discovery.  We tried
    to translate Sys$Input using the recommended $TrnLNm system service
    and found that it translated it correctly except is prepended the
    longword 8101001B (hex) (approximate) to the beginning of the translated
    string.  Anyone know what that means?  We assume it's some sort of
    flag indicating information about the process permanent file, but
    it sure does get in the way.
I didn't remember seeing the original message, so I dug it up:    
    
    From: <Provan@LLL-MFE.ARPA>
    Date: Mon, 18 Mar 85 16:47 PST
    Subject: asynchronous process permanent files

    We were puzzled for an hour or so today about why some terminal
    input wasn't reacting asynchronously until we read the fine print
    under RAB$V_ASY which says "it is ignored for process permanent
    files."  Can someone explain why this would be?  We plan to get
    around it by translating Sys$Input and using the translation to
    open the terminal (or whatever it happens to be).  Is this going
    to work?  Is there a simpler way, like an ansynchronous-even-for-
    process-permanent-files bit?
a)  Asynchronous I/O to process-permanent files (PPF's) doesn't work.  Period.
PPF's are files actually opened by an inner access mode - typically, by DCL in
supervisor mode.  The I/O is actually done by the inner-mode code, and passed
on to you.  That's how DCL arranges to pass on data in command files to pro-
grams while automatically regaining control when a line starting with a "$"
is seen in the command file.  Your initial SYS$INPUT, SYS$OUTPUT, and so on,
are actually opened when your process is created, way before your program
gets to run.  Since the inner level code that does the I/O is doing it syn-
chronously, there is no way you can do asynchronous I/O on top of it.

b)  The extra stuff you see at the beginning of the equivalence strings for
PPF's is a two-byte escape sequence and an internal file id.  The internal
file id is used by RMS to figure out which particular inner-access-mode
file you are referring to.  It is not directly useful to your code.

The escape sequence stuff is all documented.  You can find it in the index
as easily as I can.

c)  The easiest way to get at the terminal is to open device TT:.  You can
also use SYS$COMMAND - use the $GETDVI service to get the DEVNAM (device name)
field.  Either method will work even when your program is run from within a
command file, where SYS$INPUT is the command file, not the terminal.  In
a batch file, on the other hand, TT: will be the null device and SYS$COMMAND
will be a PPF pointing to the batch file.

d)  It is usually recommended that one read the documentation before trying
to use little things like system calls.
							-- Jerry
-------

info-vax@ucbvax.ARPA (03/28/85)

From: decvax!ittvax!bunker!garys@BERKELEY

> From: Provan@LLL-MFE.ARPA
> 
> Well, since no one volunteered an answer to the async problem with
> process permanent files, I'll try our latest discovery.  We tried
> to translate Sys$Input using the recommended $TrnLNm system service
> and found that it translated it correctly except is prepended the
> longword 8101001B (hex) (approximate) to the beginning of the translated
> string.  Anyone know what that means?  We assume it's some sort of
> flag indicating information about the process permanent file, but
> it sure does get in the way.

It's not a long word, it should be interpreted as the 4 bytes ESC,
0, 01, 81 in your example.  The first byte is always ESC; I don't
remember what the others are, but, if I remember correctly, that's
how VMS recognizes the process permanent files.  The translation
is correct; those four bytes are part of the logical name table.
(Thus, when you translate logical names, you have to check the
first character of the result for ESC and skip 4 bytes if it matches). 

This probably comes under the heading of "Now he tells me," but
I hope it helps a little.

Gary Samuelson
ittvax!bunker!garys

info-vax@ucbvax.ARPA (04/12/85)

From: John_Aronsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA

The answers to your questions can be found in "Volume 5A" manual,
section 6.1.6

"At login, the system creates default logical name table entries
for process permanent files. The equivalence name for these entries
(for example, SYS$INPUT and SYS$OUTPUT) are preceded with a four-byte
header that contains the following:"

Byte(s)         Contents
0               ^X1B (Escape character)
1               ^X00
2-3             VAX RMS Internal File Identifier (IFI)

I hope it was to some help.
/John Aronsson