Problem getting SENDS in DDT

[larsbrinkhoff]

There seems to be a problem getting SENDS in DDT using the ^A command. For example:

↑A
(Getting SENDS for LARS@ )
 : .TEMP.; LARS SENDS - NO SUCH DEVICE

[larsbrinkhoff]

@eswenson, I see ES has the same issue so I'm guessing it's something that affects the PI distribution as well.

EDIT: Strike that, maybe ES just has the GitHub version.

[larsbrinkhoff]

If I type LARS^A I get "No Sends" or the contents of .TEMP.;LARS SENDS if there is such a file.

[larsbrinkhoff]

It seems the code implements an undocumented feature: you can supply an ITS name (as per .GETSYS' ITSNMS) to ^A, and then DDT will check for sends on that machine (using the MLDEV device).

But somehow this feature trips up things when there's no argument to ^A. The missing argument is treated as a empty device name.

This change happened in 1978, between DDT 1000 and 1072.

[larsbrinkhoff]

Another interesting finding is that sends are preferentially stored on the .TEMP. directory, but DDT will fall back to COMMON if .TEMP. is missing. There is also code to have MAIL files on COMMON, but that has been disabled in favor of
HSNAME directory. So apparently both sends and mail was in COMMON back in the day, but no longer.

Old versions of DDT use the COM: device for sends.

[larsbrinkhoff]

The problem is in MCHOKP which checks whether A is a valid ITS name. It goes through all names in MCHTAB. The bug is that it compares A against a table entry before checking if the entry is 0. So if A is 0 it will (probably) hit an empty entry and think it's a valid name, rather than finding the end of the table and exiting the loop.

If we pass in a user name there's no problem, because it will not match a 0 in MCHTAB.

[larsbrinkhoff]

MCHOKP does another strange thing. It checks whether B is DSK, and if so returns the local machine ITS name. Not all callers will have something sensible in B, however. This change was also made in 1978, between DDT 1263 and 1316.

[eswenson1]

@eswenson, I see ES has the same issue so I'm guessing it's something that affects the PI distribution as well.

EDIT: Strike that, maybe ES just has the GitHub version.

Indeed, I updated SENDS from GitHub. I generally do this all the time. ES should be running the latest GitHub code. But if something existed in PI that hasn’t been included in GitHub, I leave it be.

[bictorv]

(One idea would be to check for corresponding code in other programs that got updated to use the ITSNMS-generated list of ITSes. I don't have time right now.)

[eswenson1]

@larsbrinkhoff I've been using :QSEND to send messages to other machines. DDT's SNDFLG allows the use of :SEND to invoke an external program of the same name, and our build causes SYS; TS SEND to be linked with SYSBIN;SENDER BIN. However, when I try :send ejs@ex ^C from ES, I get "Can't", and the ">>" prompt. When I try :send ejs@es ^C on EX, it sends perfectly find and I receive the message. On both systems, SYS;TS SEND is a link to SYSBIN;SENDER BIN, and BINPRT says that both were assembled from SYSEN1;SENDER 398.

Because :SEND ejs@ex ^C on ES always says "Can't", I figured that it didn't support the chaos SEND protocol. However, as seen by the success of the same thing from EX, that was a bad assumption. I've always used :QSEND rather than :SEND when sending messages to other machines (I used to do that back in my MIT-MC days as well).

Can you think of any reason why this works from one machine (EX/DB) and not from ES? QSEND, of course, works perfectly fine on both machines for sending to the other (and other chaosnet hosts).

[eswenson1]

For whatever reason, on ES attempting to use :SEND to send to EX, SENDER attempts to use the CLI device, rather than CHAOS. This fails (and :send prints "Can't"). However, if after the failure, I use the "K" command to switch from CLI to Chaos, it works fine. On EX, on the other hand, it doesn't attempt to use the CLI device, but chooses CHAOS, which works.

I don't understand why on ES, SEND tries to use the %CLI device, but not on EX. Any ideas?

[larsbrinkhoff]

My first idea is that you have forgotten to set SNDFLG to -1 on ES.

You should be able to make CLI work by having all your "local" machines in ITSNMS and setting up MLDEV between them.

[eswenson1]

I have SNDFLG set to 1 (not -1) on both machines. DDTORD says 0 or non-zero, so 1 should be fine.

I’m pretty sure that ITSNMS has EX and ES on both systems. And MLDEV is set up on both systems.

[larsbrinkhoff]

In that case I think it's TS SEND (SENDER) printing "Can't" (and maybe something more?) I'm guessing it can't open EX:.TEMP.;uname SENDS for some reason.

[eswenson1]

Well, it's not that. I can, from ES, write to EX:.temp.;ejs sends (using the :copy command). And I can do the same from EX (writing to ES:.temp.ejs sends). MLDEV is working perfectly fine from either machine to the other.

I put a breakpoint at BEGAN in SEND on ES and stepped until the .getsys call. I see EX in the ITS machine table.

mchtab/   456300000000   '◊1'ES◊
MCHTAB+1/   457000000000   '◊1'EX◊
MCHTAB+2/   457041000000   '◊1'EXA◊
MCHTAB+3/   457054000000   '◊1'EXL◊
MCHTAB+4/   457063000000   '◊1'EXS◊
mchtab+5/   656000000000   '◊1'UP◊
MCHTAB+6/   646400000000   '◊1'TT◊
MCHTAB+7/   565700000000   '◊1'NO◊
MCHTAB+10/   635200000000   '◊1'SJ◊
MCHTAB+11/   0   '◊1' ◊

And I stepped through the code that decides whether the recipient host is "an ITS" and that does determine it EX is an ITS host. Since the $Force flag is not on, we first attempt the CLI route. ANITS returns with TT set to EXCLI.

What would prevent an OPEN and subsequent write to EXCLI on ES (but the corresponding open of ESCLI on EX to work)?

Is there anything that needs to be set up in DEVICE for EXCLI to be considered a usable device?

Here is the failure point:

MAKE6N+2>>.CALL 12627 (OPEN)   :calprt
Control Bits: A   0,,1
Arg #1: F   0,,6
Arg #2: CLI/   ORCAB A,545100(C)   457043,,545100   ◊1'EXCLI◊
Arg #3: H6NAME/   ORCAI E,@(C)   455263,,0   ◊1'EJS◊
Arg #4: 12626/   HRL C,646256(C)   504143,,646256   ◊1'HACTRN◊
↑N
MAKE6N+3>>RETURN   PDLIST+2/   310000,,DOIT+1

We attempt an open to EXCLI and this doesn't skip-return, hence an error. However, why does it want to go to EJS HACTRN on EXCLI? This seems wrong.

Weird thing is that on EX, attempting to send to EJS@ES works just fine:

$1B; SENDIT>>TRNE 40   0/   51452,,100425      ↑N
SENDIT+2>>TLNE GETS+1   0/   51452,,100425      ↑N
SENDIT+3>>JRST MAKE6N      ↑N
MAKE6N>>TLNN KILBUF+34   0/   51452,,100425      ↑N
MAKE6N+1>>CALL 7TO6      ◊↑N
MAKE6N+2>>.CALL 12627 (OPEN)   :calprt
Control Bits: A   0,,1
Arg #1: F   0,,6
Arg #2: CLI/   ORCAM G,545100(C)   456343,,545100   ◊1'ESCLI◊
Arg #3: H6NAME/   ORCAI E,@(C)   455263,,0   ◊1'EJS◊
Arg #4: 12626/   HRL C,646256(C)   504143,,646256   ◊1'HACTRN◊
↑N
OUTHDR>>TRNE SYMSL2+1   0/   53452,,100425

We're doing the same CLI open on EX (to ES), and it works there.

[eswenson1]

Well, I did the debug-mldev thing (having another user run MLDEV with breakpoints, and having first user set up translation to other user's MLDEV), and when I do that, :SEND EJS@EX works just fine. I've stepped through all the code and the sending user is correctly connecting to MLDEV, and through it to the EX ITS system CLI device for EX:EJS HACTRN.

But when I kill the translation and MLDEV job, I cannot send a message. I have no idea why. I had suspected it was my changes to MLDEV a while back, but I'm running the same MLDEV on ES and EX, and, as I said, when debugging MLDEV, it works just fine. So I'm stumped. Anyone have any ideas?

[larsbrinkhoff]

ATSIGN DEVICE does some magic to make device names like EXCLI work. I see it has ES built in, but not EX. Unless you fixed that locally?

[eswenson1]

Thanks, Björn! That was indeed the issue. I added entries for EX to @dev and now EXCLI works just fine.

[larsbrinkhoff]

[bictorv]

HTH, som man säger. :-)