TOPS-10 BUGHLT COM911

[Lars Brinkhoff]

Is there a patch for making TOPS-10 run beoynd year 2021?

BUG.(HLT,COM911,D36COM,SOFT,<The date is past 9 November 2021>,,<

Cause: The 2 byte julian half-day field in an event message is limited
to 9 november 2021. The routine above has calculated the julian
half-day, and has found that it overflowed.

I doubt very much that the date itself has really gone past 2021.
Probably someone smashed an AC or the routine to get the time
from the monitor is returning junk.
>)

[Rich Alderson]

Lars Brinkhoff <lars...@nocrew.org> writes:

! Is there a patch for making TOPS-10 run beoynd year 2021?
!
! BUG.(HLT,COM911,D36COM,SOFT,<The date is past 9 November 2021>,,<
!
! Cause: The 2 byte julian half-day field in an event message is limited
! to 9 november 2021. The routine above has calculated the julian
! half-day, and has found that it overflowed.
!
! I doubt very much that the date itself has really gone past 2021.
! Probably someone smashed an AC or the routine to get the time
! from the monitor is returning junk.
! >)

This is a DECNET-specific issue.

1. Don't use DECNET and it won't matter. If you need networking, move to
TOPS-20 and use TCP/IP.

2. Set your system clock to something before 31-DEC-99 and it won't matter.
Best choice of date is 28 years before the current year, so that the
calendars match exactly. On 1-JAN-2028, make that 56 years before the
current year. Let the kids in 2083 worry about it.

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Jordi Guillaumes Pons]

On Sunday, December 27, 2020 at 1:47:53 AM UTC+1, Rich Alderson wrote:

> This is a DECNET-specific issue.
>
> 1. Don't use DECNET and it won't matter. If you need networking, move to
> TOPS-20 and use TCP/IP.
>
> 2. Set your system clock to something before 31-DEC-99 and it won't matter.
> Best choice of date is 28 years before the current year, so that the
> calendars match exactly. On 1-JAN-2028, make that 56 years before the
> current year. Let the kids in 2083 worry about it.

I'm in no way a PDP10 hacker, but I'll try two obvious, easy an probably wrong "fixes":

- Just commenting out that line, or maybe make it a non-halt BUGHK.
- Hardcoding a fixed value (November 8 2021?) when the field overflows...

Fortunately, the worst thing that can happen is a broken simulator. Working with virtual hardware has the avantage it won't explode nor burn out :)

(I don't know when I will try it... I'll keep this group posted).

J.

[fishtoprecords]

On Sunday, December 27, 2020 at 4:39:09 AM UTC-5, jguil...@gmail.com wrote:
> I'm in no way a PDP10 hacker, but I'll try two obvious, easy an probably wrong "fixes":
>
> - Just commenting out that line, or maybe make it a non-halt BUGHK.
> - Hardcoding a fixed value (November 8 2021?) when the field overflows...
>
> Fortunately, the worst thing that can happen is a broken simulator. Working with virtual hardware has the avantage it won't explode nor burn out :)

Dates have lots of side effects.
Done badly, things like compil won't work properly in deciding what files to recompile

[Rich Alderson]

Of course, that's an issue for file system dates, not for program-internal dates.

[lars...@nocrew.org]

> BUG.(HLT,COM911,D36COM,SOFT,<The date is past 9 November 2021>

I got this fix from Thomas DeBellis:


The DECnet-10 COM911 drop dead date of November 9th is now about three weeks
away (23 days). This will crash Tops-10 if it is up and force you to enter
a bogus date on boot up and hope it's not pulling the right date from
anything. That can happen on a KL, but I don't know about a KS.

I posted a patch to work around the issue to HECnet and make Tops-10 act
like OpenVMS in this regard on December 28th of last year.

In D36COM.MAC at NMXTIM+9, change the following two lines (which skip or
fall into the COM911 BUGHLT),

SKIPL T2 ;MAKE SURE WE HAVE A POSITIVE NUMBER OF SECONDS
TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW

to

SKIPGE T2 ;Do WE HAVE A POSITIVE NUMBER OF SECONDS?
MOVMS T2 ; No. Fine, now we're plenty positive
TDZA T1,[XWD -1,600000] ;MAKE SURE never any DATE OVERFLOW ever

[Lars Brinkhoff]

>> BUG.(HLT,COM911,D36COM,SOFT,<The date is past 9 November 2021>
> I got this fix from Thomas DeBellis

He adds:

It turns out that you can change the fix slightly to be able to patch
the monitor directly with FILDDT. You want to change two instructions
at NMXTIM+13 from:

NMXTIM+12/ IDIV T3,TICSEC
NMXTIM+13/ SKIPL T2
NMXTIM+14/ TDNA T1,COMCAW+10
NMXTIM+15/ XCT COM911

To:

NMXTIM+12/ IDIV T3,TICSEC
NMXTIM+13/ MOVMS T2
NMXTIM+14/ TDZA T1,COMCAW+10
NMXTIM+15/ XCT COM911

So doing that will keep you from crashing. You can even deposit it
right into the running monitor (one hesitates to say, 'toggle'...)

[lordha...@gmail.com]

Hey folks, how might an amateur TOPS-10 operator do this fix? I run FILDDT and then enter the NMXTIM commands?

Thanks for any simple steps!

Andy

[Robert Armstrong]

> Hey folks, how might an amateur TOPS-10 operator do this fix?
>I run FILDDT and then enter the NMXTIM commands?

I may have forgotten a step or two, but ...

Log is as [1,2]
COPY [1,5]=SYSTEM.EXE[1,4]
R FILDDT
File: SYSTEM[1,5]
NXMTIM+13/ (you should see DDT type the "SKIPL T2...") MOVMS T2 <CTRL-J>
(DDT should type NXMTIM+14 and the TDNA... You enter the TDZA ... et al and CTRL-J)
CTRL-Z
Shutdown and reboot
At the BOOT> prompt, enter "[1,5]"
You should now be running the patched monitor.
If all is well, you can rename SYSTEM.EXE[1,4] to [1,3], and then rename SYSTEM.EXE[1,5] to [1,4].

BTW, on TOPS-10 [1,5] is NEW:, [1,4] is SYS: and [1,3] is OLD:.

Bob

[lordha...@gmail.com]

Thanks Bob I will give that a whirl and report back!

Andy