HECnet

hecnet@lists.dfupdate.se

5 participants
15588 discussions

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

by bob＠jfcl.com

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

13 years

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

by hvlems＠zonnet.nl

Thanks for trying Johnny! -----Original Message----- From: Johnny Billquist <bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 31 Dec 2012 18:02:41 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SE Cc: <hvlems at zonnet.nl> Subject: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems On 2012-12-31 17:56, hvlems at zonnet.nl wrote: Yes, I meant the original. Did you try it or predict the outcome? Just predicted. But here you go: ..nft x.y=legato::info.txt;1 .dsp x.y DU4:[DECNET]X.Y;1 Size: 8./35. Created: 31-DEC-2012 17:58 Owner: [007,014] Revised: 31-DEC-2012 17:58 File ID: (124,21,0) Expires: <none_specified> File protection: System:RWED, Owner:RWED, Group:R, World:R File organization: Sequential File attributes: Allocation=35, Extend=0 Record format: Stream, no maximum defined Record attributes: Carriage return ..edt x.y Input file could not be opened File name:DU4:[DECNET]X.Y;1 IE.BTP - Bad record type EDT don't understand Stream either. Very few tools in RSX do, since most things use FCS, and FCS don't have the stream format. It's only RMS that do. In order to get it manageable in RSX, I do: ..nft x.y=legato::info.txt;1/as .dsp x.y DU4:[DECNET]X.Y;2 Size: 8./8. Created: 31-DEC-2012 18:01 Owner: [007,014] Revised: 31-DEC-2012 18:01 File ID: (126,7,0) Expires: <none_specified> File protection: System:RWED, Owner:RWED, Group:R, World:R File organization: Sequential File attributes: Allocation=8, Extend=0 Record format: Variable length, no maximum defined Record attributes: Carriage return And then I can edit it, or play with it in any form. However, each line ends with a LF. Johnny -----Original Message----- From: Johnny Billquist <bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 31 Dec 2012 17:52:55 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SE Cc: <hvlems at zonnet.nl> Subject: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems On 2012-12-31 17:46, hvlems at zonnet.nl wrote: Johnny, what happens if you feed the file to EDT ? You mean the original, Stream_CR file? EDT will be totally unimpressed, and refuse. Johnny ------Origineel bericht------ Van: Johnny Billquist Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Cc: Brian Schenkenberger, VAXman- Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems Verzonden: 31 december 2012 17:39 On 2012-12-31 17:20, Brian Schenkenberger, VAXman- wrote: "Bob Armstrong" <bob at jfcl.com> writes: It's been a few years since I edited that file, but there's about a 95% probability that it was created and edited with Gnu EMACS for VMS. The only other possibilities are EDT or EVE, and I'm pretty sure those both create VFC text files rather than stream. Looking around at other stuff that I've edited with EMACS on LEGATO, I see that they also have similar record formats. I've never had a problem using text files that I edited with EMACS with any VMS utility, so I'm not sure why you've got issues. VMS can process of of the RMS file formats is support. It would appear that this one format is one that RSX does not. I think that VMS is lying to itself in this case, and VMS is buying it. A file with Stream_CR, and not a single CR in the file... What would you expect the result to be? (Or rather, Emacs is lying to VMS, and VMS is buying it.) However, when feeding that file over DECnet, the result looks ugly, so the FAL in VMS isn't totally falling for the lie. :-) Johnny

13 years

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

by bqt＠softjar.se

