<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I finished the modifications to <font size="+1"><tt>SCLINK</tt></font>
to properly return error values which are negative and <font
size="+1"><tt>JNTMAN</tt></font> to return the error value in
AC3 if <font size="+1"><tt>.NDINT</tt></font> doesn't succeed
inserting all the nodes. Then I modified <font size="+1"><tt>SETNOD</tt></font>
to get this extended error information and print it. I put the
new monitor and <font size="+1"><tt>SETNOD</tt></font> up,
rebooted <b>…AND</b>…<br>
</p>
<blockquote>
<pre><font size="+1">SETNOD>set nod 2.298 name REACH
SETNOD>ins
SETNOD></font>
</pre>
</blockquote>
<div class="moz-cite-prefix">
<p>It works perfectly because, of course it does…</p>
</div>
<div class="moz-cite-prefix">
<p>So, as usual, Johnny's guess is pretty close to the mark, even
if he isn't a 36 bit'er. "Slightly broken"? Yeah, 'slightly'
enough so that it can't be easily reproduced…</p>
<p>The only thing I can think of is that the system had been up
over 15 weeks when I saw this. I had looked at the storage
space utilization with <font size="+1"><tt>SYSDPY</tt></font>
and didn't notice anything maxing out. I restarted the <font
size="+1"><tt>GETNOD</tt></font> batch job on <font size="+1"><tt>VENTI2::</tt></font>.
Maybe in another 15 weeks, it will break again.</p>
<p><i>Annoyed</i>…</p>
</div>
<blockquote type="cite"
cite="mid:5b27d7d8-8de7-53ce-2487-f4c3b48ca213@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<hr width="100%" size="2">On 5/4/21 10:31 PM, Thomas DeBellis
wrote:<br>
<p>Personally, I don't see how it could <i>possibly</i> be
anything to do with the <font size="+1"><tt>REACH::</tt></font>
node definition, but I have been known to occasionally overlook
the utterly obvious, particularly when it's near night-night.
Maybe not this time.<br>
</p>
<p>Right now, the way to figure it out is to get the minor error
data and see where that takes things. So I'm making a change to
<tt><font size="+1">JNTMAN to have </font></tt><font size="+1"><tt>.NDINT</tt></font>
to return the lower level code on an incomplete insert. <font
size="+1"><tt>SCLINK</tt></font> appears to have a problem
that it is mangling return values, which I'm currently
investigating.</p>
<p>You can't just blithely assuming somebody got it wrong and
'fix' things; sometimes it's a certain way for a reason.<br>
</p>
<div class="moz-cite-prefix">On 5/4/21 8:46 PM, Johnny Billquist
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:87a03c9f-7879-0b77-a5dd-4b7897f80ba2@softjar.se">On
2021-05-05 00:54, Mike Kostersitz wrote: <br>
<blockquote type="cite">Ouch that is one of my nodes 😊 @Johnny
Billquist <a class="moz-txt-link-rfc2396E"
href="mailto:bqt@softjar.se" moz-do-not-send="true"><mailto:bqt@softjar.se></a>
anything you could think of since we just renamed my old
RSX11M node to REACH. <br>
</blockquote>
<br>
Well. It is something slightly broken in Tops-20, so there isn't
really anything we can do about it. <br>
<br>
Except hope that Thomas can figure it out and fix it. <br>
<br>
Johnny <br>
<br>
<blockquote type="cite"> <br>
Mike <br>
<br>
Sent from Mail <a class="moz-txt-link-rfc2396E"
href="https://go.microsoft.com/fwlink/?LinkId=550986"
moz-do-not-send="true"><https://go.microsoft.com/fwlink/?LinkId=550986></a>
for Windows 10 <br>
<br>
*From: *Thomas DeBellis <a class="moz-txt-link-rfc2396E"
href="mailto:tommytimesharing@gmail.com"
moz-do-not-send="true"><mailto:tommytimesharing@gmail.com></a>
<br>
*Sent: *Tuesday, May 4, 2021 15:16 <br>
*To: *HECnet <a class="moz-txt-link-rfc2396E"
href="mailto:hecnet@update.uu.se" moz-do-not-send="true"><mailto:hecnet@update.uu.se></a>
<br>
*Subject: *[HECnet] Re: Tops-20 SETNOD Failure <br>
<br>
I fixed a few things in SETNOD to get some more information
about the error. In particular, <br>
<br>
* Allow listing of AREA 1 (this was specifically disallowed,
I don't <br>
know why) <br>
* More consistent error reporting (via ESOUT%) <br>
* List more than one node when doing an area list (it would
only list <br>
a single node) <br>
* List nodes with more than three digits in the node number
when doing <br>
columnar output <br>
<br>
So now you get the expected results: <br>
<br>
SETNOD>lis a 1 <br>
[Area 1] <br>
A1RTR 1023 ATHENA 620 ATLE 605 AURORA
606 BANAI 770 <br>
BANX25 771 BEA 19 BIZET 800 BJARNE
7 BLINKY 266 <br>
CATWZL 302 CLYDE 269 COOPER 263 CRISPS
201 CYGNUS 259 <br>
DAVROS 254 DBIT 351 DE1RSX 450 DE1RSY
452 DOCTOR 252 <br>
ELIN 616 ELMER 617 ERNIE 2 ERSATZ
350 FLETCH 100 <br>
FNATTE 3 FREJ 608 GAXP 730 GNAT
16 GNOME 6 <br>
GOBLIN 4 GVAX 731 HAGMAN 262 HARPER
261 HORSE 150 <br>
HUGIN 602 HYUNA 500 INKY 268 JIMIN
501 JOCKE 21 <br>
JOSSE 17 KLIO 451 KRILLE 8 LOKE
607 MACARO 303 <br>
MACRA 258 MAGICA 1 MASTER 251 MIM
13 MUNIN 603 <br>
NIPPER 202 NOMAD 610 NOXBIT 720 ORACLE
301 PACMAN 265 <br>
PAI 541 PALLAS 621 PAMINA 18 PIDP11
560 PINKY 267 <br>
PISTON 520 PLINTH 200 PMAVS2 510 PONDUS
15 PONY 12 <br>
PUFF 22 QEMUNT 151 REI 540 ROCKY
11 ROJIN 542 <br>
RSX124 306 RSX145 304 RSX170 305 RSX184
307 RUTAN 255 <br>
SHARPE 260 SIDRAT 253 SIGGE 10 SPEEDY
24 TARDIS 250 <br>
TEMPO 9 THOROS 257 TINA 14 TIPSY
604 TONGUE 264 <br>
TOPSY 601 VALAR 400 VAROS 256 WXP
20 WXP2 23 <br>
YMER 609 ZEKE 5 <br>
Total nodes in area 1: 92 <br>
SETNOD>exit <br>
<br>
Regarding the error, I have reproduced it with a single entry,
viz: <br>
<br>
!setnod <br>
SETNOD>_set nod 2.298 name REACH_ <br>
SETNOD>_insert_ <br>
?SETNOD: Failed at node REACH (2.298), Item 0 of 1 <br>
SETNOD> <br>
<br>
The high level code to do the entry is in JNTMAN. It loops
through the table passed to it via .NDINT, calling a lower
level routine called SCTAND in SCLINK. An error here is
passed up to JNTMAN, but it is not passed back to the user.
There are some other problems in SCLINK pertaining to negative
return values, so some minor work is necessary there, also. <br>
<br>
I'll make some changes to these two modules, generate a new
monitor for VENTI2 and see what happens in a few days. <br>
<br>
Right now, if any Tops-20 using is using SETNOD to update
DECnet tables, this appears to fail. If anybody else is
seeing it or can reproduce it, I'd like to hear about it. <br>
<br>
On 5/4/21 11:15 AM, Thomas DeBellis wrote: <br>
<br>
Has anybody ever seen SETNOD fail to insert the entire
node list? I <br>
just did. <br>
<br>
Shortly after I put my 20's up on HECnet, I wrote a
reoccurring <br>
batch job that fires once a week on Sundays to pull the
latest node <br>
list (T20.FIX) from MIM::. I use the highly venerable
FILCOM <br>
program to do a difference of it with the previous week's
list. I <br>
don't do anything in particular with the output except
save it in <br>
case I feel like looking at it for some reason. <br>
<br>
The batch job always inserts the entire list, rewriting
whatever <br>
might be in the monitor's data base. I have always been
unsatisfied <br>
with doing things that way because it seemed to me to be
inefficient <br>
as the node list grew. The HECnet node list count was
716 on <br>
9-Jun-19 and it's now up to 884 as of the latest version
that I've <br>
pulled, 30-Apr-21. The other problem is the microscopic
possibility <br>
that a node is in Tops-20's monitor database (a hash
table) that <br>
isn't in the HECnet node list. <br>
<br>
Nodes can get removed, although I think that infrequent.
Nodes <br>
could get inserted outside of the batch job, but I think
that most <br>
unlikely in my situation. Nodes can get renamed, as
evidenced by <br>
2.299 below, which went from THEPIT to THEARK. None of
this should <br>
or has broken anything. <br>
<br>
However, it's been in the back of my mind to do two
enhancements, <br>
one to Tops-20 and one to SETNOD. The NODE% JSYS should
have an <br>
additional feature to return the current monitor data
base. The <br>
SETNOD program should be enhanced to take that to compute
the set <br>
difference with the new list. This would show additions,
renames <br>
and deletions. That would bring the update operation down
from some <br>
hundred items to less than ten, on average. This would
obviously <br>
make more of a difference on huge DECnet's in the tens of
thousands <br>
of nodes. Another NODE% feature should probably be to
whack the <br>
entire monitor database except for the local node, which
would be <br>
useful for trouble shooting. <br>
<br>
Last Sunday, the batch job failed with the following
error: <br>
<br>
18:33:40 USER SETNOD>*TAKE SYSTEM:NODE-DATA.TXT.0 <br>
18:33:40 USER <br>
18:33:40 USER [Fork SETNOD opening
<SYSTEM>NODE-DATA.TXT.1 for <br>
reading] <br>
18:33:41 USER SETNOD>*SAVE <br>
18:33:41 USER <br>
18:33:41 USER [Fork SETNOD opening
<SYSTEM>NODE-DATA.BIN.74 for <br>
reading, writing] <br>
18:33:41 USER SETNOD>*INSERT <br>
18:33:41 USER <br>
18:33:41 USER *?SETNOD: Failed at node REACH* <br>
18:33:41 USER SETNOD> <br>
<br>
I had a look at the SETNOD source and the HECnet node list
and have <br>
discovered and concluded a few things. First, there
doesn't seem to <br>
be anything syntactically wrong with REACH::'s definition:
"set nod <br>
2.298 name REACH". Second, there don't appear to be any
semantic <br>
issues. 2.298 wasn't in use and it shouldn't matter if it
was. <br>
<br>
In the case of INSERT, there are two kinds of errors from
NODE%, a <br>
general failure of the JSYS and an incomplete insertion.
The error <br>
is from the second case. Unfortunately, SETNOD isn't
reporting <br>
enough information about the error, so I have to make some
changes <br>
there. It's also possible that SETNOD is building an
inconsistent <br>
database for the monitor to swallow; at least the LIST
command is <br>
giving me some odd results, viz: <br>
<br>
SETNOD>list arEA 2 <br>
<br>
[AREA 2] <br>
A2RTR <br>
<br>
TOTAL NODES FOUND: 1 <br>
<br>
SETNOD> <br>
<br>
That's clearly wrong, viz: <br>
<br>
!i dec <br>
Local DECNET node: VENTI2. Nodes reachable: 7. <br>
Accessible DECNET nodes are: A2RTR BOINGO
LEGATO TOMMYT VENTI2 VENTI ZITI <br>
<br>
The Exec output should probably be changed to say, "Nodes
reachable <br>
in local area" and "Online nodes in area are:" <br>
<br>
Anybody have any ideas? Hunches? Clues? <br>
<br>
File 1) OLDF:[4,120] created: 1241 15-Apr-21 <br>
File 2) NEWF:[1,1] created: 0102 30-Apr-21 <br>
<br>
1)1 set nod 44.9 name OSMIUM <br>
**** <br>
2)1 set nod 2.292 name OSIRIS <br>
2) set nod 44.9 name OSMIUM <br>
************** <br>
1)1 set nod 13.3 name RED <br>
**** <br>
2)1 *set nod 2.298 name REACH * <br>
2) set nod 13.3 name RED <br>
************** <br>
1)1 set nod 2.298 name RSX11M <br>
1) set nod 1.306 name RSX124 <br>
**** <br>
2)1 set nod 1.306 name RSX124 <br>
************** <br>
1)1 set nod 42.5 name SPARKY <br>
**** <br>
2)1 set nod 2.291 name SPARK <br>
2) set nod 42.5 name SPARKY <br>
************** <br>
1)1 set nod 2.299 name THEPIT <br>
1) set nod 35.70 name THOMAS <br>
**** <br>
2)1 set nod 2.299 name THEARK <br>
2) set nod 35.70 name THOMAS <br>
************** <br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
</body>
</html>