- HECnet - lists @ Update

by bqt＠softjar.se

Hi, all. If you are running an RSX system on HECnet, and you'd like a simple command line tool to check some information about other nodes, as it is registered in the Datatrieve database I keep on MIM, I've written one now. It does require that you have the PDP-11 C runtime libraries installed (they are installed as a part of BQTCP, and also exists as a component in RPM). Just grab MIM::HECNET:DDB.TSK, install it, and off you go. If you want the sources (it's really simple) they can be found at MIM::HECNET:DDB.C and you also have a Makefile there that compiles it for you, in case you want to experiment some. Example run: .ddb mim Node: MIM Address: 1.13 Owner: Johnny Billquist OS: RSX-11M-PLUS V4.6 CPU: PDP-11/74 (e11) Created: 12 Nov 2011 12:00:00 Modified: 02 May 2020 19:45:49 Loc: Uppsala, Sweden Coord: 59.858612,17.638744 . I just thought it could be useful to have sometimes, and it's also a good exercise in interfacing between Datatrieve and PDP-11 C. 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

4 years, 1 month

5
10
0 0

Tops-20 SETNOD Failure

by tommytimesharing＠gmail.com

Has anybody ever seen SETNOD fail to insert the entire node list?? I just did. Shortly after I put my 20's up on HECnet, I wrote a reoccurring batch job that fires once a week on Sundays to pull the latest node list (T20.FIX) from MIM::.? I use the highly venerable FILCOM program to do a difference of it with the previous week's list.? I don't do anything in particular with the output except save it in case I feel like looking at it for some reason. The batch job always inserts the entire list, rewriting whatever might be in the monitor's data base.? I have always been unsatisfied with doing things that way because it seemed to me to be inefficient as the node list grew.?? The HECnet node list count was 716 on 9-Jun-19 and it's now up to 884 as of the latest version that I've pulled, 30-Apr-21.? The other problem is the microscopic possibility that a node is in Tops-20's monitor database (a hash table) that isn't in the HECnet node list. Nodes can get removed, although I think that infrequent.? Nodes could get inserted outside of the batch job, but I think that most unlikely in my situation.? Nodes can get renamed, as evidenced by 2.299 below, which went from THEPIT to THEARK.? None of this should or has broken anything. However, it's been in the back of my mind to do two enhancements, one to Tops-20 and one to SETNOD. The NODE% JSYS should have an additional feature to return the current monitor data base.? The SETNOD program should be enhanced to take that to compute the set difference with the new list.? This would show additions, renames and deletions. That would bring the update operation down from some hundred items to less than ten, on average.? This would obviously make more of a difference on huge DECnet's in the tens of thousands of nodes. Another NODE% feature should probably be to whack the entire monitor database except for the local node, which would be useful for trouble shooting. Last Sunday, the batch job failed with the following error: 18:33:40 USER?? SETNOD>*TAKE SYSTEM:NODE-DATA.TXT.0 18:33:40 USER 18:33:40 USER?? [Fork SETNOD opening <SYSTEM>NODE-DATA.TXT.1 for reading] 18:33:41 USER?? SETNOD>*SAVE 18:33:41 USER 18:33:41 USER?? [Fork SETNOD opening <SYSTEM>NODE-DATA.BIN.74 for reading, writing] 18:33:41 USER?? SETNOD>*INSERT 18:33:41 USER 18:33:41 USER *?SETNOD: Failed at node REACH* 18:33:41 USER?? SETNOD> I had a look at the SETNOD source and the HECnet node list and have discovered and concluded a few things.? First, there doesn't seem to be anything syntactically wrong with REACH::'s definition: "set nod 2.298 name REACH". Second, there don't appear to be any semantic issues.? 2.298 wasn't in use and it shouldn't matter if it was. In the case of INSERT, there are two kinds of errors from NODE%, a general failure of the JSYS and an incomplete insertion.?? The error is from the second case.? Unfortunately, SETNOD isn't reporting enough information about the error, so I have to make some changes there.? It's also possible that SETNOD is building an inconsistent database for the monitor to swallow; at least the LIST command is giving me some odd results, viz: SETNOD>list arEA 2 [AREA 2] A2RTR TOTAL NODES FOUND: 1 SETNOD> That's clearly wrong, viz: !i dec ?Local DECNET node: VENTI2.? Nodes reachable: 7. ?Accessible DECNET nodes are:??? A2RTR??? BOINGO LEGATO??? TOMMYT??? VENTI2??? VENTI??? ZITI The Exec output should probably be changed to say, "Nodes reachable in local area" and "Online nodes in area are:" Anybody have any ideas?? Hunches?? Clues? ------------------------------------------------------------------------ File 1) OLDF:[4,120]??? created: 1241 15-Apr-21 File 2) NEWF:[1,1]????? created: 0102 30-Apr-21 1)1???? set nod 44.9 name OSMIUM **** 2)1???? set nod 2.292 name OSIRIS 2)????? set nod 44.9 name OSMIUM ************** 1)1???? set nod 13.3 name RED **** 2)1 *set nod 2.298 name REACH * 2)????? set nod 13.3 name RED ************** 1)1???? set nod 2.298 name RSX11M 1)????? set nod 1.306 name RSX124 **** 2)1???? set nod 1.306 name RSX124 ************** 1)1???? set nod 42.5 name SPARKY **** 2)1???? set nod 2.291 name SPARK 2)????? set nod 42.5 name SPARKY ************** 1)1???? set nod 2.299 name THEPIT 1)????? set nod 35.70 name THOMAS **** 2)1???? set nod 2.299 name THEARK 2)????? set nod 35.70 name THOMAS **************

