- HECnet - lists @ Update

DECnet performance problems (on TOPS-10)

by Paul_Koning＠Dell.com

Rterm for RSTS is pretty simplistic. It works essentially like telnet local echo line mode normally, but it detects a couple of state changes on the controlled terminal: if echo is disabled, the local echo is likewise disabled. And if the terminal driver goes into any kind of mode where line mode no longer works right -- ODT, binary mode, TECO mode, etc. -- it switches to no echo character at a time mode. So, for example, TECO works, but you can tell that it all of a sudden got slower. Hmm. At least better than cterm... :-) But how does it deal with things like XON/XOFF, ^O and stuff? Is that left to the client side to do however it want, so it don't neccesarily work the same as a local terminal to the RSTS/E system? If I remember right, the answer is: on the sending host when in line mode, on the RSTS system when in character mode. Character mode essentially puts the local end in binary mode. paul

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by bqt＠softjar.se

On 2011-09-02 03.01, Paul_Koning at Dell.com wrote: Yes, the goal of Cterm was to be very clever, which is why it looks like an abstraction of the VMS terminal QIO facilities. Or, I think, the union of those and the TOPS-20 terminal I/O facilities. And in spite of that extreme complexity it is really only good for those; it is such a bad fit for, say, RSTS, that the attempt was never made. (It's also a very big protocol, but the bad fit was at least 50% of the reason.) In a way, it is surprising that DEC did cterm this way. After all, it is almost impossible to get things right in every detail for every situation. And cterm rather sucks on RSX as well. It would have been so much nicer to have kept the protocol stupid and allow the host OS to do whatever needed to get things right from its point of view, since only the OS knows the right behavior anyway, and it can change. Also, if cterm would have been stupid, it could have been hooked into the existing terminal drivers, instead of having its own implementation of a driver which tries to mimic all that the normal terminal driver do (atleast on RSX). But I guess DEC thought they wanted to minimize network traffic and avoid latency issues... Oh well. Rterm for RSTS is pretty simplistic. It works essentially like telnet local echo line mode normally, but it detects a couple of state changes on the controlled terminal: if echo is disabled, the local echo is likewise disabled. And if the terminal driver goes into any kind of mode where line mode no longer works right -- ODT, binary mode, TECO mode, etc. -- it switches to no echo character at a time mode. So, for example, TECO works, but you can tell that it all of a sudden got slower. Hmm. At least better than cterm... :-) But how does it deal with things like XON/XOFF, ^O and stuff? Is that left to the client side to do however it want, so it don't neccesarily work the same as a local terminal to the RSTS/E system? Johnny paul -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Thursday, September 01, 2011 7:51 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet performance problems (on TOPS-10) On 2011-09-01 17:25, Bob Armstrong wrote: TOPS-10 and RSTS (and RT-11) echo the keystrokes as they occur, while RSX and VMS echo when the read occurs. Ah, I never thought about it before, but that's very profound and clearly true. And easily demonstrated too - do some command on VMS that takes a minute to execute, and then type ahead. You won't see anything echoed. On TOPS10 in the same circumstance, you will. I don't remember offhand how TOPS20 behaved (it's been too many years ago). A short experiment on TOPS-20 suggest that it only echoes once the character is actually read, which also would make sense since things would become rather weird and fouled up with completion, character recognition and so on in TOPS-20 if echo didn't take place at the right place and time. What a character actually will do depends on the context in TOPS-20. But it was a simple test, and I might just have failed to cause enough of a delay... And the same is somewhat true in RSX and VMS as well (well, it's actually true in any OS, but most don't take it into consideration). As Paul also mentioned, the echoing of a newline is different in RSX than RSTS/E. Technically, this is not related to input at all, but only output. Whenever a CR+LF is output in RSX, the LF is surpressed until the next character is written, and only output when something else needs to be printed. The same is actually also true in VMS. However, this behavior is depending on you using the terminal drivers own newline processing function. If you just output the CF and LF characters in your text stream, the LF will not be surpressed. Another point is the character-at-a-time mode. I don't know exactly how rterm (or whatever) does this, but it's not really comparably to telnet. There is no "raw" mode in telnet (I only finished implementing my telnet client for RSX last week, so right now all the details are very fresh in my head :-) ). However, it is probably fair to say that TOPS-20 in general reads each single character, and not a line at a time. So any terminal protocol needs to do the same for things to work right. In telnet, the most relevant part here is the echoing function, where you, for interactive sessions, normally have remote echo turned on. With local echo, you normally do a line at a time in telnet, but there is really no difference between doing line at a time and character at a time from the telnet protocol point of view. However, interactive users would not be impressed if you have remote echo, and only send the characters when you have entered a whole line (obviously). If you want to do the same as TOPS-20 in Unix, however, you will turn on "raw" mode in Unix. :-) Speaking of rterm by the way, I don't know much about it (obviously), but either it got to be a very clever protocol, or else it works the same as telnet with remote echo. If it's clever, then it needs not only be able to handle if you want to input without echoing, but also if you want binary reads (no terminators), special terminators, special keys meaning special functions, and god knows what else. I think CTERM atleast tries to be clever here, which is why it is such a mess. Notice how VMS line editing partially works when doing SET HOST to a non-VMS system. Ugh! Johnny

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by Paul_Koning＠Dell.com

Yes, the goal of Cterm was to be very clever, which is why it looks like an abstraction of the VMS terminal QIO facilities. Or, I think, the union of those and the TOPS-20 terminal I/O facilities. And in spite of that extreme complexity it is really only good for those; it is such a bad fit for, say, RSTS, that the attempt was never made. (It's also a very big protocol, but the bad fit was at least 50% of the reason.) Rterm for RSTS is pretty simplistic. It works essentially like telnet local echo line mode normally, but it detects a couple of state changes on the controlled terminal: if echo is disabled, the local echo is likewise disabled. And if the terminal driver goes into any kind of mode where line mode no longer works right -- ODT, binary mode, TECO mode, etc. -- it switches to no echo character at a time mode. So, for example, TECO works, but you can tell that it all of a sudden got slower. paul -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Thursday, September 01, 2011 7:51 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet performance problems (on TOPS-10) On 2011-09-01 17:25, Bob Armstrong wrote: TOPS-10 and RSTS (and RT-11) echo the keystrokes as they occur, while RSX and VMS echo when the read occurs. Ah, I never thought about it before, but that's very profound and clearly true. And easily demonstrated too - do some command on VMS that takes a minute to execute, and then type ahead. You won't see anything echoed. On TOPS10 in the same circumstance, you will. I don't remember offhand how TOPS20 behaved (it's been too many years ago). A short experiment on TOPS-20 suggest that it only echoes once the character is actually read, which also would make sense since things would become rather weird and fouled up with completion, character recognition and so on in TOPS-20 if echo didn't take place at the right place and time. What a character actually will do depends on the context in TOPS-20. But it was a simple test, and I might just have failed to cause enough of a delay... And the same is somewhat true in RSX and VMS as well (well, it's actually true in any OS, but most don't take it into consideration). As Paul also mentioned, the echoing of a newline is different in RSX than RSTS/E. Technically, this is not related to input at all, but only output. Whenever a CR+LF is output in RSX, the LF is surpressed until the next character is written, and only output when something else needs to be printed. The same is actually also true in VMS. However, this behavior is depending on you using the terminal drivers own newline processing function. If you just output the CF and LF characters in your text stream, the LF will not be surpressed. Another point is the character-at-a-time mode. I don't know exactly how rterm (or whatever) does this, but it's not really comparably to telnet. There is no "raw" mode in telnet (I only finished implementing my telnet client for RSX last week, so right now all the details are very fresh in my head :-) ). However, it is probably fair to say that TOPS-20 in general reads each single character, and not a line at a time. So any terminal protocol needs to do the same for things to work right. In telnet, the most relevant part here is the echoing function, where you, for interactive sessions, normally have remote echo turned on. With local echo, you normally do a line at a time in telnet, but there is really no difference between doing line at a time and character at a time from the telnet protocol point of view. However, interactive users would not be impressed if you have remote echo, and only send the characters when you have entered a whole line (obviously). If you want to do the same as TOPS-20 in Unix, however, you will turn on "raw" mode in Unix. :-) Speaking of rterm by the way, I don't know much about it (obviously), but either it got to be a very clever protocol, or else it works the same as telnet with remote echo. If it's clever, then it needs not only be able to handle if you want to input without echoing, but also if you want binary reads (no terminators), special terminators, special keys meaning special functions, and god knows what else. I think CTERM atleast tries to be clever here, which is why it is such a mess. Notice how VMS line editing partially works when doing SET HOST to a non-VMS system. Ugh! Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by bqt＠softjar.se

On 2011-09-01 17:25, Bob Armstrong wrote: TOPS-10 and RSTS (and RT-11) echo the keystrokes as they occur, while RSX and VMS echo when the read occurs. Ah, I never thought about it before, but that's very profound and clearly true. And easily demonstrated too - do some command on VMS that takes a minute to execute, and then type ahead. You won't see anything echoed. On TOPS10 in the same circumstance, you will. I don't remember offhand how TOPS20 behaved (it's been too many years ago). A short experiment on TOPS-20 suggest that it only echoes once the character is actually read, which also would make sense since things would become rather weird and fouled up with completion, character recognition and so on in TOPS-20 if echo didn't take place at the right place and time. What a character actually will do depends on the context in TOPS-20. But it was a simple test, and I might just have failed to cause enough of a delay... And the same is somewhat true in RSX and VMS as well (well, it's actually true in any OS, but most don't take it into consideration). As Paul also mentioned, the echoing of a newline is different in RSX than RSTS/E. Technically, this is not related to input at all, but only output. Whenever a CR+LF is output in RSX, the LF is surpressed until the next character is written, and only output when something else needs to be printed. The same is actually also true in VMS. However, this behavior is depending on you using the terminal drivers own newline processing function. If you just output the CF and LF characters in your text stream, the LF will not be surpressed. Another point is the character-at-a-time mode. I don't know exactly how rterm (or whatever) does this, but it's not really comparably to telnet. There is no "raw" mode in telnet (I only finished implementing my telnet client for RSX last week, so right now all the details are very fresh in my head :-) ). However, it is probably fair to say that TOPS-20 in general reads each single character, and not a line at a time. So any terminal protocol needs to do the same for things to work right. In telnet, the most relevant part here is the echoing function, where you, for interactive sessions, normally have remote echo turned on. With local echo, you normally do a line at a time in telnet, but there is really no difference between doing line at a time and character at a time from the telnet protocol point of view. However, interactive users would not be impressed if you have remote echo, and only send the characters when you have entered a whole line (obviously). If you want to do the same as TOPS-20 in Unix, however, you will turn on "raw" mode in Unix. :-) Speaking of rterm by the way, I don't know much about it (obviously), but either it got to be a very clever protocol, or else it works the same as telnet with remote echo. If it's clever, then it needs not only be able to handle if you want to input without echoing, but also if you want binary reads (no terminators), special terminators, special keys meaning special functions, and god knows what else. I think CTERM atleast tries to be clever here, which is why it is such a mess. Notice how VMS line editing partially works when doing SET HOST to a non-VMS system. Ugh! Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by bob＠jfcl.com

