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