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

[Bob Armstrong]

I'm not convinced that a '$ CONVERT/FDL="record; format stream_lf"' 
would handle that file's contents correctly.

I'm pretty sure it will. Bob, could you try?

  Yes, CONVERT on VMS is perfectly happy to convert the original file.
FWIW, that's how I created the "conventional" variable record length version
that RSX likes too.

  And FWIW, on VMS even EDT has no issues editing the original file.   

  And also, ANALYZE/RMS finds no errors in the original file's format or
contents.

  DUMP/RECORD on the original file shows this

Dump of file SYS$SPECIFIC:[FAL$SERVER]INFO.TXT;1 on 31-DEC-2012 09:58:05.44
File ID (2388,686,0)     End of file block 8 / Allocated 35

Record number 1 (00000001), 31 (001F) bytes, RFA(0001,0000,0000)

20532745 45424544 20444E41 20424F42 BOB AND DEBEE'S   000000
    454741 52414720 52455455 504D4F43 COMPUTER GARAGE. 000010

Record number 2 (00000002), 31 (001F) bytes, RFA(0001,0000,0020)

2D2D2D2D 2D2D2D2D 2D2D2D2D 2D2D2D2D ---------------- 000000
    2D2D2D 2D2D2D2D 2D2D2D2D 2D2D2D2D ---------------. 000010

Record number 3 (00000003), 0 (0000) bytes, RFA(0001,0000,0040)


Record number 4 (00000004), 79 (004F) bytes, RFA(0001,0000,0041)

6F6E2065 68742073 69207369 68542020     This is the no 000000
65727275 63202C4F 54414745 4C206564 de LEGATO, curre 000010
6F697461 74735841 56206120 796C746E ntly a VAXstatio 000020
696E6E75 7220434C 562F3030 30342D6E n-4000/VLC runni 000030
    6E6920 2C312E37 20534D56 4F20676E ng OVMS 7.1, in. 000040

Record number 5 (00000005), 78 (004E) bytes, RFA(0001,0000,0091)

20732765 65626544 20646E61 20626F42 Bob and Debee's   000000
20656761 72614720 72657475 706D6F43 Computer Garage   000010
4820746E 656D6572 69746552 20646E61 and Retirement H 000020
20434544 20646C6F 20726F66 20656D6F ome for old DEC   000030
        7449 20202E73 72657475 706D6F63 computers.   It.. 000040

  ... which doesn't show any extra LFs or CRs in the file, but I guess that
doesn't prove anything if you believe that RMS is silently eating them.
Although, ... you can see from the RFAs that there's only one "overhead"
byte between the records, so whatever the end of record character is,
there's only one.   

  I thought there was a way to get DUMP to dump the raw blocks in the file
and bypass RMS completely, but I can't find it anymore.

  As I remember, on RSX it's fairly easy to bypass RMS and read the raw
blocks in a file.   In fact, RMS is technically optional on RSX, so it's not
uncommon to do so.   On VMS, however, RMS is always there and it's not that
easy to read a file without it. Vaxman can tell me if I'm wrong, but I think
you have to resort to logical I/O in order to bypass RMS, which would
require LOG_IO privilege.   The default DECnet account doesn't have that, so
I'm not sure how the FALSERVER would even be sending raw blocks from the
file to RSX.

Bob