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!mhuxr!ihnp4!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: the continuing saga of process permanent files
Message-ID: <5834@ucbvax.ARPA>
Date: Wed, 27-Mar-85 16:34:19 EST
Article-I.D.: ucbvax.5834
Posted: Wed Mar 27 16:34:19 1985
Date-Received: Thu, 28-Mar-85 06:47:05 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 26

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