HECnet

hecnet@lists.dfupdate.se

1 participants
15560 discussions

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

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

by jg＠jordi.guillaumes.name

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.

12 years, 5 months

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

by bqt＠softjar.se

On 2012-12-31 15:54, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 14:59, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: LEGATO's INFO.TXT have real yucky file attributes and a real yucky file format. :-) (What on earth was used to produce it???) Stream_CR typically surfaces with files coming from WEENDOZE. Ah. Yes, that would be a possible, source, I guess. But I find Stream_CR a but surprising. Maybe I'm just too ignorant of VMS formats here. But isn't there a plain Stream as well (which also exists in RSX), in which records are terminated by CR+LF, and which is what I would expect a Windows machine to produce... VMS file formats: FIX ........ Fixed Record Size; Length in MRS VAR ........ Variable; Length embedded in record VFC ........ Variable Format Control; Length and Format embedded in record Stream ..... Stream; Length from scan for <CR><LF> Stream_LF .. Stream; Length from scan for <LF> Stream_CR .. Stream; Length from scan for <CR> UDF ........ Undefinded. Basically a superset of that I have in RSX, yes. The ones "missing" are Stream_LF and Stream_CR. Directory LEGATO::SYS$SPECIFIC:[FAL$SERVER] 31-DEC-12 13:59:07 INFO.TXT;1 Size: 8./35. Created: 08-JUL-10 10:54:52 Owner: [000376,000373] Revised: 27-DEC-12 19:24:34(6.) Expires: <none_specified> File protection: System:RE, Owner:RE, Group:RE, World:RE File organization: Sequential File attributes: Allocation=0 Record format: Stream-CR, no maximum defined Record attributes: Carriage return What does it mean if you have stream-CR and attribute Carriage Return? I mean, yes, each record is separated by a CR, and then what? Add an additional CR at the end of each line? "Record format" refers to the data in the file. Stream_CR means that the records are delineated with a <carriage-return> character. RMS will then populate its internal buffers and the user's buffer upon a $GET with the current record data up to the <carriage-return> character. RMS internal handlers discard this <carriage-return> and update the NRP (Next Record Pointer) leaving it pointing after the <carriage-return> to a subsequent (assuming there is one) record. "Record attributes" refer to how to present the record to the application that performed the $GET to read the record. With "Record attributes" set to "Carriage return", RMS will synthesize a record with <carriage-return> and <line-feed>. If the "Record format" is VFC (Variable Format Control), this synthesis is over-ruled by the format in the VFC header of each and every record. Ah. This do make sense, actually, and matches RSX. (Except there is no Stream_CR, there is only a Stream format.) Perhaps becasue there was no WEENDOZE when RSX was still being developed by d|i|g|i|t|a|l. True. But Windows use CR+LF to terminate lines. That is what Stream deals with anyway, and that is a format used by plenty of other OSes as well. 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... (Well, and RSX did continue to be developed into the 90s...) I obviously did not think enough here. However, the actual contents of the file, as seen if I copy it to RSX, totally belies this, as there aren't a single CR in that whole file. But it might be that things are mangled in the process of the transfer. Very likely. I'd think that these files should be maintained on nodes in a format that is much more easily consumed by RMS and DECnet vis a vis a VAR format file. I tried transfer the file in block mode, which should not mess with anything, and it still had only linefeeds. Bob later responded that he used Emacs natively on VMS. So I'd say that VMS creates broken files. They should be Stream_LF, and not Stream_CR, based on their contents. RMS under VMS is forgiving enough to actually let you get away for the most part with this brokenness. But I totally stand by my claim that this is broken. :-) Unfortunately, I already tried it in RSX, and failed, since the whole file appears as just one big line, and Teco on RSX refuse to touch it. Maybe I should teach Teco a new trick - how to read weird stream format files... Yeah, if you lost the actual format coming from VMS (likely, since RSX doesn't have provision for STREAM_CR), then TECO isn't going to fix it up because it will not know where the record boundaries exist. In a way, no. Since TECO honestly couldn't care less about formats anyway, it should be fine. At the worst, I should just have a buffer with all the text separated by simple LFs. Unfortunately, TECO under RSX don't appreciate Stream files at all, since TECO don't even use RMS. TECO uses FCS, and FCS don't have a stream format at all. But it would be easy to fix TECO. I'm going to do that as soon as I have a few minutes over. Johnny

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