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

[Brian Schenkenberger, VAXman-]

"Bob Armstrong" <bob at jfcl.com> writes: 

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.

Then, it *WAS* a Stream_CR file!


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

OK.   This record is runs from RFA 1,0,0 to 1,0,1E.


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

This record startes at RFA 1,0,20.   Thus, there's a byte amiss.   That'd be
the <CR>.

This record goes from 1,0,20 to 1,0,3E.

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

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

Record 3 starts at 1,0,40.   So, it looks like 1,0,3F is a <CR>.


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.   

Correct.


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.

$ DUMP/BLOCKS

If you do, I'll wager you'll see a 0D at the locations I've indicated.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker       VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.