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