TOPS-10 and RSTS (and RT-11) echo the keystrokes as they occur, while RSX and VMS echo when the read occurs. Ah, I never thought about it before, but that's very profound and clearly true. And easily demonstrated too - do some command on VMS that takes a minute to execute, and then type ahead. You won't see anything echoed. On TOPS10 in the same circumstance, you will. I don't remember offhand how TOPS20 behaved (it's been too many years ago). Bob

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by Paul_Koning＠Dell.com

TOPS-10 and RSTS (and RT-11) echo the keystrokes as they occur, while RSX and VMS echo when the read occurs. Also, RSX, if I remember right, echoes <ret> as carriage return, and the line feed occurs at the start of the next input, while RSTS echoes <ret> as CRLF. I think TOPS-20 is like TOPS-10/RSTS, but it's handled differently in Rterm. The reason is that TOPS-20 does a lot with command completion, so its Rterm mode is essentially single character mode (what Telnet would call "raw"). RSTS/TOPS-10 mode gathers a whole line locally then sends that over (unless you're in a screen editor or other application that turns on character at a time mode -- which RSTS calls "ODT mode" because of the debugger that uses it). paul -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong Sent: Thursday, September 01, 2011 11:03 AM To: hecnet at Update.UU.SE Subject: RE: [HECnet] DECnet performance problems (on TOPS-10) but echoes TOPS-10 style (which is also RSTS style) not VMS/RSX style. Ok, I'll bite - what's the difference in echo style between TOPS10/RSTS and VMS/RSX? And which category does TOPS20 belong to? Bob

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by bob＠jfcl.com

but echoes TOPS-10 style (which is also RSTS style) not VMS/RSX style. Ok, I'll bite - what's the difference in echo style between TOPS10/RSTS and VMS/RSX? And which category does TOPS20 belong to? Bob

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by bqt＠softjar.se

And just fyi: in RSX, you have different programs for connecting to different systems, when using "rterm". RMT.TSK is for connecting to RSX systems. RVT.TSK is for connecting to VMS. RRS.TSK is for connecting to RSTS/E. HOST.TSK is for connecting to TOPS-20. Johnny On 2011-09-01 12.47, Paul_Koning at Dell.com wrote: The pre-cterm remote terminal protocol is not actually a single protocol, but rather a set of protocols specific to the destination OS. That's why it works well: instead of trying to fit the OS native terminal behavior into a VMS-centric model as is done in Cterm, the rterm protocols simply express a terminal behavior that matches what the OS wants. The reason Cterm is so bad for TOPS-10 is that there is really nothing that matches -- just for starters, TOPS-10 echoes differently. The reason you may see failure for one destination OS type and not others is that you're going through completely different code, because you have a different rterm flavor. There are four flavors (according to the RSTS code I have that implements them): VMS, RSX, RSTS, and TOPS-20. If I remember right, TOPS-10 uses the RSTS flavor, and RT-11 perhaps does as well. The RSTS flavor is line oriented (as is Cterm) but echoes TOPS-10 style (which is also RSTS style) not VMS/RSX style. The VMS and RSX ones are somewhat like Cterm except that they more closely copy the actual set of I/O operations implemented in the terminal drivers of those two. You can find implementations of several of these in DECnet/Linux -- if you're having trouble with the standard one on VMS, you might be able to lift the Linux one and port it to VMS... paul -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of gerry77 at mail.com Sent: Wednesday, August 31, 2011 10:13 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet performance problems (on TOPS-10) On Wed, 31 Aug 2011 15:18:25 +0200, you wrote: SET HOST from a VMS system implies you use CTERM. CTERM is a horrible protocol, and only really works fine between VMS systems. Using it to connect to anything else usually means you can expect all kind of behavior and performance problems. It might be something else, but I would suspect CTERM as such first and foremost. I think you are quite right: I've just tried a connection using the old RTERM protocol (SET HOST/APP=R) and it works very fine! :-O I'll try anyway to fiddle with a couple of emulator parameters, but... BTW, since here there are many people that run things like RSX and such, I'll take advantage of this message to ask: did you ever had problems using RTERM? I ask this because I've noticed that SET HOST/APP=R on OpenVMS Alpha V8.3 bombs with an ACCVIO whenever I try to connect to RSTS or TOPS-10, but not when I use it with VAX/VMS V4.7 (or OpenVMS V7.2 VAX, for that matter). In other words, I have not so much different versions to try with, but it seems that RTPAD.EXE does not like very old RTERM implementations like ones found in OSes different from VMS, no matter how much vintage it can be. The system showing this problem is not mine, but at a quick check it appears to have every possible patch kit installed. This is the relevant image data: image name: "RTPAD" image file identification: "X-10" image file build identification: "XBC4-0080060000" link date/time: 29-JUN-2006 18:18:54.69 linker identification: "A13-03" And this is the error: %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000517000008AA4, PC=0000517000008AA4, PS=0000001B Improperly handled condition, image exit forced. Signal arguments: Number = 0000000000000005 Name = 000000000000000C 0000000000010000 0000517000008AA4 0000517000008AA4 000000000000001B Register dump: R0 = 0000000000000003 R1 = 0000000000008F50 R2 = 0000000000008134 R3 = 0000000000034804 R4 = 000000007FFCF814 R5 = 0000000000009AEF R6 = 0000000000000000 R7 = 0000000000000001 R8 = 000000000003481B R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18 R12 = 000000007FFCDA98 R13 = 0000000000005170 R14 = 0000000000008E28 R15 = 0000000000008E28 R16 = 0000000002A83089 R17 = 0000000000200000 R18 = FFFFFFFF80903360 R19 = FFFFFFFF820EFA56 R20 = 0000000000000002 R21 = 0000000000000000 R22 = 000000007AD69A54 R23 = FFFFFFFF801877D0 R24 = 0000000000000001 R25 = 0000000000000003 R26 = FFFFFFFF8018780C R27 = 000000007AD69A54 R28 = 0000000000000006 R29 = 000000007AD69A60 SP = 000000007AD69A30 PC = 0000517000008AA4 PS = 300000000000001B Any info about it? Thanks, G.

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by Paul_Koning＠Dell.com

The pre-cterm remote terminal protocol is not actually a single protocol, but rather a set of protocols specific to the destination OS. That's why it works well: instead of trying to fit the OS native terminal behavior into a VMS-centric model as is done in Cterm, the rterm protocols simply express a terminal behavior that matches what the OS wants. The reason Cterm is so bad for TOPS-10 is that there is really nothing that matches -- just for starters, TOPS-10 echoes differently. The reason you may see failure for one destination OS type and not others is that you're going through completely different code, because you have a different rterm flavor. There are four flavors (according to the RSTS code I have that implements them): VMS, RSX, RSTS, and TOPS-20. If I remember right, TOPS-10 uses the RSTS flavor, and RT-11 perhaps does as well. The RSTS flavor is line oriented (as is Cterm) but echoes TOPS-10 style (which is also RSTS style) not VMS/RSX style. The VMS and RSX ones are somewhat like Cterm except that they more closely copy the actual set of I/O operations implemented in the terminal drivers of those two. You can find implementations of several of these in DECnet/Linux -- if you're having trouble with the standard one on VMS, you might be able to lift the Linux one and port it to VMS... paul -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of gerry77 at mail.com Sent: Wednesday, August 31, 2011 10:13 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet performance problems (on TOPS-10) On Wed, 31 Aug 2011 15:18:25 +0200, you wrote: SET HOST from a VMS system implies you use CTERM. CTERM is a horrible protocol, and only really works fine between VMS systems. Using it to connect to anything else usually means you can expect all kind of behavior and performance problems. It might be something else, but I would suspect CTERM as such first and foremost. I think you are quite right: I've just tried a connection using the old RTERM protocol (SET HOST/APP=R) and it works very fine! :-O I'll try anyway to fiddle with a couple of emulator parameters, but... BTW, since here there are many people that run things like RSX and such, I'll take advantage of this message to ask: did you ever had problems using RTERM? I ask this because I've noticed that SET HOST/APP=R on OpenVMS Alpha V8.3 bombs with an ACCVIO whenever I try to connect to RSTS or TOPS-10, but not when I use it with VAX/VMS V4.7 (or OpenVMS V7.2 VAX, for that matter). In other words, I have not so much different versions to try with, but it seems that RTPAD.EXE does not like very old RTERM implementations like ones found in OSes different from VMS, no matter how much vintage it can be. The system showing this problem is not mine, but at a quick check it appears to have every possible patch kit installed. This is the relevant image data: image name: "RTPAD" image file identification: "X-10" image file build identification: "XBC4-0080060000" link date/time: 29-JUN-2006 18:18:54.69 linker identification: "A13-03" And this is the error: %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000517000008AA4, PC=0000517000008AA4, PS=0000001B Improperly handled condition, image exit forced. Signal arguments: Number = 0000000000000005 Name = 000000000000000C 0000000000010000 0000517000008AA4 0000517000008AA4 000000000000001B Register dump: R0 = 0000000000000003 R1 = 0000000000008F50 R2 = 0000000000008134 R3 = 0000000000034804 R4 = 000000007FFCF814 R5 = 0000000000009AEF R6 = 0000000000000000 R7 = 0000000000000001 R8 = 000000000003481B R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18 R12 = 000000007FFCDA98 R13 = 0000000000005170 R14 = 0000000000008E28 R15 = 0000000000008E28 R16 = 0000000002A83089 R17 = 0000000000200000 R18 = FFFFFFFF80903360 R19 = FFFFFFFF820EFA56 R20 = 0000000000000002 R21 = 0000000000000000 R22 = 000000007AD69A54 R23 = FFFFFFFF801877D0 R24 = 0000000000000001 R25 = 0000000000000003 R26 = FFFFFFFF8018780C R27 = 000000007AD69A54 R28 = 0000000000000006 R29 = 000000007AD69A60 SP = 000000007AD69A30 PC = 0000517000008AA4 PS = 300000000000001B Any info about it? Thanks, G.

13 years, 10 months

1
0
0 0

Anyone with a spare MMJ cable + RS232 adapter?

by schwa.phil＠gmail.com

On 11-08-30 05:25 PM, Sampsa Laine wrote: MMJ - MMJ RX, TX, GND 6' (2m) long enough? Qty 4 Done. I actually wired all 6 lines as crossover cables because it was easier. Hack them up at will. Send me a snail-mail address, and I'll give you the total after I pop them in the post tomorrow. How fast a service are you willing to spring for? Phil

13 years, 10 months

1
0
0 0

DECUS archive

by mark＠wickensonline.co.uk

Guys, My AlphaServer 1000A node SLAVE now has the DECUS archive from D I G I A T E R on the FAL$SERVER account, so you can access it directly from SLAVE:: For example: $ dir slave:: Directory SLAVE::DECUS$:[DECUS] 00BVMSLT.DIR;1 01AVMSLT.DIR;1 02AVMSLT.DIR;1 02BVMSLT.DIR;1 03AVMSLT.DIR;1 03BVMSLT.DIR;1 04AVMSLT.DIR;1 04BVMSLT.DIR;1 05AVMSLT.DIR;1 05BVMSLT.DIR;1 06AVMSLT.DIR;1 07AVMSLT.DIR;1 90AVAXLT.DIR;1 91AVAXLT.DIR;1 91BVAXLT.DIR;1 92AVAXLT.DIR;1 92BVAXLT.DIR;1 93AVMSLT.DIR;1 93BVMSLT.DIR;1 94AVMSLT.DIR;1 94BVMSLT.DIR;1 95AVMSLT.DIR;1 96BVMSLT.DIR;1 97AVMSLT.DIR;1 97BVMSLT.DIR;1 98AVMSLT.DIR;1 98BVMSLT.DIR;1 99AVMSLT.DIR;1 99BVMSLT.DIR;1 CIRCUIT_SIMULATOR.DIR;1 DECUSC.DIR;1 DECUSERVE.DIR;1 DECUSLIB.DIR;1 DECUSUTL.DIR;1 DECWINDOWS.DIR;1 EXTRA.DIR;1 FREEWAREV10.DIR;1 FREEWAREV20.DIR;1 FREEWAREV30.DIR;1 FREEWAREV40.DIR;1 FREEWAREV50.DIR;1 FREEWAREV60.DIR;1 FREEWAREV70.DIR;1 FREEWAREV80.DIR;1 INFO-VAX.DIR;1 ISO9660.DIR;1 LT86A.DIR;1 LT87A.DIR;1 LT89A.DIR;1 LT89B1.DIR;1 LT89B2.DIR;1 LT90A.DIR;1 LT90B1.DIR;1 LT90B2.DIR;1 LT91A.DIR;1 LT91B.DIR;1 LT92A.DIR;1 LT92B.DIR;1 LT93A.DIR;1 LT93B.DIR;1 LT94A.DIR;1 LT94B.DIR;1 LT95A.DIR;1 LT95B.DIR;1 MN.DIR;1 NCSA.DIR;1 NET.DIR;1 PCSI_KITS.DIR;1 PERL.DIR;1 $ dir slave::[.91AVAXLT] Directory SLAVE::DECUS$:[DECUS.91AVAXLT] 000README.TXT;1 0README.ALSO;1 AAAREADME.91A_LT;1 AAAREADME.91A_VAX;1 ABSTRACT.DOC;1 ABSVLT91.TXT;1 BUILDREAD.COM;1 BUILDREADL.COM;1 BUILDREADV.COM;1 CATALOG.DIR;1 COMPRESSIONS.TXT;1 COPYTAPES.COM;1 COPYTREES.COM;1 DECOMPRESS_ALL.COM;1 DEFAULT.EXE;1 DELETE_ALL.COM;1 GRAND_TOTS.COM;1 LOGIN.COM;1 OLD_AAAREADME.DIR;1 OLD_B.COM;1 REVIEWS.DIR;1 SUBMIT.TXT;1 TAPECOPY.HISTORY;1 TCTREE.LIS;1 TCTREEPROC.LIS;1 TEMPLATE.RNO;1 TOOLS.DIR;1 TREE.SEQ;1 TREESIZE.COM;1 TREETAPE.COM;1 VAXLT91ATPE.DOC;1 VLT91A.TXT;1 VLT91A.XREF;1 SLAVE isn't currently on 24/7 - normally I run it from midday to midnight BST, approximately. Feedback welcome! Regards, Mark.

13 years, 10 months

1
0
0 0

Changing console from serial to graphics on AS800 from VMS?

by sampsa＠mac.com

I HAVE a DECserver - 200, with DB25 ports lol :) Sampsa On 31 Aug 2011, at 14:26, Mark Wickens wrote: On 31/08/11 13:54, hvlems at zonnet.nl wrote: The converter from DB9 (PC style) to MMJ is called an H8571-J The -J is very important since other H8571's will do different things. Hans ------Origineel bericht------ Van: Sampsa Laine Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: [HECnet] Changing console from serial to graphics on AS800 from VMS? Verzonden: 31 augustus 2011 14:24 Is it possible to change the OPA0: (on reboot, so it sticks) from serial to graphics on an AS800 through VMS? Sampsa Verzonden vanaf mijn draadloze BlackBerry -toestel Sampsa, consider investing in a DECserver... then you can have all your consoles available over ethernet.

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by hvlems＠zonnet.nl

What I thought was this: all DECnet parameters are set to default values. The other DECnet nodes probably also. Which is good because messing with most parameters won't improve performance. The next step is that DECnet is well implemented across DEC o/s'es. TOPS is no exception to that rule so it's not the first place to start investigating. Though do try alt.sys.pdp10 or alt.sys.folklore. So what remains is the host system. Suspect #1 is pcap. Is the package recent? I can't think of parameters to change here. On linux you might check network security parameters and whether pcap needs tweaking of linux paramters. ------Origineel bericht------ Van: gerry77 at mail.com Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] DECnet performance problems (on TOPS-10) Verzonden: 31 augustus 2011 15:05 On Wed, 31 Aug 2011 06:54:12 +0000, you wrote: The paramters you posted are aal defaults except for the node name aand address, right? Yes. Anyway I tried also with some modified parameters we use on other nodes, namely executor block size and buffer size, but nothing changed. The "problem" is that most of those parameters are "embedded" into the monitor, so to change them the monitor has to be rebuilt every time. Non particularly diffucult, but quite time-consuming. Moreover they have names like %RTBSZ and %DLBSZ, and is not always so easy to discover which NCP/DECnet parameter corresponds to which internal monitor variable... :) - have a look at the exec, line and circuit counters In my previous message I forgot to mention that all the error-related counters are at zero, so I thought not to paste them here. - examine the host IP characteristics and (if present) those of the winpcap package installed on the host Specifically, what characteristics are you thinking about? I have no idea about whatever I could check at host and pcap (on Linux) level. Thanks for your time, :) G. Verzonden vanaf mijn draadloze BlackBerry -toestel

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by hvlems＠zonnet.nl

You have a DECnet key (not a PAK!) for DECnet on a pre V5.0 VMS system, rigjt? ------Origineel bericht------ Van: gerry77 at mail.com Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] DECnet performance problems (on TOPS-10) Verzonden: 31 augustus 2011 15:05 On Wed, 31 Aug 2011 10:58:53 +0200, you wrote: On PDP:s (RSX11-Mplus) and VAX/VMS, C-TERM (eg. SET HOST) is usually sort of "sluggy". Oh well, it depends! :) Usually our DECnet connections are very smooth, at least between VMS nodes; VAX, Alpha and Itanium, no matter which VMS version. In Italy we say that it glides (so well that) it seems greasy. :P LAT (eg SET TERM/LAT) is a protocol developed to cope with terminals character by character communication at first hand! I don't know if LAT is available to your 10-system, though, but if it is, use that for terminal traffic as far as possible. Yes, LAT is available, but I have other problems with it. As soon as I'll be able to tackle it, I'll try also that path. TOPS-10 is a though "game"... Besides, what version of VMS, on what hardware? I've heard birds singing of problems combining modern VMS-DECnet with older implementations in other machines... By now I have tried VMS 7.2 on VAX and 8.3 on Alpha. Now I'm waiting to try VMS 4.7 on the same Ethernet segment as the TOPS-10 node, then I will report on results! :) Thanks, G. Verzonden vanaf mijn draadloze BlackBerry -toestel

13 years, 10 months

1
0
0 0

Changing console from serial to graphics on AS800 from VMS?

by mark＠wickensonline.co.uk

On 31/08/11 13:54, hvlems at zonnet.nl wrote: The converter from DB9 (PC style) to MMJ is called an H8571-J The -J is very important since other H8571's will do different things. Hans ------Origineel bericht------ Van: Sampsa Laine Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: [HECnet] Changing console from serial to graphics on AS800 from VMS? Verzonden: 31 augustus 2011 14:24 Is it possible to change the OPA0: (on reboot, so it sticks) from serial to graphics on an AS800 through VMS? Sampsa Verzonden vanaf mijn draadloze BlackBerry -toestel Sampsa, consider investing in a DECserver... then you can have all your consoles available over ethernet.

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by bqt＠softjar.se

(I'll top-post this one...) SET HOST from a VMS system implies you use CTERM. CTERM is a horrible protocol, and only really works fine between VMS systems. Using it to connect to anything else usually means you can expect all kind of behavior and performance problems. It might be something else, but I would suspect CTERM as such first and foremost. Johnny On 2011-08-31 02:20, gerry77 at mail.com wrote: Dear All, I'm in need of some suggestions to improve DECnet performance of a TOPS-10 monitor running on KLH10. I'd like a lot to hear from you even if you do not know or run that specific system or configuration. When used locally at the CTY (Console terminal), the system response is very fast and smooth, so I'd tend to exclude emulator problems and such. Instead, when used from a remotely connected terminal (e.g. from VMS via SET HOST), it appears very sluggish: single character echo is very poor and output from the system fits and starts all the time. Output from programs is very fast for some hundreds lines, then stops briefly, then again appears almost instantly, and so on, like in bursts. Anyway, while the overall bulk data performance can be considered absolutely acceptable, the char-by-char responsiveness, e.g. typing interactive commands at the monitor prompt, is horrible: I type "D", "I", "R", and nothing happens, then I type "E" and "DIRE" suddenly appears... The TOPS-10 system has plenty of free core (both virtual and physical), free disk space, and free CPU, so it shouldn't be an OS issue in itself. Probably the most likely cause of this problem lies in some DECnet parameter that needs some tweaking, but I do not know which one... Have you ever had any experience with some ancient Digital OS having poor DECnet performance as described? And how did you solve that, or at least improve it? Here are some (maybe) interesting bits: Request # 1; Show Executor Node Characteristics Completed Executor Node = 1.1010 (DIECI) Identification = DECnet-10 Version 4.0 Management Version = 4.0.0 Loop Count = 1 Loop Length = 127 Loop With = Mixed Incoming Timer = 30 Outgoing Timer = 60 NSP Version = 4.0.0 Maximum Links = 65535 Delay Factor = 48 Delay Weight = 10 Inactivity Timer = 120 Retransmit Factor = 10 Routing Version = 2.0.0 Type = Nonrouting IV Routing Timer = 600 Broadcast Routing Timer = 40 Maximum Address = 1023 Maximum Circuits = 20 Maximum Cost = 100 Maximum Hops = 16 Maximum Visits = 20 Maximum Broadcast Nonrouters = 64 Maximum Broadcast Routers = 32 Maximum Buffers = 80 Buffer Size = 576 Segment Buffer Size = 576 Request # 5; Show Line Characteristics Completed Line = ETH-0 Receive Buffers = 6 Controller = Normal Protocol = Ethernet Hardware Address = AA 00 04 00 F2 07 Receive buffer size = 576 Request # 7; Show Circuit Characteristics Completed Circuit = ETH-0 Cost = 1 Maximum Routers = 16 Router Priority = 5 Hello Timer = 90 Type = Ethernet I'll be grateful for any suggestion! :) G. -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by gerry77＠mail.com

