Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: the continuing saga of process permanent files
Message-ID: <5804@ucbvax.ARPA>
Date: Tue, 26-Mar-85 13:52:42 EST
Article-I.D.: ucbvax.5804
Posted: Tue Mar 26 13:52:42 1985
Date-Received: Wed, 27-Mar-85 04:26:25 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 54

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
-------