21 Nov
2022
21 Nov
'22
6:02 p.m.
On Nov 21, 2022, at 9:25 AM, Paul Koning
<paulkoning(a)comcast.net> wrote:
Agreed. The original FAL on DECnet for Linux claims to be VMS. I wrote an alternative FAL
(FAL2) to provide simple sequential file access which claims to be LINUX by using one of
the reserved for user-specified operating systems values (192), mostly just to see if it
caused any problems. So far, only TOPS-10 had issues - it will fail to connect if it does
not recognize the operating system type. I don’t think I had a TOPS-20 system at time to
test with.
John.
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.
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.)
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se