HECnet

hecnet@lists.dfupdate.se

2 participants
15583 discussions

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

unsubscribe hecnet

by patrik.lidstrom＠gmail.com

5 years, 6 months

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, 7 months

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, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet