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

[Johnny Billquist]

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

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.

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

	Johnny