On Wed, 31 Aug 2011 10:58:53 +0200, you wrote: On PDP:s (RSX11-Mplus) and VAX/VMS, C-TERM (eg. SET HOST) is usually sort of "sluggy". Oh well, it depends! :) Usually our DECnet connections are very smooth, at least between VMS nodes; VAX, Alpha and Itanium, no matter which VMS version. In Italy we say that it glides (so well that) it seems greasy. :P LAT (eg SET TERM/LAT) is a protocol developed to cope with terminals character by character communication at first hand! I don't know if LAT is available to your 10-system, though, but if it is, use that for terminal traffic as far as possible. Yes, LAT is available, but I have other problems with it. As soon as I'll be able to tackle it, I'll try also that path. TOPS-10 is a though "game"... Besides, what version of VMS, on what hardware? I've heard birds singing of problems combining modern VMS-DECnet with older implementations in other machines... By now I have tried VMS 7.2 on VAX and 8.3 on Alpha. Now I'm waiting to try VMS 4.7 on the same Ethernet segment as the TOPS-10 node, then I will report on results! :) Thanks, G.

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by gerry77＠mail.com

On Wed, 31 Aug 2011 06:54:12 +0000, you wrote: The paramters you posted are aal defaults except for the node name aand address, right? Yes. Anyway I tried also with some modified parameters we use on other nodes, namely executor block size and buffer size, but nothing changed. The "problem" is that most of those parameters are "embedded" into the monitor, so to change them the monitor has to be rebuilt every time. Non particularly diffucult, but quite time-consuming. Moreover they have names like %RTBSZ and %DLBSZ, and is not always so easy to discover which NCP/DECnet parameter corresponds to which internal monitor variable... :) - have a look at the exec, line and circuit counters In my previous message I forgot to mention that all the error-related counters are at zero, so I thought not to paste them here. - examine the host IP characteristics and (if present) those of the winpcap package installed on the host Specifically, what characteristics are you thinking about? I have no idea about whatever I could check at host and pcap (on Linux) level. Thanks for your time, :) G.

13 years, 10 months

1
0
0 0

Changing console from serial to graphics on AS800 from VMS?

by hvlems＠zonnet.nl

The converter from DB9 (PC style) to MMJ is called an H8571-J The -J is very important since other H8571's will do different things. Hans ------Origineel bericht------ Van: Sampsa Laine Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: [HECnet] Changing console from serial to graphics on AS800 from VMS? Verzonden: 31 augustus 2011 14:24 Is it possible to change the OPA0: (on reboot, so it sticks) from serial to graphics on an AS800 through VMS? Sampsa Verzonden vanaf mijn draadloze BlackBerry -toestel

13 years, 10 months

1
0
0 0

Changing console from serial to graphics on AS800 from VMS?

by hvlems＠zonnet.nl

Not that I know, Sampsa. All I know is this srm command : set console graphics And its counterpart: set console serial if you have no MMJ plug, isn't it possible to use a telephone jack instead? I can make an MMJ to MMJ cable for you if you need one. All you need then is an MMJ to female DB9 jack. Hans ------Origineel bericht------ Van: Sampsa Laine Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: [HECnet] Changing console from serial to graphics on AS800 from VMS? Verzonden: 31 augustus 2011 14:24 Is it possible to change the OPA0: (on reboot, so it sticks) from serial to graphics on an AS800 through VMS? Sampsa Verzonden vanaf mijn draadloze BlackBerry -toestel

13 years, 10 months

1
0
0 0

Changing console from serial to graphics on AS800 from VMS?

by sampsa＠mac.com

Is it possible to change the OPA0: (on reboot, so it sticks) from serial to graphics on an AS800 through VMS? Sampsa

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by ahling＠eadc.se

Sorry for not being "expertly experienced on tops-10" (I know others who are... ;-) On PDP:s (RSX11-Mplus) and VAX/VMS, C-TERM (eg. SET HOST) is usually sort of "sluggy". LAT (eg SET TERM/LAT) is a protocol developed to cope with terminals character by character communication at first hand! I don't know if LAT is available to your 10-system, though, but if it is, use that for terminal traffic as far as possible. Besides, what version of VMS, on what hardware? I've heard birds singing of problems combining modern VMS-DECnet with older implementations in other machines... All best, G ran On 2011-08-31 02:20, gerry77 at mail.com wrote: Dear All, I'm in need of some suggestions to improve DECnet performance of a TOPS-10 monitor running on KLH10. I'd like a lot to hear from you even if you do not know or run that specific system or configuration. When used locally at the CTY (Console terminal), the system response is very fast and smooth, so I'd tend to exclude emulator problems and such. Instead, when used from a remotely connected terminal (e.g. from VMS via SET HOST), it appears very sluggish: single character echo is very poor and output from the system fits and starts all the time. Output from programs is very fast for some hundreds lines, then stops briefly, then again appears almost instantly, and so on, like in bursts. Anyway, while the overall bulk data performance can be considered absolutely acceptable, the char-by-char responsiveness, e.g. typing interactive commands at the monitor prompt, is horrible: I type "D", "I", "R", and nothing happens, then I type "E" and "DIRE" suddenly appears... The TOPS-10 system has plenty of free core (both virtual and physical), free disk space, and free CPU, so it shouldn't be an OS issue in itself. Probably the most likely cause of this problem lies in some DECnet parameter that needs some tweaking, but I do not know which one... Have you ever had any experience with some ancient Digital OS having poor DECnet performance as described? And how did you solve that, or at least improve it? Here are some (maybe) interesting bits: Request # 1; Show Executor Node Characteristics Completed Executor Node = 1.1010 (DIECI) Identification = DECnet-10 Version 4.0 Management Version = 4.0.0 Loop Count = 1 Loop Length = 127 Loop With = Mixed Incoming Timer = 30 Outgoing Timer = 60 NSP Version = 4.0.0 Maximum Links = 65535 Delay Factor = 48 Delay Weight = 10 Inactivity Timer = 120 Retransmit Factor = 10 Routing Version = 2.0.0 Type = Nonrouting IV Routing Timer = 600 Broadcast Routing Timer = 40 Maximum Address = 1023 Maximum Circuits = 20 Maximum Cost = 100 Maximum Hops = 16 Maximum Visits = 20 Maximum Broadcast Nonrouters = 64 Maximum Broadcast Routers = 32 Maximum Buffers = 80 Buffer Size = 576 Segment Buffer Size = 576 Request # 5; Show Line Characteristics Completed Line = ETH-0 Receive Buffers = 6 Controller = Normal Protocol = Ethernet Hardware Address = AA 00 04 00 F2 07 Receive buffer size = 576 Request # 7; Show Circuit Characteristics Completed Circuit = ETH-0 Cost = 1 Maximum Routers = 16 Router Priority = 5 Hello Timer = 90 Type = Ethernet I'll be grateful for any suggestion! :) G.

