HECnet

hecnet@lists.dfupdate.se

6 participants
15552 discussions

by tommytimesharing＠gmail.com

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?

3 years, 10 months

Reducing the ERROR.SYS file size

by tommytimesharing＠gmail.com

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?

3 years, 10 months

Thousands of DECnet errors on Tops-20 --> Ddp device

by R.Voorhorst＠swabhawat.com

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

3 years, 10 months

DS9010 kit for VAX/VMS

by steve＠davidson.net

I?m looking for a copy of this kit to setup my DECserver 90TL?s after rebuilding SGC::. Does anyone have this kit? Thanks! -Steve Davidson SF:iP1

3 years, 10 months

DECnet-10 doesn't work past Nov 9 2021?

by bob＠jfcl.com

This topic came up on the alt.sys.pdp10 list https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ Apparently DECnet-10 won't work past November 9th 2021, which isn't that far away. Personally I'd never heard this before and had no idea, and since I know there are a few 36 bit emulations on HECnet that are obviously using DECnet I thought I'd pass it along. TOPS20 isn't explicitly mentioned, but I'm guessing that it has the exact same issue. That'd mean no DECnet on 36 bit systems after next year! Unless, of course, you want to start playing games with the date (which I hate doing). Bob

3 years, 10 months

The new few centuries (or DATE75)

by tommytimesharing＠gmail.com

After sending my last update on 36 bit DECnet, I went back to working a large ALGOL program from 1980 that I recently scanned. Again, the ALGOL that ships with PANDA is quite old, dating to 10A145, whereas the most recent version I picked up from a Tops-10 site on HECnet is 10B310--so I've been dusting that off. I remembered that it is not Y2K compliant, so I quick fixed it, in ALGCON.MAC. at DEC2:, change DEC2:?? IDIVI A4,^D10???????? ; A4=TENS, A5=ONES TO: DEC2:?? CAIG??? A4,^D99???????? ;[T143] After 1999? ???????? JRST?? DEC2A?????????? ;[T143]? Nope, nothing to fix ??????? SUBI??? A4,^D100??????? ;[T143] Reduce by a century ??????? JRST??? DEC2A?????????? ;[T143] Check if in right century DEC2A:? REMARK????????????????? ;[T143] Here when year is in range ??????? IDIVI?? A4,^D10???????? ; A4=TENS, A5=ONES Simple enough.? And then something in the back of my mind started recalling a comment that such fixes wouldn't work after 2052.? A dim memory surfaced about my first DECtape in 1975 (it was a birthday present) that I had to have updated because of something called 'DATE75'. So I went spelunking and here is what DATE75 is all about. Briefly, /very/ early versions of Tops-10 could only handle dates between January 1^st 1964 and January 4^th 1975.?? 3 additional bits were found in the directory and other formats that brought the end date out to February 1^st 2052--a fine hack. Anyway, a number of things broke in 1975 when the first bit started getting used, which is why apparently somebody had to play with my DECtape.? Bugs were also found (times being off by 11 years and four days) in January 8^th 1986 when the 2^nd bit started being used. It may very well be that, despite my kludge to prevent Tops-10 from crashing in November of next year, it may drop dead before the NICE field is expired in 2052. I think it might depend on what overflows in the result of the DATE UUO.? Unfortunately, its format deeply confused me in High School, but maybe I'll have another look after all these year.

3 years, 10 months

Happy 2021 to everyone

by djm＠wiz.net.au

Happy 2021 to everyone in HECnet land. I hope that it is an eventful and fruitful year for all and that it isn?t as bad as the year we are leaving behind. Cheers, Wiz!! Sent from my iPhone

3 years, 10 months

PyDECnet and IPv6

by paulkoning＠comcast.net

Why? Because I felt like it and it wasn't too hard. I have a PyDECnet version that can handle not just IPv4 but also IPv6. It's on node PYTHON right now and on the map server 28NH (at akdesign.dyndns.org). This applies both to the web interface and also to the various IP-based datalink protocols. I've tested Multinet, GRE, Ethernet (UDP bridge) and DDCMP. If anyone is interested in using this with PYTHON, let me know. Unfortunately dyndns.org doesn't support IPv6 records well; I can enter one manually but it disappears after a while for reasons I do not understand. It's there now. You can access the mapper's web page (akdesign.dyndns.org:8080) that way if you like. paul

3 years, 11 months

Generating a note list for pyDECnet

by bob＠jfcl.com

I'm embarrassed that I don't remember this, but somebody had a way to generate a HECnet node name and address list in a format compatible with pyDECnet. How did that work again? Thanks, Bob

3 years, 11 months

PCVMS

by supratim＠riseup.net

Hi It appears once upon a time there was some sort of a VMS-like shell on DOS called PCVMS from Wendin Software. Sampsa asked for it from the last person to work on it 11 years ago at http://personallyinteresting.blogspot.com/2009/04/computer-archeology.html Wondering if Sampsa or anyone has floppy images. Thanks. -- Supratim Sanyal, W1XMT 39.19151 N, 77.23432 W QCOCAL::SANYAL via HECnet

3 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet