L.S.
You a true altruistic wonder these days to have around :)
A king, sitting on his coffers chockfull of goodies, waiting to dispense them lavishly among the lesser endowed fellow users ....
Usually with kings it is the other way around as can be seen so often today.
Are the other set host varieties on MIM also endowed with workable patches?
We'll play copycat then, ... until better times will arrive.
Thanks ever so much,
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Wednesday, 26 August, 2020 22:02
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Configuring py-decnet.
Aw, shit! (Excuse my language.)
I had more or less forgotten. Yes, as distributed, it has a bug. I have fixed it, but of course, noone else have that.
For now, the simple solution, pick MIM::DU:[5,54]RRS.TSK, and you'll be good.
Sigh! I really hope the whole DEC/Mentec/HP ownership mess can be sorted one day. I have about 100 fixes or improvements to RSX sitting...
Johnny
On 2020-08-26 21:57, R. Voorhorst wrote:
> L.S.
>
>
> Is there something different with patch levels or otherwise?
>
> After successful login on Rsts 10.1:
>
> $ logout
> SAVED ALL DISK FILES ON SY: 6784 BLOCKS IN USE JOB 7 USER 1,2 LOGGED
> OFF KB24: AT 26-AUG-20 21:53
> 6 OTHER USERS STILL LOGGED IN UNDER THIS ACCOUNT SYSTEM RSTS V10.1-L
> RSTS/E V10.1 RUN TIME WAS .2 SECONDS ELAPSED TIME WAS 1 MINUTE GOOD
> EVENING
>
>
>
>
>
>
> SWBU01::RRS -- Remote disconnect
>
> SWBU01::RRS -- Control returned to node SWBU01::
> MOV #20,R0
> EM:065126
> XDT>
>
>
> Best regards,
>
> Reindert
>
> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
> Behalf Of Johnny Billquist
> Sent: Wednesday, 26 August, 2020 15:09
> To: hecnet at Update.UU.SE
> Cc: Thord Nilson <thordn at gmail.com>
> Subject: Re: [HECnet] Configuring py-decnet.
>
> And to complement the picture a little more. On RSX, you need a program called RRS, which is provided among the "unsupported utilities" in the DECnet distribution.
>
> .rrs elvira
> MIM::RRS -- Connection established to node ELVIRA::
>
> RSTS V10.1-L 26-Aug-20 14:41
> User: 99,99
> PASSWORD:
>
> LAST INTERACTIVE LOGIN ON 26-AUG-20, 02:36 AT KB21:
>
>
> $
>
>
> Johnny
>
> On 2020-08-26 02:19, Thomas DeBellis wrote:
>> Yeah, that's what I found out, too.
>>
>> On Tops-20, the CTERM client is called CTERM-SERVER (don't ask)
>> whereas the NRT client is called SETHOST. SETHOST is /quite/ old and
>> I had been hacking it for efficiency and fixing a few bugs.
>>
>> It now has an alternate debugging entry to try to force Tops-20 NRT
>> (which will also work on Tops-10) and ignore the remote node type
>> until it can't proceed any further. Here are the results from my own
>> tests; they indicate that a CTERM (server) object does not exist on ELVIRA.
>> I'm not sure, but I had thought that CTERM had not been done on RSTS/E.
>>
>> !cterm-sERVER.EXE.2 elvira
>>
>> [Attempting a connection,
>> _CTERM Connect failed - Destination process does not exist_ !g
>> ds:sethost !ree Escape character(^Y):
>> Host name: ELVIRA::
>> [Connecting to remote host: ELVIRA]
>> _?RSTS/E type systems do not support Tops-20 NRT communications._
>>
>>
>> On 8/25/20 8:09 PM, Paul Koning wrote:
>>> John,
>>>
>>> Some systems, like VMS, will use CTERM by default, and there isn't a CTERM listener on RSTS. So you have to tell it to use the "old protocol", whatever that involves on your OS.
>>>
>>> paul
>>>
>>>> On Aug 25, 2020, at 7:24 PM,jy at xtra.co.nz wrote:
>>>>
>>>> Hi Thord,
>>>>
>>>> Congratulations, I can see you're up at:
>>>>
>>>> http://akdesign.dyndns.org:8080/map/data
>>>>
>>>> I just tried a set host elvira and set hsot 59.53 but I'm getting "network object unknown at remote node".
>>>>
>>>> Cheers, John
>>>>
>>>>
>>>>
>>>>> On 26 August 2020 at 11:14 Thord Nilson<thordn at gmail.com> wrote:
>>>>>
>>>>> Hi all!
>>>>> Update!
>>>>> Basic connections are now working, so for a limited time you can:
>>>>> set host elvira::
>>>>> login as 99,99 psw: testing
>>>>> Nothing much to see though.
>>>>> Thanks to all for your help!
>>>>>
>>>>> /Thord.
>
--
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
Peter Lothberg <roll at stupi.com> writes:
>I have a "DS20". It's a 1U thing with SCSI and IDE controllers for the disk,
>2 100M Ethernet and 2 serial ports, two Alpha CPU's. Anyone that has VMS that
> would run on that?
A 1U DS20?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Hi,
I know HECnet "should not be regarded as a serious networking setup, nor should it be expected to work 24/7" to quote Johnny's web page on the subject. I find it fun in a 'way back when' sense because way back then, as a student encountering VMS for the first time, the real DEC VAX 11/780 two-node cluster at the university was connected together via its CI and to the outside world by KMV X25 devices. The latter devices only talked the old UK 'Coloured Books' protocols and DECnet wasn't (officially) allowed over Janet. So you can imagine how underwhelming the output of various NCP SHOW commands was, even with the addition of a standalone Systime VAX and the odd departmental MicroVAX to the DECnet, using a mixture of KMVs, asynch DDCMP, eventually X25 1984 (pink book?) over Ethernet and then unencapsulated DECnet over Ethernet. All this was around the time of VMS 5.4 I think. Departmentally, we also used CMUTEK TCP/IP software to talk to the world when UK Academia finally accepted that IP was the way to go and OSI just wasn't going to happen.
Anyway, the point(s).
It's really nice to be able to see a page full of circuits, nodes, areas etc. as a result of being connected to the HECnet. In combination with Paul's excellent mapper joining up geography with connectivity, there's a certain 'warm fuzzy feeling' being part of a community like this... even if our nodes do more of the talking than we do. Harking back to the hobbyist bit though, I have to stop myself from being disappointed when nodes drop off for whatever reason especially long term. I've not seen inbound links from 29.400 and 29.500 for a while now. I occasionally wonder where area 8 is too - geographically less than 10 miles away possibly yet I've not seen any of it up and running on the HECnet during my connection to it.
I'm not complaining about any of this, just wondering... as well as staying as far away from source-code control topics as possible :)
Keith
Gentlepeople,
I finally got around to merging and testing the Linux support for "TAP mode Ethernet. It's now in the code and works in my tests (and others have confirmed this).
Thanks to Keith Halewood for the code.
paul
PS. I'm considering moving the code from my home Subversion server to Github. Any feedback on that idea?
If you are running a standard PANDA distribution, then DDT is in the
monitor and you may fail to it.? Did it come up?? Did you do an examine
from the KLH10 micro-engine to see what instruction it was failing on??
Did you see what module it is failing in?
My monitor is modified from the base PANDA distribution to include
several local enhancements, so when I looked at that address, it showed
up as in the entry of CHKOPC, which is what is checking for differed
closes on virtual circuits.? This is in PHYKLP which is the KLIPA driver
(a.k.a. the CI).? Since KLH10 (sadly) does not implement the CI, there
is no way you should be executing in that module as there nothing for it
to talk to.
Moreover, there is no JRST 4 there.? So probably you have something else
at that address.
I have been running KLH10 for a /very/ long time; since late December
2002 and have made modifications there, too to fix an issue with locking
memory and to better support Linux (recent Ubuntu).? It is remarkably
robust; despite intensive development, I have stayed up well over a year
at a time (I.E., hit UP2LNG BUGHLT's)
I have found one problem; if you are running it on an _extremely_ fast
machine with SSD storage (in other words, you're basically never waiting
for anything) and you seriously beat on the file system, then the
keep-alive counter can get out of sync with the 20 thinking the front
end has died and the KLH10 DTE simulator apparently not understanding
what to do.
The 20 typed an initial BUGCHK and then in the middle of the second one,
it hangs waiting for the front end.
It's on my list of things to investigate.
> ------------------------------------------------------------------------
> On 8/31/20 4:15 PM, Supratim Sanyal wrote:
>
> hi all - my panda distribution instance is halting after a couple of
> days with the following message. is this a known problem for which
> there is some workaround?
>
> Monitor RF434E DEC10 Development
> System uptime 52:10:47
> Current date/time Wednesday 29-Jul-120 6:01:04
>
> [HALTED: Program Halt, PC = 22013]
>
> thanks
>
> Supratim
>
