22 Nov
2022
22 Nov
'22
6:40 p.m.
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:
I didn't do anything. And the uppercase month names are what the
protocol specification states. RSX was just following the spec.
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
------------------------------------------------------------------------
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 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...