27 Dec
2020
27 Dec
'20
10:26 p.m.
I had a look at this a few years ago; here is what I remember:
Tops-10 and Tops-20 clearly share a certain amount of common code.? In
the monitor, a number of comments show that the DECnet-36 transport was
developed in user mode under Tops-10 and, once stable, ported to monitor
mode and thence to Tops-20.? From there, you have a certain amount of
divergence in the form of conditional assembly.
The BUGHLT in question (COM911) still appears under a Tops-10
conditional.? The routine, NXM, is used to compute a time stamp for an
event block.? Internally, Tops-20 has a maximum possible date of
September 27th, 2217; it looks like Tops-10 may have the same limit.
The routine takes this internal date and converts it into the number
Julian half days, the number of seconds into the current half day and
the number of milliseconds into the current second. Tops-10 will not
allow the overflow.? The Tops-20 conditional uses internal monitor
routines (which are '2217 clean') to do the calculation and will not crash.
The error logging in Tops-20 uses the internal format and, as far as I
am aware, couldn't care less about any of the above.? I would assume
that the stamping is used to package an error for consumption by other
non-Tops-20 components, but I haven't chased any further on that.
Additional work was done on the timestamp code in the PANDA monitor,
apparently by Ralph Gorin.? It handles the time of day as a proper fixed
point binary fraction and appears correct.? I don't know how many times
I have seen this done wrong (QSRADM comes to mind).
In other areas, Tops-10 and Tops-20 share no common code for DECnet.?
The DAP library is completely Tops-20 specific.? This had a date problem
that I fixed with some help from Johnny.? It still has a bug that will
cause it to crash when handling certain files from Tops-10 (of all
places).? FAL is also completely different; far more integrated into
Galaxy.? After I put the ANONYMOUS transfer support into FAL, I put all
of it aside to turn to something else.? I'll look at it again when I get
back to it.
I think Paul has made a reasonable observation that timestamps being
wrong shouldn't make DECnet gronk.?? Yet this is precisely what Tops-10
is going to do with itself.? The code appears to date from 1983, so
maybe that was a reasonable assumption.? Many utilities from Tops-10
aren't even Y2K compliant, including login.
------------------------------------------------------------------------
On 12/27/20 2:56 PM, Paul Koning wrote:
Ignoring the spec and treating that field as unsigned is certainly a reasonable thing to
do.
That said, I don't see any reason why "timestamps will be wrong" translates
to "DECnet won't work".
paul
> ------------------------------------------------------------------------
> On Dec 27, 2020, at 12:30 PM, John Forecast <john at forecast.name> wrote:
> It?s not just a DECnet-10/20 problem. DECnet event logging for any system may fail
after Nov 9th 2021. Events are time-stamped when they are generated with a 2-byte field
holding the number of half julian days since Jan-1 1977. The spec (Network Management
4.0.0, page 170/171) implies that these 2 bytes should be treated as a signed value (0 -
32767) which will overflow on Nov 9th 2021. If the code treats it as unsigned, then we?re
good for another 44 years. I wrote most of the RSX and Ultrix event logging code but I
don?t remember if that field was treated as signed or unsigned. Phase V fixed the problem
allowing the time stamp to go well past the year 9999.
>
> John.
>> ------------------------------------------------------------------------
>> On Dec 27, 2020, at 11:46 AM, Robert Armstrong <bob at jfcl.com> wrote:
>>
>> This topic came up on the alt.sys.pdp10 list
>>
>> https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ
>>
>> Apparently DECnet-10 won?t work past November 9th 2021, which isn?t that far
away. Personally I?d never heard this before and had no idea, and since I know there are
a few 36 bit emulations on HECnet that are obviously using DECnet I thought I?d pass it
along.
>>
>> TOPS20 isn?t explicitly mentioned, but I?m guessing that it has the exact same
issue. That?d mean no DECnet on 36 bit systems after next year! Unless, of course, you
want to start playing games with the date (which I hate doing)?
>>
>> Bob