Hello Keith,
Indeed, there is a way to make the white Alphaservers run VMS.The difference is minimal between the servers themselves, but sometimes the adapters and peripherals could be different in the white Alphas and don't work with VMS. Therefore you should check which adapters there are in the box. Examples of not working ones are Adaptec SCSI-adapters and various Graphics adapters.?You need to enable the SRM firmware instead of the AlphaBIOS and then create a short script which is run at boot time.If you want to do it I can send you the detailed instructions.Kari
-------- Original message --------
From: Keith Halewood <Keith.Halewood at pitbulluk.org>
Date: 10/8/20 14:00 (GMT+02:00)
To: hecnet at Update.UU.SE
Subject: [HECnet] VMS on AlphaServer 5000
Hi,
?
I?ve trawled through HECnet emails for enlightenment around alpha systems running VMS and I believe I?m not repeating the question. So here goes.
?
There?s an DEC Alphaserver 5000 (white case) (EV56) floating a few miles away from where I live. It?s running NT, so there?s an AlphaBIOS. Is there a ?hidden? SRM in that machine and therefore is it able to run current (HPE at least) versions
of VMS? I don?t want to end up with a machine running NT ? my life has enough horror in it already. I had a look on HP?s FTP site at firmware updates and the Alphaserver 5000 isn?t even mentioned, or at least not in plain text.
?
I nearly bought a reasonably loaded Itanic RX2600 a few days ago but chickened out at the last minute. What I really should do is abandon all of this and buy a new motorbike.
?
Keith
Hi,
I've trawled through HECnet emails for enlightenment around alpha systems running VMS and I believe I'm not repeating the question. So here goes.
There's an DEC Alphaserver 5000 (white case) (EV56) floating a few miles away from where I live. It's running NT, so there's an AlphaBIOS. Is there a 'hidden' SRM in that machine and therefore is it able to run current (HPE at least) versions of VMS? I don't want to end up with a machine running NT - my life has enough horror in it already. I had a look on HP's FTP site at firmware updates and the Alphaserver 5000 isn't even mentioned, or at least not in plain text.
I nearly bought a reasonably loaded Itanic RX2600 a few days ago but chickened out at the last minute. What I really should do is abandon all of this and buy a new motorbike.
Keith
Gentlepeople,
I committed rev 560, which may be of interest to a number of you.
It's basically a change of internal machinery, no functional changes. The main ones are:
1. Restructured the point to point (DDCMP and Multinet) implementations. Error recovery is much cleaner now and should be faster. Retry for persistent problems has holdoff on it that starts out pretty fast and slows down to (typically) one retry per two minutes.
2. Ethernet in PCAP mode now uses the PCAP filter mechanism to request only the frames we want. This means the Python code no longer spends a bunch of CPU time tossing away non-DECnet frames. If your machine runs other traffic in significant quantities, as mine does, this can be quite useful.
3. Improve the performance of packet logging.
This code has been running on PYTHON for several days now without problems (except for one bug that has been fixed). You're invited to give it a try; as always, problem reports or other comments are welcome.
paul
Hi, guys!
I'm trying to boot latest SIMH (4.0-current) as LAVC satellite node over
link with latency about 100ms.
Boot node is VAX/VMS 5.5.2 with latest PEDRIVER ECO.
Result: MOP part of boot sequence is work without a hitch, but SCS part is
failing miserably.
The most frequent result:
SIMH console filled with 10 x " %VAXcluster-W-NOCONN, No connection to disk
server " messages, halting with
"%VAXcluster-F-CTRLERR, boot driver virtual circuit to SCSSYSTEM 0000
Failed"
Sometime it goes little further:
...
%VAXcluster-W-RETRY, Attempting to reconnect to a disk server
%VAXcluster-W-NOCONN, No connection to disk server
%VAXcluster-W-RETRY, Attempting to reconnect to a disk server
%VAXcluster-W-NOCONN, No connection to disk server VULCAN
%VAXcluster-W-RETRY, Attempting to reconnect to a disk server
%VAXcluster-W-NOCONN, No connection to disk server
%VAXcluster-W-RETRY, Attempting to reconnect to a disk server
%VAXcluster-I-CONN, Connected to disk server VULCAN
%VAXcluster-W-NOCONN, No connection to disk server VULCAN
%VAXcluster-W-RETRY, Attempting to reconnect to a disk server
...
And halting after minute or so of filling console with those messages.
Whenever I setup throttling in SIMH to 2500K ops/s, the node boots
successfully,
joins cluster successfully and work flawlessly, but slow.
Boot process takes about half hour. After boot, changing throttle value to
3500K ops/s still works.
Increasing throttle value further broke system, with the same messages about
disk server.
Throttled SIMH performance is about 5VUPS.
The only information about maximum channel latency restrictions found in
"Guidelines for OpenVMS Cluster Configurations" manual is that:
"When an FDDI is used for OpenVMS Cluster communications, the ring latency
when the FDDI ring is idle should not exceed 400 ms."
So I suppose that 100ms latency link should be good enough for booting
satellite nodes over it.
My understanding of situation is that combination of PEDRIVER/[PEBTDRIVER
within NISCS_LOAD] with fast hardware
and slow links is a primary reason of such behavior. Please correct me if
I'm wrong.
Do anyone have experience with booting VMS clusters over slow links? OS
version recommendations?
Probably some VMS tunable variables are exists for making PEDRIVER happy on
fast hardware?
Having PEDRIVER listings can shed lights for such PEDRIVER's buggy behavior.
Link details:
Two Cisco 1861 routers connected with Internet via ADSL on one side and 3G
HSDPA on other side.
TCP/IP between sites is routed over IPSec site-to-site VPN. Ping between
sites is about 100ms.
Over that VPN built DECnet family (eth.type = 0x6000..0x600F) bridge with
L2TPv3 VPN.
--
BR, Vladimir Machulsky
Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not displayed. So you can see that a Multinet circuit is up and the other end is node 42.73, but you don't see the IP addresses or the like.
When things are working that's fine; when they are broken it might be helpful to see what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I have this question:
1. Should the addressing info (basically, what's in the --device config argument) be shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an internal address for the web service. That's what I do for my nodes except for the mapper, though perhaps there isn't a strong argument why it should be so restrictive. #2, on the other hand, is visible to all HECnet users assuming you haven't disabled NML in your config settings.
I'd be interested in comments. Am I too concerned about hiding information, or is it sensible to be cautious?
paul
I previously created a Github repository for various DEC things, including updated DECnet/E utilities. I thought that the RSTS patches I had posted in the past were there also, but that wasn't the case.
I've added a "patches" subdirectory, which contains the patches I have collected. I just added a new one, which fixes a bug encountered when running SIMH set to be an 11/94. In that case (and possibly some other similar variations) RSTS tries to figure out the line frequency and gets it wrong because SIMH executes much faster.
https://github.com/pkoning2/decstuff is the repository.
paul
The patches I posted are mostly for both. The kdj11e.cmd patch is for a problem seen on SIMH that probably can't happen on real hardware. The nsp1.pat file Tony mentioned is certainly more likely on SIMH but I suspect could happen on real hardware also. In any case, none of them will create problems on real hardware.
paul
> On Sep 15, 2020, at 9:20 AM, W2HX via cctalk <cctalk at classiccmp.org> wrote:
>
> Are these patches discussed below only for patching SIMH to fix problems with it? Or are these fixes that are for actual PDP hardware implementations of RSTS?
>
> -----Original Message-----
> From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Tony Nicholson via cctalk
> Sent: Monday, September 14, 2020 6:10 PM
> To: hecnet at update.uu.se
> Cc: cctalk at classiccmp.org
> Subject: Re: [HECnet] RSTS/E patches
>
> On Tue, Sep 15, 2020 at 7:28 AM Paul Koning <paulkoning at comcast.net> wrote:
>
>> I previously created a Github repository for various DEC things,
>> including updated DECnet/E utilities. I thought that the RSTS patches
>> I had posted in the past were there also, but that wasn't the case.
>>
>> I've added a "patches" subdirectory, which contains the patches I have
>> collected. I just added a new one, which fixes a bug encountered when
>> running SIMH set to be an 11/94. In that case (and possibly some
>> other similar variations) RSTS tries to figure out the line frequency
>> and gets it wrong because SIMH executes much faster.
>>
>> https://github.com/pkoning2/decstuff is the repository.
>>
>> paul
>>
>>
> Thanks for this Paul.
>
> There's also your NSP1.PAT patch to improve data flow using RSTS/E V10.1 under SIMH (posted to the SIMH mailing list in May 2016).
>
> You'll find it and the NSP1.TXT describing it in my repository at
>
> https://github.com/agn453/RSTS-E
>
> in the "decnete" subdirectory.
>
> I've recently joined HECnet and will be making some of my updates available soon.
>
> Tony
>
> --
> Tony Nicholson <tony.nicholson at computer.org>
I've just thrown together the RSTS/E updates mentioned in my previous
message into the DECnet default account on HECnet node DINGO:: (35.619)
The file DINGO::FILES.TXT contains the following details (and will be added
to as I make available more files).
=== FILES.TXT ==
These are the files available from HECnet node DINGO:: (a SIMH
PDP-11/70 emulation running RSTS/E V10.1 on a Raspberry Pi 3B)
in the Default DECnet account (no password required).
There's also a GitHub repository at https://github.com/agn453/RSTS-E
where you can get further RSTS/E related information (with a link
to Paul Koning's repository too).
Name .Typ Size Prot Access Date Time Clu RTS
DINGO::
Patch for improved Ethernet throughput using DECnet/E V4.1
on RSTS/E V10.1
NSP1 .PAT 2 < 62> 03-May-16 03-May-16 08:38 AM 64 ...RSX
NSP1 .TXT 9 < 62> 19-Sep-16 19-Sep-16 02:29 PM 64 ...RSX
Year 2003 update for FIT (File Interchange Transfer program)
FIT .TSK 92C < 62> 03-Jul-20 03-Jul-20 02:09 PM 64 RSX
FIT .DIF 5 < 62> 02-Jul-20 02-Jul-20 07:49 AM 64 ...RSX
FITBLD.COM 2 < 62> 03-Jul-20 03-Jul-20 08:09 AM 64 DCL
This file
FILES .TXT 2 < 60> 15-Sep-20 15-Sep-20 09:31 AM 64 RT11
A directory of Kermit-11 T3.63 files (with updates to 3-Oct-2006) available
from DINGO::KERMIT:
KERMIT.TXT 35 < 60> 15-Sep-20 15-Sep-20 09:32 AM 64 RT11
Please report any problems to me via e-mail to either
tony.nicholson at computer.org or (HECnet) FAUNA::TONY
--
Tony Nicholson <tony.nicholson at computer.org>
Peter Lothberg <roll at stupi.com> writes:
>Yes, it says DEC on some on Compac on some. The DS20 diagnostics and
>microcode update CD works on it.
What does it say in the SRM?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
G'day fellow HECnet enthusiasts!
In the past week I decided to jump in and join up my little home network of
Digital animals to HECnet. With the assistance of Johnny Billquist, David
Moylan (Wiz) and the brilliant piece of PyDECnet routing code by Paul
Koning running on a Raspberry Pi - I'm now up and online!
You'll see my machines pop up as 35.6xx nodes; and, as soon as I organise
things, I'll put some files up for perusal in the default DECnet accounts -
(they're empty now though).
I'm located at Newcastle, NSW in Australia and nudging over 45 years
contact with systems from PDP-11's through VAXen and on to Alpha... along
with various Cisco, Sun, CDC3500, ICL1904A, HP2100, HP1000 systems plus
microcomputers from the 8080, SC/MP, Z80 era up to now.
Johnny says I have "quite a list" of machines.. so I'll give a partial list
here (node names in brackets) -
RSTS/E V10.1 running on Raspberry Pis under SIMH PDP11 (DINGO and GALAH) -
the latter is a PiDP11 mini 11/70 front panel.
RSX11M-Plus V4.6 running on the same Raspberry Pi as DINGO under SIMH PDP11
(RUSTY)
OpenVMS VAX V7.3 on a Vaxstation-3100 M48 (POSSUM) - which is showing its
age with a power-supply fault since yesterday!
An original DEC-2000 AXP model 300 (TAIPAN) just freshly upgraded to VSI
OpenVMS V8.4-2L1
A VAX-11/780 SIMH emulation running OpenVMS V5.5-2 on Raspberry Pi (EMU)
Intermittently I also fire up emulations running Ultrix-32 VAX V4.6
(NUMBAT), TRU-64 V5.1B (QUOLL), "ancient" VAX/VMS from V1.5 to V4.7
(BROLGA), TOPS10 V7.04 (PANDA) - and P/OS V3.2 one day when I get a round
'tuit (DUGONG) with Xhomer Pro-380 emulation and async DECnet.
Finally a couple that are nearly always online -
An Alpha ES40 emulation (KOALA) under AlphaVM-Free running VSI OpenVMS
V8.4-2L1 on an Intel Core i7 Windows-10 box,
and VAXserver-3900 SIMH with OpenVMS VAX V7.3 under Windows-10/Cygwin-32
(VOGON).
You can reach me at FAUNA::TONY if you want to try e-mail the old fashioned
way from VAX-MAIL or Mail-11.
Tony
--
Tony Nicholson <tony.nicholson at computer.org>
Greetings all,
Now that VSI has their Hobbyist program all under way, we can get licensing for Integrity and Alpha hardware.
(the future is obviously x86 which is progressing well and I'm looking very forward to. The hobbyist program will cover x86 once it has been released)
I was thinking of trying to find an older Integrity or Alpha server to run OpenVMS but I'm struggling to find any real comparative performance comparison between the different models.
Most of the old forum posts on HP link to dead articles.
Alpha hardware still seems to be very high priced, but I'm starting to see some Integrity equipment coming down in price.
How does something like an Integrity rx1620 stack up? Would there be any sense in purchasing a single CPU version of this server?
If anyone has a list or can provide information on the different Integrity and Alpha platforms available that would be great.
I totally understand that performance comparison is an "it depends" question, but I'm just after some reality checks here, ie: a specific Integrity server might have "twice" the average performance of a different Alpha box and it might be cheaper, thus better bang per buck.
Can anyone help me out here?
The box will just be for hobbyist purposes. I'll probably setup a mail gateway and perhaps usenet and some other things to play with.
If it's relevant (for suggestions of anyone selling refurbed hardware), I'm located in Australia.
Thanks in advance,
Cheers, Wiz!!
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
>
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
Hello all!
I am trying to test up decnet iv on a rsts/e 10.1 system on simh and
hopefully connect to hecnet. Currently borrowing a node name/number from
Peter L.
Is the following setup workable/suitable?
rsts/e --> delqua --> virtual tap ethernet --> pydecnet --> real-ethernet
--> GRE tunnel.
Anyone who has done this and willing to share the setup used?
Or any good links?
I have not found a decnet-iv manual for rsts/e online, but maybe the rsx
manuals are usable. Anyone know?
Best regards,
Thord.
Hi Thomas,
How are your patches related to the Panda distribution?
Based upon as a reference or unrelated?
There are a lot of cross platform problems within fal for instance like in Tops10,
Best regards,
Reindert
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis
Sent: Wednesday, 26 August, 2020 22:44
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Configuring py-decnet.
You and me both!
I have over a 130 documented fixes and enhancements to Tops-20, some of them massive. This does not include what I've completely rewritten from scratch. Several items are in active development.
Yet I have no idea who I'd give them to. A few might interest XKL, perhaps. I guess I'll do something Github, one of these days.
I wore out all my vulgar language when Jupiter was cancelled. Seems like it's all 'Darn it', 'Golly' and 'Gee whiz' these days.
_____
On 8/26/20 4:02 PM, Johnny Billquist wrote:
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> [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 <mailto:hecnet at Update.UU.SE>
Cc: Thord Nilson <mailto:thordn at gmail.com> <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 <mailto: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 <mailto:thordn at gmail.com> <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.
Hi all,
I'm working on a connection from an OpenVMS 7.3 emulation currently running DECnet and MultiNet, to the HNET using JNET 3.6.
I'm stuck with the following after starting JNET:
$ @JAN_DEVICE:[JANCOMMON.SYS]JANSTART
%JCP-I-CREATE, Creating new Jnet database of 159 pages
$
%%%%%%%%%%% OPCOM 27-AUG-2020 15:52:14.00 %%%%%%%%%%%
Message from user SYSTEM on GLOVER
Jnet status message from link NZVAX001
Unexpected Jnet daemon termination for link: Unknown:
%RMS-E-FNF, file not found
And JNET isn't attempting to open a TCP connect to the HNET peer. The JENT install went OK and I've carefully cross checked my config files with Supratim who has been very helpful.
I appreciate this is a bit off topic for this reflector so if anyone has experience with JNET and time to help, I'd appreciate a contact off list. My email is jy at xtra.co.nz mailto:jy at xtra.co.nz
Thanks, John
I just made some small changes to the DECnet/E event logger application to fix a Y2K problem. (More precisely, a Y2K.003 problem).
https://github.com/pkoning2/decstuff
This is for RSTS V10.1. Just drop the new evtlog.tsk into [0,16].
paul
Paul,
I?m pretty sure this is you. It?s coming from 28nh (41.28). What is it expecting? I seem to remember a discussion on this, but can?t find it in my archives.
Thanks,
Zane
hi
Get your business to the next level with a solid Content Marketing strategy
http://www.str8-creative.io/product/content-marketing/
Regards
Tim Timoteo ?
Unsubscribe option is available on the footer of our website
Gentlepeople,
I've added a new feature to the HECnet mapper (http://akdesign.dyndns.org:8080/map/) to listen for topology change events and do incremental updates of the map as these happen. You can see this in the current mapper display, which will show "Last incremental change" in the map title block if there has been any incremental change since the last full update.
For this to be most effective, the mapper needs to be sent these events from at least one router in each area. A good choice would be the main backbone area router in each area; better still all the backbone area routers if there are several.
So if you have one of these and are interested in participating, please do the equivalent of this NCP command:
NCP>set logging monitor events 4.7-10,14-15,18-19 sink node 28nh
and of course the equivalent permanent command ("define" instead of "set", and perhaps in a different utility at least for the case of RSX).
If you're running PyDECnet, you need to upgrade to the current version, rev 524. Then add this line to the config file:
logging monitor --sink-node 28nh --events 4.7-10,14-15,18-19
When you set up a router for this, please drop me an email so I know which nodes are currently participating.
Thanks much,
paul