On 2012-12-31 17:59, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 17:42, Bob Armstrong wrote: But I totally stand by my claim that this is broken. :-) Well, since VMS and VMS RMS have no problems with this file, it's arguable about which end is "broken" ... However, I have converted this file to a more conventional format for the lesser-abled operating systems out there :-) Try it again. Looks pretty now. Yeah, VMS have no problems with it. VMS is somewhat forgiving internally when parsing that file, it would appear. But you got to admit that Stream_CR on a file with not a single CR in it smells broken. I doubt that is the case. You didn't see it on your side after copying it but, at that point, the file was probably hopelessly horked by RSX. I did a transfer in block mode, where each block in VMS gets transferred to RSX without any processing at all. No record transfer, but block transfer. Simple disk blocks. And then I just dumped the file contents... When the file was served with FAL to my RSX system, I just ended up with an extra LF per line, which is totally understandable, as there is an LF between each line in your file. The most interesting detail was that the LF was still interpreted as a record terminator, even though the format was Stream_CR. But the LF was not stripped off, which seems reasonable. I bet had you just changed the attribute to Stream_LF, it would have worked just fine as well. 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? But even in original, it was just a slight eyebrow-raiser to get the extra LFs in there. But they were probably free-of-charge! :) Almost. LFs are cheap. :-) Johnny

13 years

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

by bqt＠softjar.se

On 2012-12-31 17:56, hvlems at zonnet.nl wrote: Yes, I meant the original. Did you try it or predict the outcome? Just predicted. But here you go: .nft x.y=legato::info.txt;1 .dsp x.y DU4:[DECNET]X.Y;1 Size: 8./35. Created: 31-DEC-2012 17:58 Owner: [007,014] Revised: 31-DEC-2012 17:58 File ID: (124,21,0) Expires: <none_specified> File protection: System:RWED, Owner:RWED, Group:R, World:R File organization: Sequential File attributes: Allocation=35, Extend=0 Record format: Stream, no maximum defined Record attributes: Carriage return .edt x.y Input file could not be opened File name:DU4:[DECNET]X.Y;1 IE.BTP - Bad record type EDT don't understand Stream either. Very few tools in RSX do, since most things use FCS, and FCS don't have the stream format. It's only RMS that do. In order to get it manageable in RSX, I do: .nft x.y=legato::info.txt;1/as .dsp x.y DU4:[DECNET]X.Y;2 Size: 8./8. Created: 31-DEC-2012 18:01 Owner: [007,014] Revised: 31-DEC-2012 18:01 File ID: (126,7,0) Expires: <none_specified> File protection: System:RWED, Owner:RWED, Group:R, World:R File organization: Sequential File attributes: Allocation=8, Extend=0 Record format: Variable length, no maximum defined Record attributes: Carriage return And then I can edit it, or play with it in any form. However, each line ends with a LF. Johnny -----Original Message----- From: Johnny Billquist <bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 31 Dec 2012 17:52:55 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SE Cc: <hvlems at zonnet.nl> Subject: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems On 2012-12-31 17:46, hvlems at zonnet.nl wrote: Johnny, what happens if you feed the file to EDT ? You mean the original, Stream_CR file? EDT will be totally unimpressed, and refuse. Johnny ------Origineel bericht------ Van: Johnny Billquist Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Cc: Brian Schenkenberger, VAXman- Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems Verzonden: 31 december 2012 17:39 On 2012-12-31 17:20, Brian Schenkenberger, VAXman- wrote: "Bob Armstrong" <bob at jfcl.com> writes: It's been a few years since I edited that file, but there's about a 95% probability that it was created and edited with Gnu EMACS for VMS. The only other possibilities are EDT or EVE, and I'm pretty sure those both create VFC text files rather than stream. Looking around at other stuff that I've edited with EMACS on LEGATO, I see that they also have similar record formats. I've never had a problem using text files that I edited with EMACS with any VMS utility, so I'm not sure why you've got issues. VMS can process of of the RMS file formats is support. It would appear that this one format is one that RSX does not. I think that VMS is lying to itself in this case, and VMS is buying it. A file with Stream_CR, and not a single CR in the file... What would you expect the result to be? (Or rather, Emacs is lying to VMS, and VMS is buying it.) However, when feeding that file over DECnet, the result looks ugly, so the FAL in VMS isn't totally falling for the lie. :-) Johnny

