INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems

Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 15:14, Johnny Billquist wrote: 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: 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.) 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. Looking more at this, I'm curious what Bob did. It might be that the file were created on Windows. 'Tis my best educated guess having seen it all too often since the advent of _M_iscreant _I_diot _C_oding _R_ejects _O_utputting _S_pecious _O_ften _F_lawed _T_echnology WEENDOZE. However, transferred to VMS, the file do not have a a single CR, but do have plenty of LF. That smells very much like Unix. But the record format is broken. It should be Stream_LF. Funnily enough, VMS seems to think that the LF still a delimiter for the record, but it is not stripped out. Reading the file from RSX, this means I get an additional LF for each record read. I wonder why that don't happen in VMS... (This is obvious if you look at the web service on MIM compared to RHESUS.) So, end result in RSX: I read each record. Each record ends with an LF. And then the record format implies a CR+LF as well. I think I've ruled out and transfer mangling by now. The file really only have LFs in there, apart from the text. I would have expected VMS to perhaps not consider the file to be more than one record, since there is no CR, but it then appears that Stream, Stream_CR and Stream_LF only differs on what they strip out, not in what they consider to be record separators. I learned something new today. Stream in RSX is more than enough for me, so I won't ever worry about the special variants of stream that VMS have anymore. :-) I think fugly is an appropriate word, Brian. :-) If there is some "parser" handling these INFO files, I'd suspect that it is manifest in the parser or where the parsing is performed. If it were me, I'd use the VMS finite state parser to handle the parsing on VMS. A simple VAR format would appease VMS and RSX and, I'd wager, all other DEC OSs. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.