[HECnet] Another TOPS-10 DECnet problem

[Thomas DeBellis]

It is certainly true that NML might be choking on legitimately bogus 
monitor data.    However, one hesitates to observe that signaling 
incorrect input by crashing is a misfeature...

The monitor call would be nice to know.  You can trap both UUO's and 
JSYi on Tops-20 in a number of ways to see what is actually happening, 
whether or not you have the source.  I can't remember whether Tops-10 
has a similar feature.  I thought not, although I'm fairly certain it 
does have address break.

If the crash dump is Galaxy based, then it will have the AC's preserved 
in a block in the crash dump.
------------------------------------------------------------------------
On 11/10/21 1:11 PM, Robert Armstrong wrote:
>
> >I don't suppose DEC supplied source for NML?
>
>   Doesn’t look like it – there’s nothing in [10,7,NML] except for the 
> NML.EXE.  Oddly there are sources for FAL, NFT and even NCP but not 
> NML.  I wonder if there’s some “trick” for building NML.EXE from some 
> other source?
>
>   In any case, following the rule of “no matter what bad data you give 
> in the monitor call, it shouldn’t crash the system” I don’t think NML 
> is the problem.  It might be interesting to figure out exactly what 
> call NML is trying to execute, but the bug is in the monitor.
>
> Bob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211110/fa92371e/attachment.htm>