As we've noted earlier, the operating system numbers are not consistent between terminal transport and DAP.  Your numbers correspond to the DAP 5.6 specification as far as it goes, viz:

                          Value     OS Type

                            0       Illegal
                            1       RT-11
                            2       RSTS/E
                            3       RSX-11S
                            4       RSX-11M
                            5       RSX-11D
                            6       IAS
                            7       VAX/VMS
                            8       TOPS-20
                            9       TOPS-10
                           10       RTS-8
                           11       OS-8
                           12       RSX-11M+
                           13       COPOS/11 (TOPS-20 front-end)

I wish I hadn't sent out my last email because P/OS was staring me right in the face...  I don't recall there being any COPOS/11 on any Tops-20 front end.  The master DTE ran RSX20F, the RJE ran DN60 code and the Phase III DN20's ran what I thought was called "MCB".

The Tops-20 DAP library has the following operating system numbers which partly correspond to yours.  By this, I mean they are table offsets which are used to pick the default mode.  Assuming the following:

        .OSRT==1        ;RT-11
        .OSRST==2       ;RSTS/E
        .OSRXS==3       ;RSX-11S
        .OSRXM==4       ;RSX-11M
        .OSRXD==5       ;RSX-11D
        .OSIAS==6       ;IAS
        .OSVAX==7       ;VAX/VMS
        .OSTP20==10     ;TOPS-20 (^D8)
        .OSTP10==11     ;TOPS-10 (^D9)
        .OSOS8==12      ;OS-8 (^D10)
        .OSRXP==13      ;RSX11-M PLUS (^D11)

It would appear that there is a conflict in the list in the PDP-8 entries and RSX-11M+.  If MIM:: is reporting decimal 11 (octal 13), the right thing from my list, then it is reporting itself as a PDP-8 running OS-8 according DAP 5.6.

So... go with what MIM:: says, not what is documented?

Hmm. Oops. I have to correct myself, as well as Thomas.
Looking at the RSX code, the system types are defines as such:

;       OSTYPE(1):B             Operating system type
;
OS$RT 'B'= 1                    ; RT-11
OS$RST'B'= 2                    ; RSTS
OS$11S'B'= 3                    ; RSX-11S
OS$11M'B'= 4                    ; RSX-11M
OS$11D'B'= 5                    ; RSX-11D
OS$IAS'B'= 6                    ; IAS
OS$VMS'B'= 7                    ; VAX/VMS
OS$T20'B'= 8.                   ; TOPS-20
OS$T10'B'= 9.                   ; TOPS-10
OS$RTS'B'= 10.                  ; RTS-8
OS$OS8'B'= 11.                  ; OS-8
OS$MPL'B'= 12.                  ; RSX-11M-PLUS
OS$COP'B'= 13.                  ; COPOS/11
OS$POS'B'= 14.                  ; P/OS          *** V6.0 ***
OS$ELN'B'= 15.                  ; ELAN          *** V7.0 ***
OS$CPM'B'= 16.                  ; CP/M          *** V7.1 ***
OS$MSD'B'= 17.                  ; MS-DOS
OS$U32'B'= 18.                  ; Ultrix-32
OS$U16'B'= 19.                  ; Ultrix-11
OS$MAX'B'= 19.                  ; Highest legal OS
OS$DTF'B'= 20.                  ; DTF/MVS       *** V7.2 (TBS) ***

So, RSX-11M-PLUS is 12(10), not 13(8). 13(8) is OS/8. And I have no clue what COPOS/11 is.

And I also find is "strange" that OS$MAX is 19, and then you have OS$DFT at 20. I guess if that pops up, it will considered unknown. Half-finished work maybe?

And with that said, if FAL in RSX is built, or run on 11S, it will indeed set the OS type to 3.
Not sure what you'd do through that FAL though. But it's definitely possible based on the code.

  Johnny

On 2022-10-20 20:10, Johnny Billquist wrote:

Yes. RSX-11M and RSX-11M-PLUS have different IDs, and yes, MIM is M+, and thus sends 13(8).

   Johnny

On 2022-10-20 03:05, Thomas DeBellis wrote:

I recently had a number of connectivity issues that caused me to review my DECnet related batch jobs.  The following is a snippet from the log file of GETNOD, which is the weekly batch job that fetches the latest HECnet node list from MIM::.  I had updated it in part because of trouble-shooting, but the change isn't dramatic--it's rather more of a 'buff and polish'.  The items in red are of note:

    20:31:21 MONTR   $@NFT
    20:31:21 USER   NFT>*SET DEFAULTS MIM:: /USER:
    20:31:21 USER   NFT>*SET DEFAULTS MIM:: /PASSWORD:
    20:31:21 USER   NFT>*SET DEFAULTS MIM:: /ACCOUNT:
    20:31:21 USER   NFT>*SET DEFAULTS MIM:: /OSTYPE:RSX11  ;<-- NEW
    20:31:21 USER   NFT>*DIR MIM::FIX.T20;0
    20:31:21 USER
    20:31:21 USER   [Fork NFT opening DCN:MIM-FAL for reading, writing]
    20:31:23 USER %Remote OS type /different/ from that specified with
    SET DEFAULT
    20:31:23 USER
    20:31:23 USER     MIM::DU1:[DECNET]
    20:31:23 USER   FIX.T20;161;P775656             18 35840(8)
    18-Oct-2022 09:59:43

There is nothing fatal about the message, but it was surprising. Investigating the parse table for OSTYPE in NFT.MAC shows:

    OSTTBL: XWD OSTSIZ,OSTSIZ               ;ARGUMENTS FOR /OSTYPE
             T (IAS,.OSIAS)                  ;Operating system type
    ;       T (OS-8,.OSOS8)
             T (RSTS,.OSRST)
             T (RSX11,.OSRXM)
             T (RT11,.OSRT)
             T (TOPS10,.OSTP10)
             T (TOPS20,.OSTP20)
             T (VMS,.OSVAX)

So the above shows only a single RSX parse item and I had wondered about that, given all the various flavors of RSX. Further investigation into DAPSYM.MAC shows what Tops-20 DAP actually knows about (in octal).

         .OSRT==1        ;RT-11
         .OSRST==2       ;RSTS/E
         .OSRXS==3       ;RSX-11S
         .OSRXM==4       ;RSX-11M
         .OSRXD==5       ;RSX-11D
         .OSIAS==6       ;IAS
         .OSVAX==7       ;VAX/VMS
         .OSTP20==10     ;TOPS-20
         .OSTP10==11     ;TOPS-10
         .OSOS8==12      ;OS-8
         .OSRXP==13      ;RSX11-M PLUS

That's more like it, I would assume.  So I guess the fix here is to put a few more entries into the NFT parse table.

Johnny, which one of the above is MIM:: reporting?  I guess 13?