21 Nov
2022
21 Nov
'22
3:43 p.m.
On 2022-11-21 15:25, Paul Koning wrote:
Totally agree. And I think/hope RSX does this. But if anyone spots RSX
acting strange, let me know.
On Nov 20, 2022, at 11:09 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
It's taken me over a month to put some data together, both tabulating from various
sources and observing what is actually going over the wire.
The basic problem was that some changes that I had previously made to DAP, NFT, FAL and
friends to write protect the code space silently left things in such a fragile state that
trying to link the relocatable binaries (I.E., .REL files) into an NFT execute either
outright blew LINK up or hung it in an endless loop. That's right: Boom... I
don't think I've ever seen that.
Fixing LINK didn't seem to be obvious and I didn't want to get into pile of code
as I judged this to be a one to two year rabbit hole because it would turn into a rewrite
to use extended mode and support long symbols.
Briefly, the problem turned out to be that if you are using Read-Only .PSECT's (a
relatively late MACRO feature) in a GLXLIB program, you must name your code segment .HIGH.
and your data area DATA. I got the data part correct, but committed the unforgivable sin
of naming the code segment "CODE"... Go figure.
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. 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 wondering whether I should double check the FILESYS byte. Probably.
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. 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.
VMS, unfortunately, broke things in many ways as they more and more
assumed that there was just VMS anywhere anyway. The MAIL11 server
certainly have some very broken bits as well, that I noticed. And CTERM
usually is a bit odd with anything non-VMS. :-)
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.)
As far as I understood, Thomas was thinking of/referring to the naming
of symbols in the source code. In RSX you have OS$xxx, and Thomas was
thinking of just taking the TOPS-20 format, which is .OSxxx and just
copy the xxx part from the RSX symbols over to the TOPS-20 symbols.
But things you say about filename string parsing is certainly true as well.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol