Oh.  Don't be surprised.

When I write protected what would be GLXLIB's high segment on Tops-20, the only way to do this is with .PSECT's, but GLXLIB makes a lot of assumptions about addresses.  On Tops-10, the GLXLIB high segment is write protected, and I think that is the right thing to do for all executable code.  I also moved GLXLIB as high as i could in the address space to allow GLXMEM on DAP's behalf to snarf really huge chunks of memory, which get filled up on large directory responses.  This is the default GLXLIB memory address space lay out:

  Section 0    R, W, E,  Private
0           TOMMYT:<SUBSYS>GLXLIB.EXE.5  1   R, CW, E
400-432     TOMMYT:<SUBSYS>GLXLIB.EXE.5  2-34   R, CW, E

Tops-10 fans will note that page 400 is the historic address of the high segment and this dates back to KA days.  I think that was just a convention and that it could be different, but I don't remember.  Bob?  This is the new layout:

  Section 0    R, W, E,  Private
0           STAR:<GALAXY-SOURCES.GLXLIB>GLXLIB.EXE.92  1   R, CW, E
637-673     STAR:<GALAXY-SOURCES.GLXLIB>GLXLIB.EXE.92  2-36   R, E

Note that GLXLIB is much higher--in fact, it is as high as it can go before bumping into DDT (if DDT is in the same section).  It is also write-protected.

Another reason I did this was to see what kind of bugs it would shake out and I've gotten a few, which is the reason for the two pages of added code (28 pages to 30, a big whopping 15K ...)  I also lifted some nifty stuff from Tops-10 GLXLIB; the sources diverged.

On 11/22/22 4:54 AM, Johnny Billquist wrote:
On 2022-11-22 06:18, Thomas DeBellis wrote:
------------------------------------------------------------------------
On 11/21/22 5:47 PM, John Forecast wrote:

I wanted to quickly find out how much, if  any, code was dependent on the OS type. One other area of incompatibility is that TOPS-10 and the Linux dndir require a DAP-level ACK after the attributes during directory listings.

Johnny and I did a lot of work and testing to get Tops-20 DAP/FAL to perform better.  Some were Tops-20, others not.  One Tops-20 bug was that an eight bit file would cause a directory listing to stop.  My favorite RSX issue was that it wants UPPERcase month names; I fixed that by UPPERcasing the result of ODTIM%. I can't remember what Johnny did (if anything).

I didn't do anything. And the uppercase month names are what the protocol specification states. RSX was just following the spec.

I don’t know. I think several people were talking about making a system available.

Well, when if one is ever available on HECnet, I'll be /delighted/ to test against it.

Meanwhile, now that I am finally able to assemble and LINK a working NFT and FAL and have fixed the incorrect OS type number issue, I bumped into another problem.  Naturally, it's doing directories.  When doing an ANONYMOUS directory of MIM:: (I.E., DIR MIM::*.*), I got:

    MIM::DU1:[DECNET]

    ....

    [Parsing Name message]
    [Parsing Attributes message]
    [Parsing Date/time Attributes message]
    [Parsing File Protection Attributes message]
    [Parsing Name message]
    DTRCOM.LST;115;P775656          10 18944(8)   24-Oct-2021 15:06:46
    [Parsing Name message]
    [Allocated Receive buffer (Words=225 Len=1056)]
    ?Logical link reception error - Record is longer than user requested
    Logical link abort reason(0) - No error

So it died on whatever the file is that follows MIM::DU1:[DECNET]DTRCOM.LST;115

Sigh...

The next file in the directory is DTRCOM.MAP, which is a file that is a bit more odd. But I'm surprised that TOPS-20 would barf on this.

.dsp [decnet]dtrcom.map

DU1:[DECNET]DTRCOM.MAP;84
                        Size:    47./47.         Created: 24-OCT-2021 15:06
                        Owner:   [007,014]       Revised: 24-OCT-2021 15:06
                        File ID: (17262,10,0)    Expires: <none_specified>
  File protection:      System:RWED, Owner:RWED, Group:R, World:R
  File organization:    Sequential
  File attributes:      Allocation=47, Extend=0
  Record format:        Variable length, no maximum defined
  Record attributes:    None

Compared to the .LST file:

.dsp [decnet]dtrcom.lst

DU1:[DECNET]DTRCOM.LST;115
                        Size:    37./37.         Created: 24-OCT-2021 15:06
                        Owner:   [007,014]       Revised: 24-OCT-2021 15:06
                        File ID: (17260,106,0)   Expires: <none_specified>
  File protection:      System:RWED, Owner:RWED, Group:R, World:R
  File organization:    Sequential
  File attributes:      Allocation=37, Extend=0
  Record format:        Variable length, no maximum defined
  Record attributes:    Carriage return

  Johnny