13 years, 10 months

1
0
0 0

Anyone with a spare MMJ cable + RS232 adapter?

by sampsa＠mac.com

Those would be very welcome as well, esp the ones that are wired to a DB9-F on the other end. Sampsa On 31 Aug 2011, at 09:31, Chrissie Caulfield wrote: On 30/08/11 18:39, Sampsa Laine wrote: Or other sane mechanism for getting a graphical console up on an AS800? I want to add some controllers and drives to CHIMPY? I might have some home-made (ie very dodgy) ones lying around a cupboard -- Chrissie

13 years, 10 months

1
0
0 0

Anyone with a spare MMJ cable + RS232 adapter?

by christine.caulfield＠googlemail.com

On 30/08/11 18:39, Sampsa Laine wrote: Or other sane mechanism for getting a graphical console up on an AS800? I want to add some controllers and drives to CHIMPY? I might have some home-made (ie very dodgy) ones lying around a cupboard -- Chrissie

13 years, 10 months

1
0
0 0

DECnet performance problems (on TOPS-10)

by hvlems＠zonnet.nl

The paramters you posted are aal defaults except for the node name aand address, right? Two suggestions: - have a look at the exec, line and circuit counters - examine the host IP characteristics and (if present) those of the winpcap package installed on the host Hans Verzonden vanaf mijn draadloze BlackBerry -toestel -----Original Message----- From: gerry77 at mail.com Sender: owner-hecnet at Update.UU.SE Date: Wed, 31 Aug 2011 02:20:37 To: HECnet<hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: [HECnet] DECnet performance problems (on TOPS-10) Dear All, I'm in need of some suggestions to improve DECnet performance of a TOPS-10 monitor running on KLH10. I'd like a lot to hear from you even if you do not know or run that specific system or configuration. When used locally at the CTY (Console terminal), the system response is very fast and smooth, so I'd tend to exclude emulator problems and such. Instead, when used from a remotely connected terminal (e.g. from VMS via SET HOST), it appears very sluggish: single character echo is very poor and output from the system fits and starts all the time. Output from programs is very fast for some hundreds lines, then stops briefly, then again appears almost instantly, and so on, like in bursts. Anyway, while the overall bulk data performance can be considered absolutely acceptable, the char-by-char responsiveness, e.g. typing interactive commands at the monitor prompt, is horrible: I type "D", "I", "R", and nothing happens, then I type "E" and "DIRE" suddenly appears... The TOPS-10 system has plenty of free core (both virtual and physical), free disk space, and free CPU, so it shouldn't be an OS issue in itself. Probably the most likely cause of this problem lies in some DECnet parameter that needs some tweaking, but I do not know which one... Have you ever had any experience with some ancient Digital OS having poor DECnet performance as described? And how did you solve that, or at least improve it? Here are some (maybe) interesting bits: Request # 1; Show Executor Node Characteristics Completed Executor Node = 1.1010 (DIECI) Identification = DECnet-10 Version 4.0 Management Version = 4.0.0 Loop Count = 1 Loop Length = 127 Loop With = Mixed Incoming Timer = 30 Outgoing Timer = 60 NSP Version = 4.0.0 Maximum Links = 65535 Delay Factor = 48 Delay Weight = 10 Inactivity Timer = 120 Retransmit Factor = 10 Routing Version = 2.0.0 Type = Nonrouting IV Routing Timer = 600 Broadcast Routing Timer = 40 Maximum Address = 1023 Maximum Circuits = 20 Maximum Cost = 100 Maximum Hops = 16 Maximum Visits = 20 Maximum Broadcast Nonrouters = 64 Maximum Broadcast Routers = 32 Maximum Buffers = 80 Buffer Size = 576 Segment Buffer Size = 576 Request # 5; Show Line Characteristics Completed Line = ETH-0 Receive Buffers = 6 Controller = Normal Protocol = Ethernet Hardware Address = AA 00 04 00 F2 07 Receive buffer size = 576 Request # 7; Show Circuit Characteristics Completed Circuit = ETH-0 Cost = 1 Maximum Routers = 16 Router Priority = 5 Hello Timer = 90 Type = Ethernet I'll be grateful for any suggestion! :) G.

13 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet