<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I had a look at this a few years ago; here is what I remember:<br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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).</p>
<p>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.</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:B916CFAD-D450-4ECF-896D-BB1DD929366B@comcast.net">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On 12/27/20 2:56 PM, Paul Koning wrote:
</pre>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<blockquote type="cite">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On Dec 27, 2020, at 12:30 PM, John Forecast <a class="moz-txt-link-rfc2396E" href="mailto:john@forecast.name"><john@forecast.name></a> wrote:
</pre>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On Dec 27, 2020, at 11:46 AM, Robert Armstrong <a class="moz-txt-link-rfc2396E" href="mailto:bob@jfcl.com"><bob@jfcl.com></a> wrote:
This topic came up on the alt.sys.pdp10 list
<a class="moz-txt-link-freetext" href="https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ">https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ</a>
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
</pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>