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

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