13 years

SIMH performance on OS X vs Linux

by jg＠jordi.guillaumes.name

El 31/12/2012, a les 16:01, Clem Cole <clemc at ccc.com> va escriure: For this reason, besides making sure the HW is that I would standardize the compiler if you can. FYI: The Intel C/C++ compiler for both Linux and OS X are the same compiler, although sometimes slightly different libraries. Tends to be a better Apples to Apples test than GCC because of some of the variations introduced into gcc by different players (plus Apple is moving away from gcc to LLVM due the silliness caused the GPL restrictions). Hmmm if I'm not mistaken, nowadays MacOS defaults to use the clang compiler... Anyway that does not justify that performance difference. On the other hand, MacOS scheduler favors heavily the desktop tasks... Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES

13 years

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

by system＠TMESIS.COM

Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 17:42, Bob Armstrong wrote: But I totally stand by my claim that this is broken. :-) Well, since VMS and VMS RMS have no problems with this file, it's arguable about which end is "broken" ... However, I have converted this file to a more conventional format for the lesser-abled operating systems out there :-) Try it again. Looks pretty now. Yeah, VMS have no problems with it. VMS is somewhat forgiving internally when parsing that file, it would appear. But you got to admit that Stream_CR on a file with not a single CR in it smells broken. I doubt that is the case. You didn't see it on your side after copying it but, at that point, the file was probably hopelessly horked by RSX. When the file was served with FAL to my RSX system, I just ended up with an extra LF per line, which is totally understandable, as there is an LF between each line in your file. The most interesting detail was that the LF was still interpreted as a record terminator, even though the format was Stream_CR. But the LF was not stripped off, which seems reasonable. I bet had you just changed the attribute to Stream_LF, it would have worked just fine as well. I'm not convinced that a '$ CONVERT/FDL="record; format stream_lf"' would handle that file's contents correctly. But even in original, it was just a slight eyebrow-raiser to get the extra LFs in there. But they were probably free-of-charge! :) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

13 years

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

by bqt＠softjar.se

On 2012-12-31 17:50, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: (Or rather, Emacs is lying to VMS, and VMS is buying it.) The Emacs for VMS post is ancient (neolithic) history. Who knows what's being told to the file system when a file is created, updated and closed. Yeah. And I think therein lies the lie. However, when feeding that file over DECnet, the result looks ugly, so the FAL in VMS isn't totally falling for the lie. :-) FAL will open the file based upon the file attributes of the file and it will then attempt to digest it with those file attributes to transfer it over the wire. Without a corresponding set of file attributes on RSX, it is possible that it's RSX that is choking. Try logging into the VMS box which has this file and dump it: $ DUMP/RECORD <the-file>/OUTPUT=THE_FILE_RCD.DMP $ DUMP/BLOCKS <the-file>/OUTPUT=THE_FILE_RAW.DMP ...and then, make it available here so that I can see its layout. I DO not believe that VMS RMS "lies"; especially, after four years of work in it! I should point out that it worked just fine transfer the file to RSX. What happened was just that each line had an LF at the end, and then of course each line has the Carriage return attribute. So, typing the file in RSX, I see it just fine, but with an extra LF at each line. Totally expected, based on what existed in the file. So, RSX didn't choke. It got the file, with linefeeds. However, if I transfered the file using block mode, which shoudn't touch anything inside, I can see that the "original" file, as far as I can tell, really is the text, separated by just LF for each line. So obviously, when VMS serves the file, it considers the LF to be record separators, even though the file is Stream_CR. And it's not stripping the LF away when transferring. This all sounds very reasonable, with the possible exception of how VMS reads out records from a Stream_CR file. If Bob could do dumps of the original file, it would be cool to look at to just confirm what I'm writing. Johnny

13 years

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

by hvlems＠zonnet.nl

Yes, I meant the original. Did you try it or predict the outcome? -----Original Message----- From: Johnny Billquist <bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 31 Dec 2012 17:52:55 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SE Cc: <hvlems at zonnet.nl> Subject: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems On 2012-12-31 17:46, hvlems at zonnet.nl wrote: Johnny, what happens if you feed the file to EDT ? You mean the original, Stream_CR file? EDT will be totally unimpressed, and refuse. Johnny ------Origineel bericht------ Van: Johnny Billquist Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Cc: Brian Schenkenberger, VAXman- Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems Verzonden: 31 december 2012 17:39 On 2012-12-31 17:20, Brian Schenkenberger, VAXman- wrote: "Bob Armstrong" <bob at jfcl.com> writes: It's been a few years since I edited that file, but there's about a 95% probability that it was created and edited with Gnu EMACS for VMS. The only other possibilities are EDT or EVE, and I'm pretty sure those both create VFC text files rather than stream. Looking around at other stuff that I've edited with EMACS on LEGATO, I see that they also have similar record formats. I've never had a problem using text files that I edited with EMACS with any VMS utility, so I'm not sure why you've got issues. VMS can process of of the RMS file formats is support. It would appear that this one format is one that RSX does not. I think that VMS is lying to itself in this case, and VMS is buying it. A file with Stream_CR, and not a single CR in the file... What would you expect the result to be? (Or rather, Emacs is lying to VMS, and VMS is buying it.) However, when feeding that file over DECnet, the result looks ugly, so the FAL in VMS isn't totally falling for the lie. :-) Johnny

13 years

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

by bqt＠softjar.se

On 2012-12-31 17:46, hvlems at zonnet.nl wrote: Johnny, what happens if you feed the file to EDT ? You mean the original, Stream_CR file? EDT will be totally unimpressed, and refuse. Johnny ------Origineel bericht------ Van: Johnny Billquist Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Cc: Brian Schenkenberger, VAXman- Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems Verzonden: 31 december 2012 17:39 On 2012-12-31 17:20, Brian Schenkenberger, VAXman- wrote: "Bob Armstrong" <bob at jfcl.com> writes: It's been a few years since I edited that file, but there's about a 95% probability that it was created and edited with Gnu EMACS for VMS. The only other possibilities are EDT or EVE, and I'm pretty sure those both create VFC text files rather than stream. Looking around at other stuff that I've edited with EMACS on LEGATO, I see that they also have similar record formats. I've never had a problem using text files that I edited with EMACS with any VMS utility, so I'm not sure why you've got issues. VMS can process of of the RMS file formats is support. It would appear that this one format is one that RSX does not. I think that VMS is lying to itself in this case, and VMS is buying it. A file with Stream_CR, and not a single CR in the file... What would you expect the result to be? (Or rather, Emacs is lying to VMS, and VMS is buying it.) However, when feeding that file over DECnet, the result looks ugly, so the FAL in VMS isn't totally falling for the lie. :-) Johnny

13 years

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

by bqt＠softjar.se

On 2012-12-31 17:42, Bob Armstrong wrote: But I totally stand by my claim that this is broken. :-) Well, since VMS and VMS RMS have no problems with this file, it's arguable about which end is "broken" ... However, I have converted this file to a more conventional format for the lesser-abled operating systems out there :-) Try it again. Looks pretty now. Yeah, VMS have no problems with it. VMS is somewhat forgiving internally when parsing that file, it would appear. But you got to admit that Stream_CR on a file with not a single CR in it smells broken. When the file was served with FAL to my RSX system, I just ended up with an extra LF per line, which is totally understandable, as there is an LF between each line in your file. The most interesting detail was that the LF was still interpreted as a record terminator, even though the format was Stream_CR. But the LF was not stripped off, which seems reasonable. I bet had you just changed the attribute to Stream_LF, it would have worked just fine as well. But even in original, it was just a slight eyebrow-raiser to get the extra LFs in there. Johnny

13 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet