Oh, I don't think you could claim the exclusive mantle of amusing one's self with weird things, years after the fact and I know that you wouldn't want to.

The pity is that this is how the state of the art was sometimes advanced, back in the day.  The story of IBM's VM immediately comes to mind.  For DEC, where customers had source, you would often see somebody getting annoyed with a particular feature, misfeature or un-feature and wind up implementing it.  And then spend years trying to get DEC to adopt the fix.

At least for Tops-20, it has been gotten up to date enough that I have been successfully use it for regression tests or to prove that a problem exists.  Ideas still have a way of getting around sometimes.

This is a hobby and we do what amuses us and change what annoys us (one hesitates utter 'fix' without forethought).  This leads to the DeBellis Theory of Delayed releases:
  1. It is more fun to start wring code than to fully finish writing code.
  2. It is more fun to have several things going on instead of focusing on completion of one sole thing.
  3. Numbers 2. and 3. are more fun than creating a comprehensive test battery (I'm thinking UETP)
  4. Packaging a fully tested release is tedious
  5. Unless you happen to have a spare degree in literature, nobody wants to write documentation.
    1. Ever
    2. Even they are threatened with payment

I've got a big pile of things to document.  Even when I write the manual concurrently with the implementation (which I did for the Tops-20 FAL anonymous functionality), it remains on the pile to somehow package up.

There is some sense of urgency for me.  MRC died long before anyone would have ever expected.  A very grievous loss for me personally, because I lost an excellent technical resource, proof-reader, critique (oh boy...) and somebody to keep the release package up to date.

On 1/24/22 12:46 AM, Johnny Billquist wrote:

Ok, it's highly unlikely that anyone cares, but just in case I am posting this anyway.

When using RSX-11M-Plus, if you write a program that uses the Datatrieve-11 callable interface over DECnet, your program cannot use DECnet itself for anything in parallel. Which sucks. I've just done some changes to the Datatrieve-11 call interface library, so that this is now possible to do. Ping me if you want to know more.

I've also written a nice interface from PDP-11 C, which makes it pretty easy to use both Datatrieve-11 and DECnet.

The weird things I amuse myself with, 20 years after anyone stopped caring.

I should probably start writing somekind of manual with how to do these things that are not obvious, might not be documented, or that I might have fixed over the years...

  Johnny