[HECnet] Re: Tops-20 NFT limited parse types for RSX systems?

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: 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. 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. 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?