4 years, 2 months

4
9
0 0

T-Shirt

by supratim＠riseup.net

I don?t know if Jon Newton is in this group, but he pointed me to this t-shirt that may be of interest. https://curiousmarcs-store.creator-spring.com/listing/VAXinated?product=211 --- Supratim Sanyal, W1XMT 39.19151 N, 77.23432 W QCOCAL::SANYAL via HECnet > On Apr 22, 2021, at 5:31 PM, Dave McGuire <mcguire at neurotica.com> wrote: > > ?On 4/22/21 4:42 PM, Robert Armstrong wrote: >>> Dave McGuire <mcguire at neurotica.com> wrote: >>> .... schmutz in the slots. >> >> That's what you get for jimmying the cover interlock :) > > Heh. :) But, ah, no. We have everything as close to "as-shipped > perfect" as possible at the museum, and even in a personal setting I'm > WAY too anal to run a machine without proper covers. > > But when a BA32 sits in a dirty warehouse for twenty years, dust and > crap gets into those slots, top covers or not. > >> The ZIF slots, "no cables attached to the cards" and the "identical POST pass/fail LEDs on every card" features of BI are nice for working on, but it's a real problem for restoration. Anything that attached to some peripheral (DEBNT, KLESI-B, KDB50, DMB32, etc) required a special "transition header" that adapted the backplane to the cable set for that particular device. Spare BI cards are fairly easy to come by, but everybody has thrown away the transition headers and the cards are pretty much useless without them. > > Yes, it's awful. I have countless BI and XMI boards with no cab kits. > > DEC was clearly not planning properly for the surplus and aftermarket > for their machines. ;) > > -Dave > > -- > Dave McGuire, AK4HZ > New Kensington, PA

4 years, 2 months

2
1
0 0

Reading RT11 files under Windows or Linux

by bob＠jfcl.com

Is there a Windows utility that will read and write RT11 files from TU58, RX01/2 or RL01/2 images? A Linux utility would be OK too. I know about PUTR, but it doesn't appear that it can run under any recent (e.g. 64 bit) version of Windows.. And EXCHANGE on VMS works fine, but getting the image files on VMS in the first place is a hassle. Thanks, Bob

4 years, 2 months

10
43
0 0

Younger generations

by Keith.Halewood＠pitbulluk.org

With what was going on about RT11, I showed a much younger colleague some of the conversations on this list. Let?s just say that I fear for the future of the human race. Keith

4 years, 2 months

10
14
0 0

PyDECnet

by bqt＠softjar.se

For anyone running PyDECnet, I would recommend you update to the latest version (582), since that removes a behavior that triggered BQTCP to sometimes automatically block PyDECnet hosts. And of course, it you're running something way older, there are probably other improvements you'll also benefit from. And thanks to Paul Koning, who wrote this nice piece of software. 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

4 years, 2 months

6
16
0 0

Task Buillder question

by bob＠jfcl.com

Ok, this is a bit of an off the wall question, but - can Task Builder (aka TKB) build paper tape images in absolute loader format? Can anybody clue me in as to the magic switch(es) to do this? Thanks, Bob

4 years, 2 months

4
26
0 0

Use of Area 63 for Testing

by nf6x＠nf6x.net

MIM::DECNET.TXT states that area 63 is "Reserved for hidden area testing". Is area 63 routing suppressed by PyDECnet and/or any other methods of connecting to HECnet? If one were to play around with local nodes in area 63 without remembering to bring down the upstream HECnet connection, what would happen? I am interested in creating some useful semi-turnkey SIMH VAX instances to share with friends who are interested in playing with VAXen and/or connecting to HECnet, but are hesitant because of the learning curve involved. I figured it might be desirable to set up the simulations to use nodes in area 63 by default. I'll naturally want to test out intercommunication with my other simulations and real VAXen, and I'd like to understand whether I need to shut down my PyDECnet connection to HECnet while I am doing that. -- Mark J. Blair, NF6X <nf6x at nf6x.net> https://www.nf6x.net/

4 years, 3 months

6
9
0 0

Announcing TCP/IP V2.6 for RSX-11M-PLUS

by bqt＠softjar.se

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. This is version 2.6 of BQTCP/IP. It's been five months since the last official update, and there been various smaller improvements. Highlights: . Improved TCP performance. . Bugfixes in DNS subsystem. . Fixed various MAIL bugs that caused issues. . Improved MAIL performance, handling and features. . Added EPSV and EPRT to FTP and FTPD. . Improved TELNETD performance. Detailed information on things that have been done since the last release: TCP: . In TCP, Change IO.REJ to create a socket in Time Wait, so that we don't get multiple requests for something we reject. . Improved TCP congestion window handling. . Improved TCP retransmit recovery logic. . Correct TCP slow timer handling. If KAF is active, cancel timer. . Improve TCP sender. If the only thing motivating a send is a window update, we always delay it. . Added not starting new processes if pool is low. . Changed TCP PU.RXP option to always return partial data, independent of push flags. DNS: . Bugfix for resolver. If DNS resolving results in multiple answers, the resolver only handled the first answer correctly. . Bugfix for resolver. If a DNS response is received, which has an empty answer section, that is also an answer. . Improve resolver cache. If we get multiple identical answers, only cache one copy. TELNET/TELNETD: . Added timeout to telnetd console logging I/O. . Changed TELNET server to delay small sends. . Improved telnet server to not set push on data sent. . Improved telnet client to use PU.RXP when in binary mode. . Improved telnet client. If connecting to something else than port 23, assume we don't do telnet negotiations. However, if remote side start doing them, we will also start doing them. FTP/FTPD: . Added EPRT and EPSV handling to FTPD. Improve EPSV handling in FTPD. MAIL: . Improved mail reader screen handling. . Fix MAILD to remove temporary files if connection is dropped. . Improved MAILD SMTP receive parsing. . Fix various priv issues in mail reader causing notification problems. (Bugs reported by Kevin Jordan) . Added mail label handling in mail reader. . Bugfix in mail. FILE command filed wrong mail. . Added better handling of locked records in mail. . Improved mail submission processing to not wait until mail actually delivered before returning status. . Improved performance in adding mails to a mailbox. IPNCONFIG: . Updated IPNCONFIG.CMD for managing DECnet over IP connections. Contributed by Oleg Safiullin NETSTAT/RMD: . Changed port lists in RMD and NETSTAT to not include local address by default. . Change TCP state texts. Previous LISTEN is now ACCEPT. Previous SERVER is now LISTEN. BQTLIB: . Bugfix in BQTLIB. BP2 multiple IO code could misbehave. Some additional notes: As usual, I would recommend people to update as soon as possible. The changes are not critical, but will lead to a much better experience. For the RSX fixes to be applied, it is necessary to answer yes to the question about installing RSX patches. Otherwise those fixes will not be installed. This does not lead to any failures, but it might lead to some components not running exactly the way you might be expecting (such as daemons running under the wrong user). As usual, the distribution is available from: ftp://mim.update.uu.se/bqtcp.dsk ftp://mim.update.uu.se/bqtcp.tap ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk !!! BQTCP is also available through RPM !!! (As an additional note, I have become aware of that there is some device proxying access to the ftp service at Mim. This might lead to failure to transfer large files. If you observe such problems, try connecting to Mim at port 10021 instead, which is an alternative port for the ftp server, and which circumvents the proxy.) The documentation is also available through ftp on Mim, or also at http://mim.update.uu.se/tcpipdoc I hope people find this update useful. 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

4 years, 3 months

1
0
0 0

Old protocols in new ones

by Keith.Halewood＠pitbulluk.org

Hi, I might have posted this to just Paul and Johnny but it's probably good for a bit of general discussion and it might enlighten me because I often have a lot of difficulty in separating the layers and functionality around tunnels of various types, carrying one protocol on top of another. I use Paul's excellent PyDECnet and about half the circuits I have connecting to others consist of DDCMP running over UDP. I feel as though there's something missing but that might be misunderstanding. A DDCMP packet is encapsulated in a UDP one and sent. The receiver gets it or doesn't because that's the nature of UDP. I'm discovering it's often the latter. A dropped HELLO or its response brings a circuit down. This may explain why there's a certain amount of flapping between PyDECnet's DDCMP over UDP circuits. I notice it a lot between area 31 and me but but much less so with others. In the old days, DDCMP was run over a line protocol (sync or async) that had its own error correction/retransmit protocol, was it not? So a corrupted packet containing a HELLO would be handled at the line level and retransmitted usually long before a listen timer expired? Are we missing that level of correction and relying on what happens higher up in DECnet to handle missing packets? I'm having similar issues (at least on paper) with an implementation of the CI packet protocol over UDP having initially and quite fatally assumed that a packet transmitted over UDP would arrive and therefore wouldn't need any of the lower level protocol that a real CI needed. TCP streams are more trouble in other ways. Just some thoughts Keith

4 years, 3 months

8
28
0 0

CTAKAH IP address changed

by form＠pdp-11.online

Hi! CTAKAH node is moved to IP address 178.205.143.174. Please update IPNET/MultiNet configuration.

4 years, 3 months

2
1
0 0

Old protocols in new ones --> Anf10

by R.Voorhorst＠swabhawat.com

Yes, ANF10 also uses Ddcmp. On simh Anf10 also uses the Dmr/Dmc implementations. RV -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Saturday, 27 March, 2021 20:06 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Old protocols in new ones On 2021-03-27 18:59, John Forecast wrote: > >> On Mar 27, 2021, at 11:06 AM, Mark Berryman <mark at theberrymans.com >> <mailto:mark at theberrymans.com>> wrote: >> >> DDCMP was originally designed to run over intelligent synchronous >> controllers, such as the DMC-11 or the DMR-11, although it could also >> be run over async serial lines. Either of these could be local or >> remote. If remote, they were connected to a modem to talk over a >> circuit provided by a common carrier and async modems had built in >> error correction. From the DMR-11 user manual describing its features: >> DDCMP implementation which handles message sequencing and error >> correction by automatic retransmission >> > > No. DDCMP was designed way before any of those intelligent controllers. > DDCMP V3.0 was refined during 1974 and released as part of DECnet Phase > I. The customer I was working with had a pair of PDP-11/40?s, each > having a DU-11 for DECnet communication at 9600 bps. DDCMP V4.0 was > updated in 1977 and released in 1978 as part of DECnet Phase II which > included DMC-11 support. The DMC-11/DMR-11 included an onboard > implementation of DDCMP to provide message sequencing and error > correction. Quite frequently, customers would have a DMC-11 on a system > communicating with a DU-11 or DUP-11 on a remote system. Right. Smart controllers with DDCMP in firmware on the controller itself was definitely not the first implementation. But I don't have the full history of DDCMP as such. But it sounds reasonable that the original DECnet could have been using DDCMP already. But was that the first implementation of DDCMP? You mentioned V3.0, which would imply that there were even older versions since before DECnet. Did ANF-10 use DDCMP? Johnny > > John. > >> In other words, DDCMP expected the underlying hardware to provide >> guaranteed transmission or be running on a line where the incidence of >> data loss was very low. UDP provides neither of these. >> >> DDCMP via UDP over the internet is a very poor choice and will result >> in exactly what you are seeing. This particular connection choice >> should be limited to your local LAN where UDP packets have a much >> higher chance of surviving. >> >> GRE survives much better on the internet than does UDP and TCP >> guarantees delivery. If possible, I would recommend using one these >> encapsulations for DECnet packets going to any neighbors over the >> internet rather than UDP. >> >> Mark Berryman >> >>> On Mar 27, 2021, at 4:40 AM, Keith Halewood >>> <Keith.Halewood at pitbulluk.org <mailto:Keith.Halewood at pitbulluk.org>> >>> wrote: >>> >>> Hi, >>> I might have posted this to just Paul and Johnny but it?s probably >>> good for a bit of general discussion and it might enlighten me >>> because I often have a lot of difficulty in separating the layers and >>> functionality around tunnels of various types, carrying one protocol >>> on top of another. >>> I use Paul?s excellent PyDECnet and about half the circuits I have >>> connecting to others consist of DDCMP running over UDP. I feel as >>> though there?s something missing but that might be misunderstanding. >>> A DDCMP packet is encapsulated in a UDP one and sent. The receiver >>> gets it or doesn?t because that?s the nature of UDP. I?m discovering >>> it?s often the latter. A dropped HELLO or its response brings a >>> circuit down. This may explain why there?s a certain amount of >>> flapping between PyDECnet?s DDCMP over UDP circuits. I notice it a >>> lot between area 31 and me but but much less so with others. >>> In the old days, DDCMP was run over a line protocol (sync or async) >>> that had its own error correction/retransmit protocol, was it not? So >>> a corrupted packet containing a HELLO would be handled at the line >>> level and retransmitted usually long before a listen timer expired? >>> Are we missing that level of correction and relying on what happens >>> higher up in DECnet to handle missing packets? >>> I?m having similar issues (at least on paper) with an implementation >>> of the CI packet protocol over UDP having initially and quite fatally >>> assumed that a packet transmitted over UDP would arrive and therefore >>> wouldn?t need any of the lower level protocol that a real CI needed. >>> TCP streams are more trouble in other ways. >>> Just some thoughts >>> Keith >> > -- 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

4 years, 3 months

2
1
0 0

PyDECnet update

by paulkoning＠comcast.net

I just fixed a bug in PyDECnet that produces wrong routes if you use the --latency parameter on circuit configuration entries. The fix is rev 580. paul

4 years, 3 months

1
0
0 0

Orphaned node

by ales.petan＠digital.si

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

4 years, 4 months

3
2
0 0

I have a new baby.

by Keith.Halewood＠pitbulluk.org

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!

4 years, 4 months

3
3
0 0

Looking for old version of VMS

by lee.gleason＠comcast.net

? 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

4 years, 4 months

3
5
0 0

DECnet on VMS version3

by petermallan＠gmail.com

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

4 years, 4 months

3
4
0 0

DDCMP sync?

by paulkoning＠comcast.net

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

4 years, 5 months

4
3
0 0

No connectivity to arsgea 4

by mark＠wickensonline.co.uk

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

4 years, 5 months

13
33
0 0

GRE tunnel update...

by tim＠sneddon.id.au

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.

4 years, 5 months

9
21
0 0

Thousands of DECnet errors on Tops-20

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?

4 years, 5 months

5
42
0 0

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?

4 years, 5 months

1
0
0 0

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

4 years, 5 months

2
1
0 0

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

4 years, 5 months

4
5
0 0

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

4 years, 6 months

9
28
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet