HECnet

hecnet@lists.dfupdate.se

1 participants
15560 discussions

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

by bob＠jfcl.com

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. 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 :-) Bo

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 17:06, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote: If there is some "parser" handling these INFO files, I'd suspect that it is manifest in the parser or where the parsing is performed. If it were me, I'd use the VMS finite state parser to handle the parsing on VMS. A simple VAR format would appease VMS and RSX and, I'd wager, all other DEC OSs. The info files are text because they are easy to create (free form text + parseable bit) and are used by web services like http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com My "parser" (20-30 lines of Python) downloads the data for the node, strips out everything but the free form text and creates a HELP section out of it. sampsa

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: On 2012-12-31 15:14, Johnny Billquist wrote: On 2012-12-31 14:59, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 08:08, sampsa at mac.com wrote: 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.) 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. Looking more at this, I'm curious what Bob did. It might be that the file were created on Windows. '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. However, transferred to VMS, the file do not have a a single CR, but do have plenty of LF. That smells very much like Unix. But the record format is broken. It should be Stream_LF. Funnily enough, VMS seems to think that the LF still a delimiter for the record, but it is not stripped out. Reading the file from RSX, this means I get an additional LF for each record read. I wonder why that don't happen in VMS... (This is obvious if you look at the web service on MIM compared to RHESUS.) So, end result in RSX: I read each record. Each record ends with an LF. And then the record format implies a CR+LF as well. I think I've ruled out and transfer mangling by now. The file really only have LFs in there, apart from the text. I would have expected VMS to perhaps not consider the file to be more than one record, since there is no CR, but it then appears that Stream, Stream_CR and Stream_LF only differs on what they strip out, not in what they consider to be record separators. I learned something new today. Stream in RSX is more than enough for me, so I won't ever worry about the special variants of stream that VMS have anymore. :-) I think fugly is an appropriate word, Brian. :-) If there is some "parser" handling these INFO files, I'd suspect that it is manifest in the parser or where the parsing is performed. If it were me, I'd use the VMS finite state parser to handle the parsing on VMS. A simple VAR format would appease VMS and RSX and, I'd wager, all other DEC OSs. -- 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

SIMH performance on OS X vs Linux

by sampsa＠mac.com

