Great!!? I'll try out my latest Tops-20 DECnet NRT enabled Kermit (K20MIT) with it.? Once I get a few less sparks flying out of it, I'll see what's what with yours. ------------------------------------------------------------------------ On 11/9/21 9:03 PM, Robert Armstrong wrote:

Is that KDP link something that is on the 2020, then?? We only had KL's, so anything like that would have gone through a DN20. I am not wholly surprised that VENTI:: needed a reboot; recall that we are clamping the value in T1 to 65,535 Julian half-days, so anything that is playing with that or otherwise paying attention is going to see a monotonically increasing value that got pretty large wrap around to something close to the smallest possible value (maybe even zero). For the seconds remainder in T2, if this goes negative, then the same thing will happen (a clamp to 1 second), but since that is only monotonic by day, this shouldn't matter. However, the code ignores T3 (the number of milliseconds), but if T2 goes negative, then so will T3. This suggests that T3 needs to be clamped, as well.? The following code is a potential fix: At label NMXTIM + 9 lines, (Decimal) change ??????? IDIVI T3,JIFSEC???????? ;CONVERT TO NUMBER OF MILLISECONDS. ??????? SKIPL T2??????????????? ;MAKE SURE WE HAVE A POSITIVE NUMBER OF SECONDS ??????? TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW ?To: ??????? IDIVI T3,JIFSEC???????? ;CONVERT TO NUMBER OF MILLISECONDS. ??????? MOVMS T3??????????????? ;Ensure milliseconds are always positive ??????? MOVMS T2??????????????? ;Ensure seconds are always positive ??????? TDZA T1,[XWD -1,600000] ;Ensure no Julian half day overflow The assumption here is still that the result in T1, T2 and T3 is only being used for logging which may not be correct.