Hello Paul,

Thanks for the detailed and, as always, very informative response!

In retrospect, perhaps some of my wording is unfortunate and/or insufficient.  Let me try to clarify/elaborate:

On Nov 20, 2022, at 11:09 PM, Thomas DeBellis <tommytimesharing@gmail.com> wrote:

So MIM:: is sending an OS Type of 12, just like it's supposed to, and Tops-20 doesn't recognize this.  The recovery works well enough, it seems, Tops-20 DAP merely whining, but carrying on.  So I'll fix that. [...]

On 11/21/22 9:25 AM, Paul Koning wrote:

I may have said this before, but....  applications like FAL should NOT base decisions on the received type codes.  Those are actually a protocol design error; use them only for informational displays.


    

    
Yes, you've said it and I think maybe more than once.  This is an
      important point and I don't disagree.  Hardly.  You may recall
      that, based on your observation, I changed Kermit-20 (and SETHOST, I think) to check the NRT protocol type instead of the OS
      Type.  There, I only use the OS Type to print nice informative
      messages.

    

    
For what it's worth, neither Tops-20 NFT nor FAL have any VMS
      specific code.  NFT will parse an OS Type keyword, yet it does
      nothing but hand the OS Type code to DAP.  Historically, DAP
      largely used that information to handle how the VAX was acting
      incorrectly with the apparent tacit understanding that the
      behavior would be remediated.  Edit 106 is instructive:

    

      
The maximum value of DPMXM was lowered to ^d1636 if the
          user said /OSTYPE:VMS in SET DEFAULT.  This is the largest it
          can be and still allow VAX FALs to function if the VAX users
          accounting file allows BYTLM to default to 4K. If BYTLM is too
          small for DPMXM, then the VAX FAL hangs.  If all VAX users
          have BYTLM raised, then DPMXM can also be raised. Doing this
          provides better performance.  Note that the next release of
          VMS FAL should include a patch to solve this problem.  When
          NFT/FAL-20 is shipped with DECnet-20 Phase III this patch
          should be removed.

      

    

    
This was, in fact, eventually removed as part of Edit 161, viz:

    

    

      
Remove edit 106 to DAPLIB which compensated for BYTLM being
          too small on a VAX/VMS account prior to DECnet-VMS V.3.1 and
          VMS V3.4.  This eliminates "data overrun" errors seen when
          transferring files from a -20 to VAX running VMS V3.4 or
          greater.

      

    

    
Among other things, OS Type byte is still used to pick the
      default file mode, viz:

    

      
.MD1==^D1      ;/IMAGE

        .MD2==^D2      ;/IMAGE/FIXED

        .MD3==^D3      ;/IMAGE/VARIABLE

        .MD4==^D4      ;/IMAGE/MACY

        .MD5==^D5      ;/MACY

        .MD6==^D6      ;/MACY/FIXED

        .MD7==^D7      ;/MACY/VARIABLE

        .MD8==^D8      ;/ASCII

        .MD9==^D9      ;/ASCII/FIXED

        .MD10==^D10    ;/ASCII/VARIABLE

        .MD11==^D11    ;Print file format

        .MD12==^D12    ;Fortran format

      

    

    
Tops-20 DAP has a lot of special cases to handle the PDP-10's
      variable byte sizes.  There is no more any special casing for VMS
      as far as I can tell.  The only other OS type specific special
      casing that I see is for RSTS/E, but I have not reviewed that in
      depth, yet.

    

    

      
I'm wondering whether I should double check the FILESYS byte.  Probably.

The decisions on how to handle all the many choices that DAP offers is from the capability flags -- 60 or so in the more recent protocol specs.  If one side needs to know whether the other side can do X, don't do "if it's RSTS it can't do X" but rather "does the flags field say the other side can do X?".  That way you won't make the mistake VMS did, breaking when another OS adds a new feature.

    

    
Yes, but I didn't mean base decisions on the FILESYS
      byte.  What I meant was, "I wonder where else Tops-20's DAP has
      different numbers than what is specified in DAP V5.6?  I ought to
      at least double-check whether the FILESYS
      byte definitions jive."  I have and they do.
    

    

      
It seems the best way to go is to simply mimic the RSX naming paradigm; that is, RSX OS$XXX would go to .OSXXX.


I'm not sure what "naming paradigm" means.  Is that about parsing name strings?  The way I remember it is that a single set of rules works for everything interesting.  Directories are in [ ] or < >; versions are delimited by dot or semicolon.  That excludes some oddball cases -- protection codes in <> for RSTS, directories in ( ) for RSTS (that was for IBM 2741 terminal support).  Those aren't all that important and have workarounds on those systems.  Unix doesn't fit at all; those names have to be handled by using quoted strings.  (Handling quoted names is important for that reason, and also to deal with anything else strange a user might want to hand you.)

    

    
That's an excellent point, and this is, in fact, done.  However,
      it is not what I meant.  I simply meant what sort of naming
      convention should I follow when coining new symbol names and that
      it seemed to me that it might be useful to either follow or at
      least mimic or 'rhyme' with what Johnny sent me for RSX.  In other
      words,

    

      

      

      

            
          

            RSX

              Symbol		
            RSX

              Value		
            RSX

              OS Type		
            Tops-20 DAP

              Symbol		
          

          

            OS$RT
            1
            RT-11
            .OSRT
          

          

            OS$RST
            2
            RSTS
            .OSRST
          

          

            OS$11S
            3
            RSX-11S
            .OSRXS
          

          

            OS$11M
            4
            RSX-11M
            .OSRXM
          

          

            OS$11D
            5
            RSX-11D
            .OSRXD
          

          

            OS$IAS
            6
            IAS
            .OSIAS
          

          

            OS$VMS
            7
            VAX/VMS
            .OSVAX
          

          

            OS$T20
            8
            TOPS-20
            .OSTP20
          

          

            OS$T10
            9
            TOPS-10
            .OSTP10
          

          

            OS$RTS
            10
            RTS-8
            .OSRTS
          

          

            OS$OS8
            11
            OS-8
            .OSOS8
          

          

            OS$MPL
            12
            RSX-11M+
            .OSRXP
          

          

            OS$COP
            13
            COPOS/11
            .OSCOP
          

          

            OS$POS
            14
            P/OS
            .OSPOS
          

          

            OS$ELN
            15
            ELAN
            .OSELN
          

          

            OS$CPM
            16
            CP/M
            .OSCPM
          

          

            OS$MSD
            17
            MS-DOS
            .OSMSD
          

          

            OS$U32
            18
            Ultrix-32
            .OSU32
          

          

            OS$U16
            19
            Ultrix-11
            .OSU16
          

        
      

      

        

    

    
Here, the red
      means the corrected Tops-20 DAP symbol definitions and the green are
      the new definitions.  You will note that the last three letters
      for these new symbols are the same as RSX and I thought there
      might be some value in that as a reminder when trouble-shooting.

    

    
Maybe naming convention is the better term than paradigm?