[HECnet] TOPS-10 D-Day, DECnet failure on November 9th is less than six days away

[G.]

> I have seen part of this before; it's modifying the Tops-10 idle loop to
> notify the KLH10 micro-engine that there are no jobs that want to run.  The
> modification is roughly equivalent to what was done to Tops-20.  However, it
> should not be assumed that this is The Thing To Do on simh or other PDP-10's.

Indeed, I agree on everything. Mine were instructions for some specific
purpose that I pasted here just to give an outline of the several required
steps to rebuild the monitor, but people must tailor them to their needs. :)

> I don't see why device address 700 would be any more or less risky than 740.
> As long is nothing else is sitting on the address, you're fine from what I can
> remember.

 From what I can read after some quick search in alt.sys.pdp10, in 2004 (!)
someone had issues with UNJ stopcodes ("This stopcode occurs when the null job
executes a monitor call other than the doorbell call") and found that the
processor reference manual says that "Unless User In-out is set, do not give
any IO instruction with device code less than 740" (on page 2-136) hence I
guess that 740 instead of 700 must have been a safer choice.

Moreover, in some other post MRC refers to devices whose address is above 700
(or 740?) as "unrestricted" devices. I'm not expert enough to understand any
of it but I followed what seemed some sensible advice. :)

HTH,
G.


P.S. Just in case, I have a couple of procedures (.CTL) to rebuild both the
TOPS-20 monitor and EXEC from sources...