On 31 Dec 2012, at 17:01, Clem Cole <clemc at ccc.com> wrote: Interesting indeed. Lots of variables here so something is different. Assume same HW and not running a VM under the covers etc... which compiler did you use and what memory model when you built SIMH. Are all the same optimizations turned on? If different HW, could be a SW emulation of HW instruction optimizations not available on the other CPU implementation. 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). [Non-Commerical download can be obtained at: http://software.intel.com/en-us/non-commercial-software-development These are the product bits, but has a free license key - nothing is restricted - just be honest when you sign up]. I'm not sure if we have a free download.about that Mac OS X compiler - I'll try to ask the product manager when she/he gets back after the new year. Anyway - with identical HW, a 64 bit model, using the same compiler with same optimizations for the CPU, I would expect very similar performance with some places were OS X to be slightly and Linux in a few others. In the case of SIMH on a laptop system, my expectation would be that OS X and its I/O system would have a same advantage over Linux on a same HW. Something sounds very messy if its off by a factor of 2. Clem The point is that it's on the same HW, just in a VM running Linux. Go figure, just thought it was interesting, I don't really have time to properly investigate this right now :) It has to be either the OS or the compiler, my guess is the compiler. Sampsa

12 years, 5 months

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

by bob＠jfcl.com

Funny thing about LEGATO's INFO.TXT - my parser looks for the .BEGIN-HECNET-INFO tag and deletes all text after that. I must have missed something - what's the funny thing? Bob

12 years, 5 months

SIMH performance on OS X vs Linux

by clemc＠ccc.com

Interesting indeed. Lots of variables here so something is different. Assume same HW and not running a VM under the covers etc... which compiler did you use and what memory model when you built SIMH. Are all the same optimizations turned on? If different HW, could be a SW emulation of HW instruction optimizations not available on the other CPU implementation. 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). [Non-Commerical download can be obtained at: http://software.intel.com/en-us/non-commercial-software-development These are the product bits, but has a free license key - nothing is restricted - just be honest when you sign up]. I'm not sure if we have a free download.about that Mac OS X compiler - I'll try to ask the product manager when she/he gets back after the new year. Anyway - with identical HW, a 64 bit model, using the same compiler with same optimizations for the CPU, I would expect very similar performance with some places were OS X to be slightly and Linux in a few others. In the case of SIMH on a laptop system, my expectation would be that OS X and its I/O system would have a same advantage over Linux on a same HW. Something sounds very messy if its off by a factor of 2. Clem On Mon, Dec 31, 2012 at 8:26 AM, <sampsa at mac.com> wrote: I noticed that Linux SIMH is about twice as fast on OS X. KUHAVX got about 12 VUPS when running natively on a Core i5 iMac, 24 when in a Linux VM on the same hardware. Pretty weird. sampsa

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: On 2012-12-31 14:59, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 08:08, sampsa at mac.com wrote: Funny thing about LEGATO's INFO.TXT - my parser looks for the .BEGIN-HECNET-INFO tag and deletes all text after that. I should probably make a manual HLP file for LEGATO, Bob you OK with that? 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. 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. 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. This is fugly. On VMS, I would typically read a file like this into TECO and then, EX (exit) to write out a new file that will have typical VMS RMS file attributes. $ EDITT/TECO <the-file> *EX$$ <-- the $ is echoed by TECO when entring an escape $ (ie. escape => CTRL-[) How wonderful to see someone else but me use Teco. Yes, this is a pretty useful property of Teco. It "fixes" weird files... TECO appears prominently in my DESCRIP.MMS rules for things like RUNOFF used to process sources such as .RNH (RuNoff Help files). RUNOFF takes .RNH files and formats a .HLP file, but it will leave <CR><LF> in these target stains which I hate to see when I need to check for errors in the formatting. So, there's a rule after the .SUFFIXES definitions for the .RNH to .HLP action: $(RNH)$(HLP) : $(RUNOFF)$(RFLAGS) $(MMS$SOURCE) @ DEFINE TEC$INIT "EB$(MMS$TARGET)<ESC>K<ESC>EGPURGEE $(MMS$TARGET)<ESC><ESC>" @ EDITT/TECO/COMMAND The <ESC> is, of course, an actual ESCAPE (%x1B) character. 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. -- 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 sampsa＠mac.com

On 31 Dec 2012, at 16:36, Johnny Billquist <bqt at softjar.se> wrote: But the record format is broken. It should be Stream_LF. Funnily enough, VMS seems to think that the LF still a delimiter for the record, but it is not stripped out. Reading the file from RSX, this means I get an additional LF for each record read. I wonder why that don't happen in VMS... (This is obvious if you look at the web service on MIM compared to RHESUS.) So maybe this is why when it was HLP formatted it broke my parser... Hmmm...Must test this later. Sampsa

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:14, Johnny Billquist wrote: On 2012-12-31 14:59, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 08:08, sampsa at mac.com wrote: 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.) 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. Looking more at this, I'm curious what Bob did. It might be that the file were created on Windows. However, transferred to VMS, the file do not have a a single CR, but do have plenty of LF. That smells very much like Unix. But the record format is broken. It should be Stream_LF. Funnily enough, VMS seems to think that the LF still a delimiter for the record, but it is not stripped out. Reading the file from RSX, this means I get an additional LF for each record read. I wonder why that don't happen in VMS... (This is obvious if you look at the web service on MIM compared to RHESUS.) So, end result in RSX: I read each record. Each record ends with an LF. And then the record format implies a CR+LF as well. I think I've ruled out and transfer mangling by now. The file really only have LFs in there, apart from the text. I would have expected VMS to perhaps not consider the file to be more than one record, since there is no CR, but it then appears that Stream, Stream_CR and Stream_LF only differs on what they strip out, not in what they consider to be record separators. I learned something new today. Stream in RSX is more than enough for me, so I won't ever worry about the special variants of stream that VMS have anymore. :-) I think fugly is an appropriate word, Brian. :-) 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 14:59, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 08:08, sampsa at mac.com wrote: Funny thing about LEGATO's INFO.TXT - my parser looks for the .BEGIN-HECNET-INFO tag and deletes all text after that. I should probably make a manual HLP file for LEGATO, Bob you OK with that? 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... 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.) 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. This is fugly. On VMS, I would typically read a file like this into TECO and then, EX (exit) to write out a new file that will have typical VMS RMS file attributes. $ EDITT/TECO <the-file> *EX$$ <-- the $ is echoed by TECO when entring an escape $ (ie. escape => CTRL-[) How wonderful to see someone else but me use Teco. Yes, this is a pretty useful property of Teco. It "fixes" weird files... 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... 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