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.