HECnet

hecnet@lists.dfupdate.se

6 participants
15562 discussions

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

12 years, 5 months

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

12 years, 5 months

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

12 years, 5 months

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

12 years, 5 months

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

by system＠TMESIS.COM

Johnny Billquist <bqt at softjar.se> writes: 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? I can't see the file in question as I've not yet gotten my network onto HECnet. If you can make a VMS BACKUP of the file and make it available for download (ftp, sftp, http), I'll determine what's going on with it. (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. 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! -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 5 months

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

by hvlems＠zonnet.nl

Johnny, what happens if you feed the file to EDT ? ------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

12 years, 5 months

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

by bob＠jfcl.com

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. Bob

12 years, 5 months

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

by bqt＠softjar.se

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

12 years, 5 months

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

by sampsa＠mac.com

On 31 Dec 2012, at 18:19, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote: El 31/12/2012, a les 17:16, Johnny Billquist <bqt at softjar.se> va escriure: 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... I think the "classic" Mac OS (pre-OSX) used that format. I think you're right, when I got my Powerbook G4 (Panther-era) in 2004 and Classic was still around, that used to bork a lot of things between OS X and Classic apps...

12 years, 5 months

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

by system＠TMESIS.COM

"Bob Armstrong" <bob at jfcl.com> writes: Looking more at this, I'm curious what Bob did. It might be that the file were created on Windows. 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. Sorry for the delay, but I only read about 1/10th of the traffic on this list these days. Is it just RSX that has issues with this format? 'Tis my best educated guess having seen it all too often since the advent of > _M_iscreant _I_diot _C_oding _R_ejects _O_utputting _S_pecious _O_ften _F_lawed _T_echnology WEENDOZE. In any event, I can promise that Windows had nothing to do with it. Sorry to disappoint you :-) No disappointment in me. It's always something pleasurable when WEENDOZE is NOT involved. ;) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet