HI,
My VAX is now back online again (so am I) - looks like my "Hecnet-hub"
is no longer accepting my node 29.400.
I would like to get back on-line.. anyone has an idea how to get back on
the line ?
Regards,
Ales
I received an RX4640 for my birthday today (ok a few weeks early). 4 cpu, 12Gb ram, 2x 72Gb discs. It also appears to have 2 smart array controllers and some fibre channel cards (pci-x)
I put VSI VMS on it.
It?s going to be ANBUS on the HECnet.
Boy is it loud!
And warm....
:)
Right, now back to that CI for SIMH that I parked a while back....
Buzzing!
? I'm tinkering with putting together a MicroVAX I system. They only
ran on a few versions of VMS.
? Does anyone have a copy of VMS handy for any version between V4.1 and
V5.1? On HECnet would be great.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
Hello everyone,
I am trying to get DECnet working on a simulated VAX 780 (with simh) with a
3.x version of VMS. This is largely for nostalgic reasons.
I have the version of VMS 3.0 from John Dundas that Supratim posted nearly
a year ago. I have also built a VMS 3.0 system by installing VMS from the
VMS 3.0 distribution tape. Both of those systems seem to work well.
However I am failing to find a way of getting DECnet working. I have a
DECnet end node key (and a routing key, come to that) from
http://iamvirtual.ca/VAX11/VAX-11-software.html but that says that it only
works for VMS 3.4 or later. I did try it on 3.0 anyway, but it did not get
DECnet to work. It complains about needing a license.
Can anyone help me either upgrade my VMS 3.0 system to VMS 3.4 or higher
(or just install the higher version from scratch), or help me find a DECnet
key that works with VMS 3.0.
Cheers
Peter Allan
In playing with DECnet I built a DDCMP implementation which deals with a byte stream, normally from a UART. So that works nicely with async link DDCMP as found in RSX and several other operating systems. But the speed is limited.
The other option would be synchronous links, which would enable connections to DMC11 or the like at speeds up to 1 Mb/s. But synchronous comm devices that connect to modern computers aren't so easy to find, though I have seen a few.
After playing with Arduino for LK201 keyboard emulation I started to wonder if one could be made to be a synchronous comm link with a USB back end, with low level things like byte framing and maybe DDCMP packet format handling in there, but the protocol state machine in the host behind the USB interface. For moderate speeds that seems entirely practical. For 1 Mb/s, probably not, though perhaps one of the fast ARM based units with its built-in SPI could be warped into that.
The alternative would be something like a BeagleBone Black (or Green) such as David Gesswein used as the engine for his MFM hard disk emulator. That clearly could do the job without any strain.
So I'm wondering: would there be interest in such a thing? If yes, should it be a modem-connected one (RS232 signaling, bit clock supplied externally by a modem or modem-eliminator)? Or should it be the "integral modem" short distance type, the ones that used a pair of coax with 4-pin AMP connectors like this https://www.digikey.com/en/products/detail/te-connectivity-amp-connectors/2… ?
paul
The Raspberry Pi that I have been using for at least 10 years to run the
hecnet bridge has finally died so I need to setup a new one.
In the meantime my area will be offline as far as hecnet is concerned.
Regards, Mark.
--
https://www.qrz.com/db/M0NOM/P
For all those who have tunnels to my Cisco 1841, I have switched ISPs and
as such my static IP address has changed. In my configuration I have the
following endpoints configured:
David Moylan (Area 35)
Tomas Prybil (Area 34)
Supratim Sanyal (Area 31)
Brian Hechinger (Area 52)
Ian McLaughlin (Area 42)
Cory Smelosky (Area 9)
Dave McGuire (Area 61)
Peter Lothberg (Area 59)
Mark Darvill (Area 22)
Mark G Thomas (Area 23)
If you are on that list could you please update your tunnel to use my new
address, which is 163.47.57.118.
Mark Berryman, my IPv6 address is unchanged, for the moment.
Regards, Tim.
I was wondering if anybody else had either seen the below or noticed
it.? I didn't have as free space on my public structure as I thought I
should, so I went poking around and found:
TOMMYT:<SYSTEM-ERROR>?? Pages?? Bytes(Size)? Write Date and Time Writer
?ERROR.SYS.1;P777752????? 138,495 70909216(36) 11-Jan-2021 14:20:29
OPERATOR
To put this into perspective, we are looking at about a 304 MB file;
it's larger than what could have been held on an RP06? So I ran SPEAR
and pulled down a few of the most recent items, viz:
***********************************************
DECNET ENTRY
?LOGGED ON? 9-Jan-2021 19:02:18-EST????? MONITOR UPTIME WAS 113
day(s) 0:50:12
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 28063.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.522 (VENTI2), occurred 9-JAN-2021 19:02:08
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B
There are hundreds of thousands of these, causing ERROR.SYS to grow by a
number of pages every day.? I didn't remember how to turn a DECnet node
number into dotted decimal, but I did notice the follow from the DECnet
bridge (SIGUSR1):
Host table:
0: purgatorio 0.0.0.0:0 (Rx: 2963632 (3352330) Tx: 1687334 Fw:
1276298 (Drop rx: 2076032)) Active: 1 Throttle: 598 (203)
1: legato 108.65.195.50:4711 [Ov: 0, Nov: 1693548, Lst: 0] (Rx:
1687334 (1693548) Tx: 1276298 Fw: 1687334 (Drop rx: 6214)) Active: 1
Throttle: 9054(070)
Hash of known destinations:
aa000400080a -> 0 (2.520)
aa0004000a0a -> 0 (2.522)
aa000400ff0b -> 1 (2.1023)
So one of these is coming over that bridge (2.1023).? What is AB 00 00
03 00 00?? Anybody have any ideas of what's going on?? I haven't looked
in the monitor code, yet.? If you are running any 36 bit OS, what are
you seeing?
The octal code for the DECnet Frame Too Long error is _240_.? In order
to free up some PS: space on my systems, I split off all these off into
a separate binary file on another structure.? On VENTI2::, ERROR.SYS
went from 96,967 pages to 45,847 pages.? The separate binary file
containing only the 240's is 51,120 pages long, so more than half the
space were these errors.
TOMMYT:: was a similar story: there, the ERROR.SYS file was a whopping
137,970 pages long.? With the 240 items split off, it went down to 9,614
pages, while the (binary) extracted items were 129,410 pages long.? It's
hard to understand what files of these sizes mean; at nearly two RP06's,
this single file approaching ? of the total storage that was allocated
to ? of Columbia's 25,000 undergraduate student body.
The size of my ERROR.SYS files is due to two factors:
1. It's every error since I started running Tops-20 again in late 2001
2. I have a lot of errors due to DECnet nodes coming on and off line
The 2^nd item is triggered because of a nightly batch job (VIKING) that
updates my development changes on VENTI2 to another structure on TOMMYT,
in case I blow VENTI2 up.? The KLH10 NI can pump out an amazing amount
of data, but chokes when it is receiving; I've never really understood
why (not that I've carefully looked).? If you want to get data into the
machines, then you either have to use a magnetic tape or Kermit.
Anyway, this plus, quarterly backups, is how I address losing files by
mistake.? You ARE all doing backups, right?
Meanwhile, it seems to me that, for the time being, I really don't care
about the node-online/offline events.? Unfortunately, there does not
appear to be any way to shut them off.? I'm thinking putting together
some kind of monthly batch job to strip these out.? Again, any Tops-10
or Tops-20 machine is going to see /huge/ error logs because of what's
happening.
Isn't anybody else noticing anything?
L.S.
Almost good:
In the Anf10 source listings the following:
DN200 - DECSYSTEM-10 REMOTE STATION MACDLX V31 11-AUG-120 20:31 PAGE 227-1
DNDCMP.P11 16-FEB-88 07:57 LINK DOWN
9934 ;*** ALTHOUGH THERE IS NOTHING REALLY IN THE DDCMP SPEC TO PROHIBIT SIMPLY
9935 ;*** STARTING OFF WITH WILD AND WIERD NUMBERS, SOME LESS-THAN-ROBUST SYSTEMS
9936 ;*** TEND TO GET TERRIBLY CONFUSED IF THE FIRST DDCMP NUMBERED MESSAGE ISN'T
9937 ;*** NUMBER "1", SO . . . RESET THE MESSAGE NUMBERS
9938 ;*** MOVB LB.LAP(J),LB.HSN(J) ;HIGHEST PROC IS HIGHEST SENT
9939 ;*** MOVB LB.HSN(J),LB.LAR(J)
9940 035140 005065 000056 CLR LB.ROK(J) ;RESET MSG NUMBERS
9941 035144 005065 000060 CLR LB.LAP(J)
9942
9943 002 .IF NE FT.DDP
9944 TST LB.ST2(J) ;IS THIS A DDP-CONTROLLED LINE?
9945 BPL 40$ ;NO, DO NCL'ISH STUFF
9946 MOV J,-(P) ;YES, SAVE LBLK ADDRESS
9947 MOV LB.DDB(J),J ;CONTEXT SWITCH TO DDP DEVICE LEVEL
9948 JSR PC,DDPOFL ;SAY THE DDP DEVICE IS "OFFLINE"
9949 MOV (P)+,J ;RESTORE DDB ADDRESS
9950 RTS PC ;NOTHING MORE TO DO
9951 001 .ENDC ;.IF NE FT.DDP
DN200 - DECSYSTEM-10 REMOTE STATION MACDLX V31 11-AUG-120 20:31 PAGE 230
DNDCMP.P11 16-FEB-88 07:57 DDPSER - DDP DEVICE SERVICE ROUTINES
10058 .SBTTL DDPSER - DDP DEVICE SERVICE ROUTINES
10059
10060 001 .IF NE FT.DDP
10061 002 .IF NE DDPN
10062
10063 ;THE DDP DEVICE ALLOWS THE VARIOUS DDCMP LINES TO BE USED AS DIRECT I/O
10064 ;DEVICES RATHER THAN AS NCL (OR NSP) NETWORK COMM LINES.
10065
10066 ;DDP DEVICE PARAMETERS SETTABLE ON A "PER-LINE" BASIS
10067 ;
10068 ; DPnnWID ;"RECORD SIZE" OR MESSAGE SIZE
10069 ; DPnnCHK ;CHUNKS-PER-DATAREQUEST WEIGHTING
10070 ; DPnnRNN ;RESTRICTED HOST ASSIGNMENT
10071 ; DPnnPFH ;PREFERRED HOST ASSIGNMENT
10072
It is for an Anf10 ddcmp device on a Pdp11/34 DN200 Anf10 workstation which might also have been (projected to?) made use of in a 2020 system.
Anf10 runs on simh Pdp11/34 with some fiddling of the emulation speed.
Best regards,
R.V.
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Peter Lothberg
Sent: Sunday, 17 January, 2021 23:29
To: hecnet <hecnet at Update.UU.SE>
Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
A DDP device is a "DDCMP speaker on a ANF10 front end".
It's basically a 576 byte card punch/reader on the front end with corresponding
device on the T10 side. We used it on the KI to talk both DECnet-IV and IP (to
a BSD 4.3 vaxen with a DMR-11.) It was done as a hack by Robert Hauk, who
also put in ANF10 over Ethernet. (remmember the DECnet frontend for the DTE
was only phase 3).
Dept of useless knowledge..
-P
_____
From: "tommytimesharing" <tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com> >
To: "hecnet" <hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE> >
Sent: Sunday, January 17, 2021 5:10:08 PM
Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
The only serial lines that I saw DECnet running on were synchronous connections. The local connections between CU's 20's (before we got the CI's and NI's) were 56K baud synchronous lines running on KMC11's, which we thought were pretty hot stuff ...until... Non-data center connections (our chemistry VAX, CMU & CWR 20's) were asynchronous lines running 9.6K baud (on DUP11's, I think).
The PANDA monitor's Multinet code implements serial IP (SLIP), which it will run over an ordinary DL or DH based asynchronous lines. I didn't immediately see anything similar for DECnet, but it is doubtful that MRC would have put that it in; the code was supposed to run on a 2020, which has different IO drivers. If his 2020 5.0 changes ever do surface, it may be conceivable that some of them might be retrofitted into 7.1 (depends on what's applicable).
It is now possible that I will eventually figure out what this mysterious DDP device is. I reconfigured both 20's to have the largest buffer possible (DECNET BUFFER-SIZE 1476 in SYSTEM:7-1-CONFIG.CMD, which I checked in the running monitor), rebooted and ... I'm still getting the same frame too long error, viz:
***********************************************
DECNET ENTRY
LOGGED ON 16-Jan-2021 01:29:38-EST MONITOR UPTIME WAS 0 day(s) 0:16:8
DETECTED ON SYSTEM # 3691.
RECORD SEQUENCE NUMBER: 35752.
***********************************************
DECNET Event type 5.15, Receive failed
>From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:11
Line NI-0-0
Failure reason = Frame too long
Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 08 0A
***********************************************
DECNET ENTRY
LOGGED ON 16-Jan-2021 01:29:38-EST MONITOR UPTIME WAS 0 day(s) 0:16:8
DETECTED ON SYSTEM # 3691.
RECORD SEQUENCE NUMBER: 35753.
***********************************************
DECNET Event type 5.15, Receive failed
>From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:28
Line NI-0-0
Failure reason = Frame too long
Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B
************************************************************************
Darn it?? So now I've got some modifications to actually make to the monitor to give some better error information (like the number of bytes overrun, if I can extract it). So maybe I'll stumble over whatever DDP does. It's odd; I can't think of any device that a pack of KL's could share except something like a dual ported disk or magnetic tape drive and that's only two KL's.
Meanwhile, I'll also do a tcpdump so I can try to correlate what Tops-20 is silently whining about with what's coming over the bridge.
Finally, something to beware of if you are running the KLH10 micro-engine and have a very large file that you're backing up (you're all running regular backups, right?) The amount of disk activity will somehow prevent KLH10's front end timer from popping so, unless you are running my changes to DTESRV, you're going to hang with a DTEKPA BUGINF. A quick hack is to deposit a -1 into FEDBSW, which will keep the 20 from trying to reboot the front end (which KLH10 absolutely does not know how to handle).
So the quarterly full backups worked fine on the development machine (VENTI2) which has the patch, but not on the production machine (TOMMYT) which does not. Pity, I had been up over 32 weeks and was only a little short of 3,000 hours uptime.
_____
On 1/15/21 11:58 PM, Johnny Billquist wrote:
I saw that and wondered as well.
I was thinking maybe it could be for DDCMP devices without more specifically defining what it would be, since DDCMP could be run over any serial line?
Johnny
_____
On 2021-01-15 22:53, Peter Lothberg wrote:
The 2020 has a KMC11 and up to 2 DUP11, and those are the interfaces
the "MRC T20 DECnet thing supports.
On the list of devices/sizes you posted is a "DDP" device and I wounder if you knew what that is?
--P
_____
From: "tommytimesharing" <mailto:tommytimesharing at gmail.com> <tommytimesharing at gmail.com>
To: "hecnet" <mailto:hecnet at Update.UU.SE> <hecnet at Update.UU.SE>
Sent: *Friday, January 15, 2021 4:24:07 PM
Subject: *Re: [HECnet] Thousands of DECnet errors on Tops-20
DDP? I thought it was DUP-11.
_____
On 1/15/21 4:21 PM, Peter Lothberg wrote:
Well, MRC was receiving "suggestions" from Stu Grossman on how to do it, but if my memory does not fail me the block size was 312, due to lack of buffer space in the already crammed single section 512KW 2020. I'm afraid my tape and disk-pack are in Seattle. I knew it was not 576 as it had two DUP-11's and using it for transit failed...
Quiz, do you knew what a DDP is?
-P