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

[Johnny Billquist]

On 2012-12-31 15:54, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:

On 2012-12-31 14:59, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:

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.

Basically a superset of that I have in RSX, yes.
The ones "missing" are Stream_LF and Stream_CR.

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.

True. But Windows use CR+LF to terminate lines. That is what Stream deals with anyway, and that is a format used by plenty of other OSes as well.
Stream_CR is something I can't remember seeing anywhere in the wild.
Maybe something like Wang used something like that, or DG. I think one or the other might have been using pure CR terminated lines in files...

(Well, and RSX did continue to be developed into the 90s...)

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.

I tried transfer the file in block mode, which should not mess with anything, and it still had only linefeeds.

Bob later responded that he used Emacs natively on VMS. So I'd say that VMS creates broken files. They should be Stream_LF, and not Stream_CR, based on their contents. RMS under VMS is forgiving enough to actually let you get away for the most part with this brokenness.

But I totally stand by my claim that this is broken. :-)

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.

In a way, no. Since TECO honestly couldn't care less about formats anyway, it should be fine.
At the worst, I should just have a buffer with all the text separated by simple LFs.
Unfortunately, TECO under RSX don't appreciate Stream files at all, since TECO don't even use RMS. TECO uses FCS, and FCS don't have a stream format at all. But it would be easy to fix TECO. I'm going to do that as soon as I have a few minutes over.

	Johnny