On 2011-09-03 16:06, Jesper Christensen wrote:
On Sat, 03 Sep 2011, Sampsa Laine wrote:
Anyone else having problems?
We had to shut Psilocybe (the machine running the bridge here at
Update) down to poke a bit at the UPS to which the machine is
connected. The bridge software is, afaik, not started at boot and I
have no idea how to start it so the bridge will probably be down until
Johnny can start it again.
Sorry about the inconvenience.
Yeah. I should fix that at some point... :-/
Never have enough time to do everything I'd like to do...
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
Signed PGP part
Ok, no worries, stops me from ripping my router / server configs to bits, however :)
On 3 Sep 2011, at 15:06, Jesper Christensen wrote:
> On Sat, 03 Sep 2011, Sampsa Laine wrote:
>> Anyone else having problems?
>>
>>
>
> We had to shut Psilocybe (the machine running the bridge here at
> Update) down to poke a bit at the UPS to which the machine is
> connected. The bridge software is, afaik, not started at boot and I
> have no idea how to start it so the bridge will probably be down until
> Johnny can start it again.
>
> Sorry about the inconvenience.
>
> /Jesper
On Sat, 03 Sep 2011, Sampsa Laine wrote:
Anyone else having problems?
We had to shut Psilocybe (the machine running the bridge here at
Update) down to poke a bit at the UPS to which the machine is
connected. The bridge software is, afaik, not started at boot and I
have no idea how to start it so the bridge will probably be down until
Johnny can start it again.
Sorry about the inconvenience.
/Jesper
I have no V4 system running right now. I thought that the /application_protocol switch had been present since V3.4 or so.
------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: 3 september 2011 14:23
On Sat, 3 Sep 2011 11:46:33 +0000, you wrote:
$ set host/applic=rterm <nodename>
Yes, but not on VAX/VMS V4... :-)
G.
Verzonden vanaf mijn draadloze BlackBerry -toestel
Oh there is:
$ set host/applic=rterm <nodename>
Hans
------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: 3 september 2011 13:09
On Fri, 02 Sep 2011 23:38:09 +0200, you wrote:
Indeed, I was also looking for a third-party implementation in the DECUS
archives: if I'm not wrong, older VMS like V4.7 already did CTERM, but had
no /APP=R qualifier in SET HOST, so there was no apparent way to switch from
CTERM back to RTERM like we can do now with newer VMS. So, I was hoping
someone back then wrote a RTERM client to be used with such vintage VMS
releases (which I'd try in V8), but I've still found nothing. :-\
I bet it was a separate application back in VMS V4, instead of being a
switch to SET HOST. Or else a different switch back then...
Not really: I've just discovered that RTPAD.EXE (the program behind the SET
HOST command) falls back to RTERM if CTERM cannot be used, e.g. if object 42
is not defined at the remote node. This at least in V4.7. :)
(There is apparently no way to use RTERM when CTERM is available.)
Bye,
G.
Verzonden vanaf mijn draadloze BlackBerry -toestel
On Fri, 02 Sep 2011 23:38:09 +0200, you wrote:
Indeed, I was also looking for a third-party implementation in the DECUS
archives: if I'm not wrong, older VMS like V4.7 already did CTERM, but had
no /APP=R qualifier in SET HOST, so there was no apparent way to switch from
CTERM back to RTERM like we can do now with newer VMS. So, I was hoping
someone back then wrote a RTERM client to be used with such vintage VMS
releases (which I'd try in V8), but I've still found nothing. :-\
I bet it was a separate application back in VMS V4, instead of being a
switch to SET HOST. Or else a different switch back then...
Not really: I've just discovered that RTPAD.EXE (the program behind the SET
HOST command) falls back to RTERM if CTERM cannot be used, e.g. if object 42
is not defined at the remote node. This at least in V4.7. :)
(There is apparently no way to use RTERM when CTERM is available.)
Bye,
G.
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
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
