- HECnet - lists @ Update

by bob＠jfcl.com

I've made some fixes to the DECnet/Linux NML server to bring it more in line with other DECnet implementations, and these are enough to make Paul's HECnet mapper happy with Linux nodes now. The only changes are to the dnetnml program, and you can download the new sources from LEGATO::dnetnml.zip. FWIW, my changes were made starting from Erik Olofsen's dnprogs-2.68 from http://rullf2.xs4all.nl/decnet/, but since the only thing that's changed is dnetnml, I don't think it matters much which DECnet/Linux release you are using. And fair warning - this will really only work if your DECnet/Linux machine is an end node. If your DECnet/Linux is a router then it will undoubtedly return some wrong answers (and you will also mostly likely have bigger problems than NML to worry about!). Thanks, Paul, for answering my questions and explaining stuff to me. Bob

5 years, 2 months

1
0
0 0

Cisco DECnet routers and NML

by roll＠stupi.com

The Cisco DECnet router implementation does not speak "decnet management" as we all knew. The way we are using them the tunnel end-points are on the Internet. Most of the information "missing" is actually available through the SNMP MIB, so if we could agree on a common read-only community and publish the IP addresses of those routers it would be possible to complete Paul's map.. Attached info. -P

5 years, 2 months

14
63
0 0

Fwd: Request for access to a VMS system

by bqt＠softjar.se

I got a request from someone. Not anyone I know, and since I don't normally have any VMS systems up and running, I can't really help. I'm sending it on here in case anyone feel generous in helping the guy out... Johnny -------- Forwarded Message -------- Subject: Request for access to a VMS system Date: Tue, 5 May 2020 16:49:12 -0700 From: Steven Schoch <schoch6 at gmail.com> To: Johnny Billquist <bqt at update.uu.se> Hello Johnny, I got your name from Eric Fair when I asked about a VMS system on a group. I long time ago I wrote a module (for an X Windows terminal) that would use a chat script to login to VMS using telnet. I haven't had access to a VMS systems for years, but a user of my script wanted to use it, and said it wouldn't work. So I'd like to troubleshoot it, but I don't have access to a VMS system. Would you be willing to give me temporary access, just long enough to test my login script? Thanks in advance. -- Steve -- 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

5 years, 2 months

1
0
0 0

FW: More NRT --> VMS and others

by R.Voorhorst＠swabhawat.com

From: R. Voorhorst [mailto:R.Voorhorst at swabhawat.com] Sent: Tuesday, 05 May, 2020 12:04 To: 'owner-hecnet at Update.UU.SE' <owner-hecnet at Update.UU.SE> Subject: RE: [HECnet] More NRT --> VMS and others Hi Thomas, I use NRT frequently on the older systems as CTERM does not work well with them; often bursty IO. On VAX/VMS, NRT usually works well, at least as host and cooperates well with Tops10/Tops20 Panda. Also on Rsx11M and Rsts 10.1. Sethost on Tops20 Panda to VMS however does not: sethost Escape character(^Y): Host name: swbv89 ? Communication with VMS not supported by SETHOST Even on OpenVms alpha 8.3 it works to vax, however with connection to tops10/20, the process crashes with an exception. Maybe it could be repaired on Alpha, but I doubt sufficient sources are around. You can test initial connect on Swbv55 on hecnet when it is up, as it is a VAX VMS 7.3 hecnet area router, though you cannot login on it (yet?). Best regards, R.V. From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE> [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis Sent: Tuesday, 05 May, 2020 07:14 To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE> Subject: [HECnet] More NRT What's fun about the Tops-20 NRT client (SETHOST) is that it doesn't do much aside from parsing for an escape character and node name. It builds a connection string and checks to make sure the remote system is either a 10 or a 20. Then it twiddles a few things on the terminal (a few more if you're running my changes to handle page mode). Finally, and this is the cool part, it issues an MTOPR% to directly connect the local user's terminal to the open DECnet connection (port 23). Thereafter, the client does nothing until the interrupt character is typed or the connection is broken. So response can be pretty snappy because you are never running in user space; no context switching. The CTERM client on the other hand is reading and writing data and otherwise handling the specifics of the protocol in user space. So, more overhead and more context switching. As an experiment, I removed the checks for Tops-10 and Tops-20 and tried connecting to a few hosts on HECnet. * Tops-20; TOMMYT and TWENEX worked (of course) * Tops-10; VENTI worked * RSX-11+; MIM accepted the connection and broke it as soon as I started typing. * VMS; LEGATO accepted the connection and broke it as soon as I started typing. * RSTS; TRON accepted the connection and then did nothing. It never broke the connection, but never displayed any banner or anything else. It appeared hung. So it would appear that NRT servers only exist on the 36 bit line. Perhaps it's possible to configure the service for other platforms? The first few RSTS systems I tried didn't appear to be online; MEZZO, PLUTO, RSTSE and BITXOT. The few Windows systems I checked didn't appear to be online, either; WXP, MISSY, KIBBEH and WATAN. I'm not sure if that means they refused the connection attempt outright.

5 years, 2 months

2
1
0 0

HECnet map

by paulkoning＠comcast.net

Gentlepeople, I've added a map maker to PyDECnet, which is now on-line on HECnet. It currently refreshes once every 24 hours, showing locations and paths between the locations. You can hover over the location markers to see nodes that have been recently observed, or click on the markers to see all nodes whether observed or not. Clicking on the connecting arcs will tell you which nodes have connections on that path. The map is here: http://akdesign.dyndns.org:8080/map You can also see a tabular display of the data collected by the network scanner, at http://akdesign.dyndns.org:8080/map/data . Right now that link isn't shown, I'll add that. Feedback would be welcome. There is no map legend yet. The button on the upper right is the "layers" tool that lets you chose among a number of map sources, and lets you turn the location and/or path information on or off. The default map is OpenStreetMap, and the mapping interface machinery is the Leaflet package, a very nice and easy to use tool. paul

5 years, 2 months

17
39
0 0

I'm not sure Paul got my email about locations...

by roll＠stupi.com

Spam Filter? >> *Subject: *Area 59... >> >> DIMMA is at Update in Uppsala >> >> STUPI R29GWA SOL at Stockholm >> 59?19'03.2"N 18?01'24.1"E, 59.317551, 18.023352 >> KRYLBO and 59.3 HOBBYH at Charlottesville, VA >> 38?09'10.9"N 78?33'26.3"W, 38.153026, -78.557299 You can park all other area 59 nodes at the Stockholm address. --Peter

5 years, 2 months

2
1
0 0

Proxy to VMS?

by paulkoning＠comcast.net

I've run into a glitch with the map maker, which wants to make NICE connections to other nodes without authentication information. Depending on the OS, there is a notion of "default account" or "proxy", and I expected that to work when I send the connect request off without any username/password content. Apparently that's wrong for VMS, and I very vaguely remember this but not what to do about it. On VMS, how can you set up a network object to allow access without a password? If you do this, what is required in the connect request coming in? paul

5 years, 2 months

5
8
0 0

Announcing TCP/IP for RSX-11M-PLUS

by bqt＠softjar.se

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. Highlights: . IP multicasting have been implemented . TCP stability improvements Detailed information on things that have been done since the last release: IP: . Added IP multicast support, and functions to enable this on UDP sockets. UDP: . Added functions for joining and leaving multicast groups on sockets. TCP: . Bugfix in TCP. Under some circumstances, TCP will stop receiving data because of a calculation error on TCP sequence numbers. . Improvement in TCP. Code accidentally sent unnecessary probes when a socket is in Close Wait. . Bugfix in TCP. Any ICMP error received for a socket caused the TCP connection to close down. This should not happen for ICMP source quench or ICMP timeout messages. . Correct MSS computation and setup based on interface MTU. IFCONFIG: . Added ability to change MTU of interface in IFCONFIG. FTPD: . Bugfix in FTPD. Long home directory names caused FTPD to fail. Some additional notes: Some people might wonder why the multicast changes have been introduced, but no other changes related to it. I wanted to get this change out now in order to allow people the possibility to play with it, if anyone is interested. For my own part, I next plan to look at mDNS, to allow RSX to live in home networks without a proper DNS server, but still be visible to other systems. mDNS depends on multicast groups. In addition, the TCP corrections finally fixed some long standing problems that I have been observing that have been very rare, but very annoying to me. BQTCP is now behaving very well on the network, and I do not actually have any known issues (at this time) that that are nagging me. I hope this release will see a further reduction on work on protocols like IP, TCP and UDP, and future work will be even more focused on higher level protocols. 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 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

5 years, 2 months

2
1
0 0

VMS/RSX Guest accounts --> 2020 memory extension

by R.Voorhorst＠swabhawat.com

L.S. The memory extension from 1 --> 2-->4 MW are quite easy to implement within the 2020 KS10 architecture, few extra mapping bits in the CPU and Unibus maps are all that is needed. Though in current hardware maybe a bit difficult: 2 more bits in the UBA rams, etc. in Simh it is easy to do. As Tops10 was developed onto KL10 and modified for KS10, the real limits of Tops10 was really the 4 MW barrier i.e. 13 bits versus 11 bits. The KS10 modifications were relatively simple to adapt to larger sizes, BOOT inclusive. R.V. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: Wednesday, 29 April, 2020 19:58 To: hecnet at Update.UU.SE Subject: Re: [HECnet] VMS/RSX Guest accounts On 4/28/20 11:51 PM, Thomas DeBellis wrote: > You know, I have been racking my brains from time to time and I can't > remember a thing about the ADP modifications to the 2020. I myself know very little about the specifics. (I'm mainly an -8, -11, and VAX guy) I would guess Peter Lothberg knows quite a lot about it. > Did you pick up any software with these little jewels? The monitor > changes might be interesting. No software, unfortunately. Just the iron. BTW, one of our museum folk is working on the 36-bit quote swag now. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

5 years, 2 months

2
1
0 0

VMS/RSX Guest accounts --> 2020 Unibus(ses) --> Tops20 V4/5

by R.Voorhorst＠swabhawat.com

L.S. By the way, I am pretty sure MRC attempted his variant of Tops20 (4.2? and 5.x?) on the 512 kB KS10 variant; the results might have turned out differently if he had a 1 MW variant available. Is this work preserved somewhere? R.V. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of R. Voorhorst Sent: Wednesday, 29 April, 2020 08:51 To: hecnet at Update.UU.SE Subject: RE: [HECnet] VMS/RSX Guest accounts --> 2020 Unibus(ses) L.S. Well, look in Tops10 monitor sources and in the engineering stuff: multiple Unibus adapters (up to 4, standard 2 provided) each which its own mapping hardware and registers. It can easily expanded to even handle 4 MW memory space (I run here some 2 MW variants), but the current Tops10 single section monitor cannot handle the needed page mapping in monitor mapping space very well. 1 MW works fine though. 1 MW variants surfaced somewhat later than the 512k ones. R.V. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Wednesday, 29 April, 2020 08:14 To: hecnet at Update.UU.SE Subject: Re: [HECnet] VMS/RSX Guest accounts I should point out that I actually suspect the 2020 have a Unibus map, just as the big PDP-11s or any VAXen have. Which then remaps the Unibus address space to the larger address space of the machine, so that DMA can go anywhere. Johnny On 2020-04-29 08:10, Johnny Billquist wrote: > Nope. Unibus can only address 128Kword, and in this context that is > 128K of 18-bit words. So you cannot even DMA into a full 256K of 36 bit words. > > Johnny > > On 2020-04-29 05:51, Thomas DeBellis wrote: >> You know, I have been racking my brains from time to time and I can't >> remember a thing about the ADP modifications to the 2020. >> >> So, the 2020 came with a maximum of 512K words, 2**9. An addition >> bit would have brought it up to a full megaword, 2**10, which is >> quite reasonable for the target audience (some kind of installation >> that didn't hold stock in the local power utility). >> >> I guess there may have been modifications to the 2020 build of the >> monitor to allow for the extra bit. I don't know if the Unibus >> devices could do DMA into the full address space. >> >> Did you pick up any software with these little jewels? The monitor >> changes might be interesting. >> >>> -------------------------------------------------------------------- >>> ---- On 4/24/20 12:12 AM, Dave McGuire wrote: >>> Nice! >>> >>> One of our 2020s is in the brown color scheme. You know what >>> that >>> means: ADP, and one more address bit. >>>> ------------------------------------------------------------------- >>>> ----- >>>> >>>> On 4/23/20 6:15 PM, Thomas DeBellis wrote: >>>> >>>> The solution for 4.1 was one of the finest hacks I have ever heard >>>> of; while the 2020 doesn't support extended addressing, it does >>>> support multiple address spaces, so what they did was move all the >>>> symbols into a separate address space. This was called 'hiding' >>>> symbols and I thought it was great because it made them harder to >>>> smash. However, all of that went out the window with 5.0, which >>>> fully supported extended addressing. > -- 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

5 years, 2 months

2
1
0 0

VMS/RSX Guest accounts

by tommytimesharing＠gmail.com

I've had my fill of FAL and DAP for the moment and have turned to some other things as sort of a 'break'.? The Tops-10 NFT client breaks on certain file names that the 20 sends it, so there is going to be some debugging to track that down.? Fortunately, a very patient person gave me PPN on one of their 10's. Right now, I'm working on bringing the Tops-20 mail system a bit more up to date with respect to DECnet communications.? These were largely put aside when full Internet connectivity happened. Still, the PANDA distribution has some bit rot because I know that certain Columbia changes for DECnet (to support CCnet) are not there.? I can't imagine that we didn't send them to MRC; that would have been unthinkable. Fortunately, I was able to remember enough to put some of them back so that I got SMTP over DECnet working well, again.? It had been suffering from about two minute timing delays and now it's instantaneous between 20's, like I remember.?? Oddly enough, I don't remember what else ran SMTP over DECnet; I'm certain that RSX and VMS could have done it.? I think some VMS site might have. However, most non-SMTP DECnet hosts on CCnet were running Mail-11, which the 20 also groks.? In fact, it can convert Mail-11 addresses to SMTP and route over other transports such as PUP, Chaos and TCP/IP as well as DECnet.? We did a lot of mail routing for CCnet to the Internet on CU20B, back in the day. Unfortunately, there is some bit rot in some of the Tops-20 Mail-11 code, so I've got some tinkering to do.? Does anyone have a VMS or RSX system that they'd care to give me a guest account on?? It doesn't need any special capabilities; I'm just going to be sending mail and looking a few raw headers over.

5 years, 2 months

10
41
0 0

VMS/RSX Guest accounts --> 2020 Unibus(ses)

by R.Voorhorst＠swabhawat.com

L.S. Well, look in Tops10 monitor sources and in the engineering stuff: multiple Unibus adapters (up to 4, standard 2 provided) each which its own mapping hardware and registers. It can easily expanded to even handle 4 MW memory space (I run here some 2 MW variants), but the current Tops10 single section monitor cannot handle the needed page mapping in monitor mapping space very well. 1 MW works fine though. 1 MW variants surfaced somewhat later than the 512k ones. R.V. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Wednesday, 29 April, 2020 08:14 To: hecnet at Update.UU.SE Subject: Re: [HECnet] VMS/RSX Guest accounts I should point out that I actually suspect the 2020 have a Unibus map, just as the big PDP-11s or any VAXen have. Which then remaps the Unibus address space to the larger address space of the machine, so that DMA can go anywhere. Johnny On 2020-04-29 08:10, Johnny Billquist wrote: > Nope. Unibus can only address 128Kword, and in this context that is > 128K of 18-bit words. So you cannot even DMA into a full 256K of 36 bit words. > > Johnny > > On 2020-04-29 05:51, Thomas DeBellis wrote: >> You know, I have been racking my brains from time to time and I can't >> remember a thing about the ADP modifications to the 2020. >> >> So, the 2020 came with a maximum of 512K words, 2**9. An addition >> bit would have brought it up to a full megaword, 2**10, which is >> quite reasonable for the target audience (some kind of installation >> that didn't hold stock in the local power utility). >> >> I guess there may have been modifications to the 2020 build of the >> monitor to allow for the extra bit. I don't know if the Unibus >> devices could do DMA into the full address space. >> >> Did you pick up any software with these little jewels? The monitor >> changes might be interesting. >> >>> -------------------------------------------------------------------- >>> ---- On 4/24/20 12:12 AM, Dave McGuire wrote: >>> Nice! >>> >>> One of our 2020s is in the brown color scheme. You know what >>> that >>> means: ADP, and one more address bit. >>>> ------------------------------------------------------------------- >>>> ----- >>>> >>>> On 4/23/20 6:15 PM, Thomas DeBellis wrote: >>>> >>>> The solution for 4.1 was one of the finest hacks I have ever heard >>>> of; while the 2020 doesn't support extended addressing, it does >>>> support multiple address spaces, so what they did was move all the >>>> symbols into a separate address space. This was called 'hiding' >>>> symbols and I thought it was great because it made them harder to >>>> smash. However, all of that went out the window with 5.0, which >>>> fully supported extended addressing. > -- 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

5 years, 2 months

1
0
0 0

Route20 Test

by supratim＠riseup.net

Johnny and all, Would it be possible to help me test Rob Jarratt's Route20? At this point, ROUT20 (31.1022) is configured as an additional Level-2 router for Area 31 not doing much beyond waiting to talk to other area routers. Johnny - do you think you could open up a port on your bridge for testing? This side is at 64.137.176.104 (static), port 4711. Anyone who owns an area and connects to Johnny's bridge using an area router can also perhaps set up a second bridge link to 31.1022 for testing. Here is my config file, followed by Rob's readme file. Hopefully I am not missing something basic here and such a test will be a really bad idea. --- $ cat route20.ini [node] name=ROUT20 level=2 address=31.1022 priority=5 [ethernet] interface=vde-decnet-tap1 cost=4 [bridge] address=psilo.update.uu.se:4711 port=4711 cost=7 ; DNS section is optional, if not present then there is no periodic check to make sure ; that IP addresses have not changed. Note that the periodic checks do not cause any delay ; as they are done asynchronously. [dns] address=8.8.8.8 poll=60 [logging] ethpcapline=verbose general=detail circuit=verbose line=verbose adjacency=verbose update=verbose decision=detail forwarding=verbose messages=detail dns=verbose ethinit=verbose ethcircuit=detail ethpcapline=verbose ethsockline=verbose ddcmpsock=detail ddcmp=verbose ddcmpinit=verbose sock=detail nsp=verbose nspmessages=verbose netman=verbose --- User Mode DECnet Router Readme ============================== This program is a DECnet router that implements version 2.0 of the DECnet routing specification found here: http://linux-decnet.sourceforge.net/docs/route20.txt Second Alpha Release 15th Sep 2012 --> Actually no, Rob updated it in March 2020 ---------------------------------- This second release has been successfully tested with another person in another area. It fixes the following bugs and limitations: 1. Implements Level 1 Routing messages and interoperates correctly with Level 1 routers ?? (ie routing nodes that are not area routers). 2. Packets routed from outside into the local area are no longer dropped. 3. More tolerant of different line end formats on the configuration file (ie DOS or non-DOS format). 4. Fixed some compiler warnings related to format strings. I have also realised that for every bridge connection you use you need a separate UDP port. I am not sure if this is a flaw or a feature. Features -------- 1. Runs on Windows either as a Windows Service, or as a console program. 2. Runs on Linux as a daemon. 3. Full routing capability, so it avoids broadcasting all routing messages to ?? entire network and kills looping packets. 4. Supports Ethernet (using pcap/winpcap). 5. Supports Johnny's bridge. You can now have multiple bridge connections to ?? Johnny and direct to other people without creating loops. 6. Can be extended to support other kinds of circuit (Cisco and Multinet might ?? be examples, not tried). 7. Does dynamic DNS updates without blocking. Limitations ----------- 1. Only tested on Windows Server 2003 and Raspberry Pi running Debian. 2. Does not support Phase III nodes. 3. Although it can be configured as a Level 1 node, it has only been tested ?? as a Level 2 (area router) node. 4. Limited testing on Raspberry Pi. 5. Performance not tested. Does not implement throttling, so traffic sent to ?? a machine with a slow network interface may experience problems. 6. Not tested with multiple ethernets. 7. It does not handle LAT and MOP, if you need these protocols then you still ?? need to use Johnny's bridge. Configuration ------------- The program expects a configuration file called route20.ini. A sample is provided, but here are some notes. An [ethernet] section is used to define an Ethernet network interface. You can have as many [ethernet] sections as you have ethernet network interfaces. A [bridge] section is used to define an interface compatible with Johnny's bridge. You can have as many [bridge] sections as you have direct links to other people's bridge or router (each requires a separate port). Use a DNS name rather than an IP address, the IP address is checked and updated according the [dns] section. Note also that the router will not accept packets from bridges not configured in the [bridge] section. The [dns] section is used to specify the IP address of your DNS server. This must be a numeric IP address. The poll period determines the period (in seconds) of the checks for changes to the IP address in your [bridge] sections. Windows Installation -------------------- Prerequisites: winpcap To install it as a service do the following: 1. Open a command prompt as an administrator. 2. Run "route20 install". 3. Copy the configuration file to %windir%\system32 4. Make sure the "DECnet 2.0 Router" service is configured to run under an ?? account that has administrative privileges. 5. Start the service. To run it as a console program: 1. Create a configuration file in the directory where the executable is ?? located. 2. Run the executable. Linux Installation ------------------ Prerequisites: pcap The program is designed to run only as a daemon. It logs to the syslog. Launch the program and it will fork and create a daemon. -- Supratim Sanyal, W1XMT 39.19151 N, 77.23432 W QCOCAL::SANYAL via HECnet

5 years, 2 months

3
5
0 0

Lightcycle FORTRAN Source

by supratim＠riseup.net

Does anyone have the FORTRAN source for Lightcycle (the game) that can be sent to me somehow - VAX mail to MARIAH::SYSTEM will work fine ... I had collected it from someone kind enough to send it to me circa 2015, lost it, shame on me. Thanks in advance, Supratim -- Supratim Sanyal, W1XMT 39.19151 N, 77.23432 W QCOCAL::SANYAL via HECnet

5 years, 2 months

4
9
0 0

Apparently good news from VSI

by Keith.Halewood＠pitbulluk.org

Hi, Via Process Software email (Multinet), it looks like VSI have a community licence scheme for VMS in the making. Keith

5 years, 2 months

11
24
0 0

FW: [Hobbyist-Users] Re: Good news from VSI

by Keith.Halewood＠pitbulluk.org

FYI From: Hunter Goatley [mailto:goathunter at goatley.com] Sent: 22 April 2020 15:10 To: Hobbyist-Users at lists.process.com Subject: [Hobbyist-Users] Re: Good news from VSI Sorry for the second message, but I wanted to clear up a couple of questions I've gotten. The text I sent came from VSI's website: https://vmssoftware.com/new/about/news/ Someone asked me if this would include VAX hardware. I know no more about VSI's plans than what is on their website, but to my knowledge, VSI does not have the rights to the VAX code, nor do they physically have the VAX code. I'm assuming that VAX hardware will not be included, but since VSI has not released any more details, I have no idea for sure. I hope something is done by HPE and/or VSI to allow VAX hardware to still be used. Time will tell. Hunter

5 years, 2 months

1
0
0 0

I have found how to recover the TOPS-10 Fortran V11 patch decryption keys

by gerry77＠mail.com

Since here too there are some TOPS-10 users, I am pleased to announce that I have found a way to recover the long-missing TOPS-10 Fortran V11 patch decryption keys. Find below a copy of the post I just sent to alt.sys.pdp10. HTH, :) G. ===== Dear all, as many of you may know, the TOPS-10 Fortran V11 tape image available in the usual repositories is truncated because the original tape reel from which it was sourced (BB-D480G-SB) was found to be damaged. Luckily enough, the first four savesets (out of seven) were indeed readable, therefore the V11 compiler is in fact available. Unfortunately, one of the missing savesets (the seventh) contains the keys required to decode TSU tape patches. Therefore, even if TSU tapes are available and completely readable, their contents could not be used because they are encrypted. Nonetheless, after much pondering and careful observing, and thanks to some good guess, I was able to reconstruct the most important missing keys :) Since both TOPS-10 and TOPS-20 Fortran compilers share the vast majority of their sources, my first idea was to build the updated TOPS-10 Fortran compiler from scratch with TOPS-20 sources from the latest TSU tape, but I soon found it to be a too complex task because, among other things, some TOPS-10-specific sources were missing. I would have had to use those from some old field test tape available in the repository, but I was afraid that the resulting compiler (if buildable at all) could have been a weird bug-ridden hybrid. So I had to find a different route. Since I was there, I also verified that TOPS-20 keys (which have always been available) do not work with TOPS-10 products. By observing the keys for other products I noticed that they are wildly different in size and are usually pretty large, some are several hundred blocks long, therefore I speculated that the encryption may have been just some simple XOR of keys and sources. This means that XORing any cleartext file with its corresponding encrypted version yields the key. Since I could not directly recover the key for the patched compiler binaries because I didn't have a suitable cleartext copy of any encrypted binary, I had to follow a more circuitous route. The solution comes from the fact that, as I said above, TOPS-10 and TOPS-20 Fortran compilers share the vast majority of their source files, which also happen to be among the largest of the whole Fortran distribution. Also, most important, the updated runtime sources come with their respective compiled counterparts, i.e. REL files. Finally, runtime binary modules are contained in the runtime sources saveset, whereas the resulting library is contained in the binaries saveset. So, here is a summary of the required steps. 1. First of all, on TOPS-20, restore the TOPS-20 Fortran V11 runtime key, namely FORLIB.KEY, from the product distribution tape BB-4157J-BM. 2. Then, still on TOPS-20, restore the largest updated source of the Fortran V11 runtime and the decryption tool, namely FOROPN.MAC and DCRYPT.EXE, from TSU tape 04 (volume 1 of 2) BB-PENEA-BM. 3. Then, again on TOPS-20, use DCRYPT to obtain a plaintext version of FOROPN.MAC, and call it e.g. FOROPN.T20. 4. Finally, transfer FOROPN.T20 to TOPS-10. If you do not have a working DECnet network available you could use a tape image. The standard TOPS-20 backup program, DUMPER.EXE, could write (and read) TOPS-10 BACKUP tapes when instructed to do so with the INTERCHANGE command. Note that the same INTERCHANGE command in TOPS-10 BACKUP.EXE has another (unrelated) meaning. 5. Now on TOPS-10, restore the original (unpatched) TOPS-10 Fortran V11 runtime files from the truncated tape BB-D480G-SB. In fact they are in the fourth saveset, i.e. the last readable one. Then, in the same directory, restore the updated Fortran runtime files from TSU tape 04 (volume 3 of 3) BB-PBDED-BB. The directory on tape is DSKB:[10,7,FTNOTS]. Several old files will be overwritten with new patched and encrypted updated copies. 6. Restore tools APUTIL.EXE and DCRYPT.EXE from TSU tape 04 (volume 1 of 3) BB-BT99V-BB. APUTIL and DCRYPT do basically the same thing, but APUTIL is list-driven and could verify checksums, whereas DCRYPT does just one file at a time and does not perform any check. 7. Then restore (or make available) the FOROPN.T20 file created on TOPS-20 and "misuse" DCRYPT to obtain the runtime key. Since the encryption is a simple XOR and DCRYPT luckily does not distinguish among encrypted, plain, and key files, just feed it with FOROPN.MAC (which is encrypted as it came from the TOPS-10 TSU tape) when it asks for some encrypted file, and FOROPN.T20 when it asks for a key. Call the resulting file FTNOTS.KEY. |.r [,,tsu]dcrypt | | [DCRYPT version 1(3)] | Dcrypt>decrypt foropn.mac foropn.t20 ftnots.key | Decrypting DSK:FOROPN.MAC | with DSK:FOROPN.T20 | calling it DSK:FTNOTS.KEY ...[OK] | | Dcrypt> 8. Now, with our new key, we can use APUTIL to decrypt every runtime file. APUTIL reads file names from a VFY file and is able to distinguish between encrypted and non-encrypted files. Therefore in decrypt mode it will only work on encrypted files, whereas in verify mode it will work on all files. If the VFY file and the KEY file have the same name, it's all automatic. | .r [,,tsu]aputil | | APUTIL>read ftnots.vfy | [Reading DSKB:FTNOTS.VFY[1,2,FTNOTS]] | APUTIL>decrypt | [Decrypting DSKB:[1,2,FTNOTS] using key file DSKB:FTNOTS.KEY[1,2,FTNOTS]] | B10FRS.CTL has been decrypted | FDDT.MAC has been decrypted | FORCHR.MAC has been decrypted | . . . | MTHDUM.REL has been decrypted | MTHPRM.UNV has been decrypted | FORDDT.REL has been decrypted | [Decrypted 25 of 94 files, 0 errors, 0 checksum errors] | APUTIL>verify | [Verifying DSKB:[1,2,FTNOTS]] | B10FDT.CTL has been verified | B10FRS.CTL has been verified | F10LIB.CCL has been verified | . . . | MTHTRP.MAC has been verified | MTHTRP.REL has been verified | FORDDT.REL has been verified | [Successfully verified 94 of 94 files, 0 errors, 0 checksum errors] | APUTIL> 9. At this point we are ready to create our updated runtime library. Run MAKLIB and feed it with F10LIB.CCL. This will create a new and updated FORLIB.REL in the current directory, which will be the picklock to recover the compiler binaries key. Let's rename it to something like FORLIB.NEW. | .r maklib | | *(a)f10lib.ccl | | *^Z | | .rename forlib.new=forlib.rel | Files renamed: | DSKB:FORLIB.REL 10. Now, in another directory, restore the updated and encrypted compiler binary files from TSU tape 04 (volume 3 of 3) BB-PBDED-BB. The directory on tape is DSKB:[10,7,FTNSYS]. Copy to the same directory FORLIB.NEW from the previous step and feed it to DCRYPT.EXE together with FORLIB.REL (encrypted, coming from the TSU tape) to obtain FTNSYS.KEY in the same way as above. 11. Now run APUTIL to decrypt and verify the binary compiler files, that is our final target. | APUTIL>read ftnsys.vfy | [Reading DSKB:FTNSYS.VFY[1,2,FTNSYS]] | APUTIL>decrypt | [Decrypting DSKB:[1,2,FTNSYS] using key file DSKB:FTNSYS.KEY[1,2,FTNSYS]] | FORDDT.REL has been decrypted | FORLIB.REL has been decrypted | FORO11.EXE has been decrypted | FORTB.EXE has been decrypted | FORTC.EXE has been decrypted | FORTD.EXE has been decrypted | FORTE.EXE has been decrypted | FORTF.EXE has been decrypted | FORTG.EXE has been decrypted | FORTRA.EXE has been decrypted | [Decrypted 10 of 10 files, 0 errors, 0 checksum errors] | APUTIL>verify | [Verifying DSKB:[1,2,FTNSYS]] | FORDDT.REL has been verified | FORLIB.REL has been verified | FORO11.EXE has been verified | FORTB.EXE has been verified | FORTC.EXE has been verified | FORTD.EXE has been verified | FORTE.EXE has been verified | FORTF.EXE has been verified | FORTG.EXE has been verified | FORTRA.EXE has been verified | [Successfully verified 10 of 10 files, 0 errors, 0 checksum errors] | APUTIL> :) The same trick, but with REVHST.MAC instead of FOROPN.MAC, could be used to recover the compiler sources key, although it will not decrypt a couple of files because they are longer than REVHST.MAC and some other unpatched files will not pass the checksum verification because the originals are missing (they were stored in the unreadable section of the product distribution tape) and those from the field test tape I had to use are different. At the moment I have no fresh data at hand, but if my notes are correct it worked for 253 out of 258 files, i.e. only 5 files didn't pass the checksum test, and of those only 2 are actual source files. I hope you'll find all of this useful and amusing as much as I did, :) G.

5 years, 2 months

3
2
0 0

Announcing TCP/IP for RSX-11M-PLUS

by bqt＠softjar.se

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. Highlights: . Added IGMP . mDNS have been implemented . Bug fixes and enchanced functionality in UDP . Performance and stability improvements in TCP . Improved Multinet driver . Stability improvements in HTTP with CGI . Bugfix for FTP/FTPD regarding files with implied CRLF . Improved SPOOF handling of blocking whole subnets Detailed information on things that have been done since the last release: IP: . Added ability to not loopback broadcast or multicast packets. IGMP: . Added IGMP protocol handler. UDP: . Added ability to not loopback broadcast or multicast packets. . Bugfix. The multicast related functions would crash the system if the argument had an odd address. TCP: . Improved fast retransmit logic, which did not work right. . Improved TCP probe handling. . Bugfix. If large amounts of data was being sent in PU.TXT mode, and the data consisted of all NULs, the system could crash. mDNS: . mDNS have been implemented. Multinet: . The Multinet driver have been redesigned to improve compatibility with VMS. PING: . Added /NOLOOPBACK switch to avoid loopback of broadcast or multicast packets. NETSTAT: . Added the switch IGMP among the other statistics switches, and output. HTTPD: . Bugfix: The CGI handling could leave the HTTP task hung forever for some badly formed requests. FTP/FTPD: . Bugfix. If a file was transferred in binary mode, and had attribute implied CR+LF, the CR+LF was lost. SPOOF: . Improved SPOOF detector to better block whole netblocks. Some additional notes: For people who don't know what mDNS is, it is a way of resolving host names to IP addresses on a local network without having to setup any DNS server. It works by using the special domain ".local". So if you have a machine called "foo", and your machines are all mDNS capable, you can reach the machine "foo", by addressing it as "foo.local" on your local network. No additional configuration is needed. This is all part of the IP zero configuration framework. 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 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

5 years, 2 months

4
4
0 0

Oscar

by supratim＠riseup.net

Is anyone here in communication with Oscar Vermeulen? The last communication with me was on March 17 just after he drove back from Holland. He is usually a prompt and casually chatty fellow, Thanks Supratim --- Supratim Sanyal, W1XMT 39.19151 N, 77.23432 W QCOCAL::SANYAL via HECnet

5 years, 2 months

3
3
0 0

VAX/Smalltalk-80

by nw＠retrocomputingtasmania.com

See below for a link to a g-drive file containing a ZIP archive of the DEC research group implementation of Smalltalk for the VAX. If someone has a VT125 to try it on I would appreciate seeing an image of the screen with Smalltalk running. Begin forwarded message: > From: Nigel Williams <nw at retroComputingTasmania.com> > Date: 7 April 2020 at 10:33:55 pm AEST > To: John Ames <commodorejohn at gmail.com> > Subject: Re: VAX/Smalltalk-80? > > ? >> >>>> On 2 Apr 2020, at 10:08 am, John Ames via cctech <cctech at classiccmp.org> wrote: >>> I know from the book "Smalltalk-80: Bits of History, Words of Advice" >> >> Thanks for the reminder about the VMS version, as you likely know >> their paper about VAX Smalltalk was in an early DEC Technical Journal >> too. >> >> ...while the second ran under VMS and was actually developed >> within DEC. This version - VAX/Smalltalk-80 - was headed up by Stoney >> Ballard and Stephen Shirron; anybody know if there's a surviving copy >> out there, if it was ever available outside DEC to begin with? > > I contacted Stephen and he kindly provided a ZIP > > https://drive.google.com/open?id=1NvO-ULropJ9xyT-WFqalXY79FBt6tdfB > > I had a quick look and it will need an early VMS I suspect, around > version 4.x (might work on a later version). > > cheers, > nigel.

5 years, 3 months

14
34
0 0

VAX/Smalltalk-80

by mark＠wickensonline.co.uk

Success! https://photos.app.goo.gl/U4PyEtDX1YLxGmWS7 Regards, Mark. M0NOM <https://www.qrz.com/db/M0NOM/P>

5 years, 3 months

3
3
0 0

unsubscribe hecnet

by patrik.lidstrom＠gmail.com

5 years, 3 months

1
0
0 0

Multinet for VMS?

by bqt＠softjar.se

In order to better debug and develop my Multinet compatible link for RSX, I think should set up a VMS box locally with Multinet. I do have a VAX or two around, which currently are running TCPIP services from HP. So, how do I switch? I've never actually used Multinet before. Where do I find it? How do I get a license? Anything in particular I should be aware of when installing it? 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

5 years, 3 months

5
6
0 0

TCP/IP Services for OpenVMS Version 5.3

by steve＠davidson.net

Does anyone know where I can find this version of the kit? I would like to add IMAP support to the STRGTE:: cluster. Thanks! -Steve Steve Davidson Hollis, NH (US) STRGTE::SYSTEM or STRGTE::DAVIDSON

5 years, 3 months

8
14
0 0

Bringing up a MicroVAX 3100-80

by supratim＠riseup.net

I have obtained a MicroVAX 3100-80 with a Storageworks pizza box, a CD-ROM drive, a tape drive, some cables and no monitor. It powers on, does not smoke or explode. The 8 LEDs at the back settle down to all on except 2 and 3 counting from zero on the right. I can hear a hard disk spin up. The cables include two MMJs. I have a PC with a 9-pin female serial connector. It runs Linux. The first two of many questions: does the ?0? connector connect to the console? What exactly do I need to do to connect the PC?s serial port to the MMJ cable? Note: I have passable soldering skills. Next question will be about the BNC connector and networking. One thing at a time. Here are some pictures: https://photos.app.goo.gl/KduorZEimMQ73bMdA Thanks in advance Supratim --- Supratim Sanyal, W1XMT 39.19151 N, 77.23432 W QCOCAL::SANYAL via HECnet

5 years, 3 months

18
54
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet