Interesting; I was wondering why you picked a special number?  I would imagine that most implementation wouldn't know it and maybe Ultrix-32 (OS$U32==^D18) might have been a better choice?  Ultrix-32 is of interest as its NRT is compatible with Tops-10/Tops-20 and has the same OS type number.

I ought to update my spreadsheet to see how the Tops-20 NRT numbers now align with the fixed DAP numbers.

Is there an implementation of your DAL on HECnet?  I'd be happy to see if Tops-20 FAL/NFT/DAP chokes on it.  Considering Paul's previous points about OS type, one assumes it should not be failing (if it does).

The Tops-10 and Tops-20 NFT/FAL/DAP implementations do not appear to share the same code base.  That's of interest because a number of the DECnet transport monitor modules do.  Phase II NICE doesn't.  Later NICE is written in BLISS, which is suggestive, but it was never released to my knowledge.

I'm not sure if it's 'unfortunate'.  They might have because Tops-20 NFT/FAL/NFT are GLXLIB based and could maybe be enhanced to run on both operating systems.  'Enhanced' does not necessarily imply a trivial amount of work as the OS calls and job structures are quite different as are the file systems.  GLXLIB does a good job against shielding you against the latter.

The job structure (I.E., how you run FAL) is vastly different.

---

On 11/21/22 12:02 PM, John Forecast wrote:

Agreed. The original FAL on DECnet for Linux claims to be VMS. I wrote an alternative FAL (FAL2) to provide simple sequential file access which claims to be LINUX by using one of the reserved for user-specified operating systems values (192), mostly just to see if it caused any problems. So far, only TOPS-10 had issues - it will fail to connect if it does not recognize the operating system type. I don’t think I had a TOPS-20 system at time to test with.

  John.