Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 14:59, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 08:08, sampsa at mac.com wrote: Funny thing about LEGATO's INFO.TXT - my parser looks for the .BEGIN-HECNET-INFO tag and deletes all text after that. I should probably make a manual HLP file for LEGATO, Bob you OK with that? LEGATO's INFO.TXT have real yucky file attributes and a real yucky file format. :-) (What on earth was used to produce it???) Stream_CR typically surfaces with files coming from WEENDOZE. Ah. Yes, that would be a possible, source, I guess. But I find Stream_CR a but surprising. Maybe I'm just too ignorant of VMS formats here. But isn't there a plain Stream as well (which also exists in RSX), in which records are terminated by CR+LF, and which is what I would expect a Windows machine to produce... VMS file formats: FIX ........ Fixed Record Size; Length in MRS VAR ........ Variable; Length embedded in record VFC ........ Variable Format Control; Length and Format embedded in record Stream ..... Stream; Length from scan for <CR><LF> Stream_LF .. Stream; Length from scan for <LF> Stream_CR .. Stream; Length from scan for <CR> UDF ........ Undefinded. Directory LEGATO::SYS$SPECIFIC:[FAL$SERVER] 31-DEC-12 13:59:07 INFO.TXT;1 Size: 8./35. Created: 08-JUL-10 10:54:52 Owner: [000376,000373] Revised: 27-DEC-12 19:24:34(6.) Expires: <none_specified> File protection: System:RE, Owner:RE, Group:RE, World:RE File organization: Sequential File attributes: Allocation=0 Record format: Stream-CR, no maximum defined Record attributes: Carriage return What does it mean if you have stream-CR and attribute Carriage Return? I mean, yes, each record is separated by a CR, and then what? Add an additional CR at the end of each line? "Record format" refers to the data in the file. Stream_CR means that the records are delineated with a <carriage-return> character. RMS will then populate its internal buffers and the user's buffer upon a $GET with the current record data up to the <carriage-return> character. RMS internal handlers discard this <carriage-return> and update the NRP (Next Record Pointer) leaving it pointing after the <carriage-return> to a subsequent (assuming there is one) record. "Record attributes" refer to how to present the record to the application that performed the $GET to read the record. With "Record attributes" set to "Carriage return", RMS will synthesize a record with <carriage-return> and <line-feed>. If the "Record format" is VFC (Variable Format Control), this synthesis is over-ruled by the format in the VFC header of each and every record. Ah. This do make sense, actually, and matches RSX. (Except there is no Stream_CR, there is only a Stream format.) Perhaps becasue there was no WEENDOZE when RSX was still being developed by d|i|g|i|t|a|l. I obviously did not think enough here. However, the actual contents of the file, as seen if I copy it to RSX, totally belies this, as there aren't a single CR in that whole file. But it might be that things are mangled in the process of the transfer. Very likely. I'd think that these files should be maintained on nodes in a format that is much more easily consumed by RMS and DECnet vis a vis a VAR format file. This is fugly. On VMS, I would typically read a file like this into TECO and then, EX (exit) to write out a new file that will have typical VMS RMS file attributes. $ EDITT/TECO <the-file> *EX$$ <-- the $ is echoed by TECO when entring an escape $ (ie. escape => CTRL-[) How wonderful to see someone else but me use Teco. Yes, this is a pretty useful property of Teco. It "fixes" weird files... TECO appears prominently in my DESCRIP.MMS rules for things like RUNOFF used to process sources such as .RNH (RuNoff Help files). RUNOFF takes .RNH files and formats a .HLP file, but it will leave <CR><LF> in these target stains which I hate to see when I need to check for errors in the formatting. So, there's a rule after the .SUFFIXES definitions for the .RNH to .HLP action: $(RNH)$(HLP) : $(RUNOFF)$(RFLAGS) $(MMS$SOURCE) @ DEFINE TEC$INIT "EB$(MMS$TARGET)<ESC>K<ESC>EGPURGEE $(MMS$TARGET)<ESC><ESC>" @ EDITT/TECO/COMMAND The <ESC> is, of course, an actual ESCAPE (%x1B) character. Unfortunately, I already tried it in RSX, and failed, since the whole file appears as just one big line, and Teco on RSX refuse to touch it. Maybe I should teach Teco a new trick - how to read weird stream format files... Yeah, if you lost the actual format coming from VMS (likely, since RSX doesn't have provision for STREAM_CR), then TECO isn't going to fix it up because it will not know where the record boundaries exist. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.