DIGEST daemon dies

[eswenson1]

On ES, the hourly DIGEST daemon dies upon startup. It would appear this is because the hostname (ES) is not in the table (ITS).

First of all, why are installing this daemon if it isn't going to run using the source-defined ITS table? Secondly, how is this running in DB? What's the best thing to do here? a) remove from DB or b) made to work by adding DB to the ITS table (which currently has MC, AI, ML, and MD as the only known hosts), or c) convert to using the new mechanism in ITS for listing known machines?, or d) nothing, since this is only supposed to be run on those 4 hosts, in which case we shouldn't be adding a link in DRAGON to this daemon, which has no hopes of running on machines no in its built-in list?

[larsbrinkhoff]

I think preferably c, or else d.

My intent is that programs can be added even if they are not useful. Of course, if they are harmful they should be fixed or made inactive.

[bictorv]

Late response: I also noticed this. I'd say firstly (d), and then independently (c), but let people who want to run mailing lists on ITS add the link in DRAGON.

[eswenson1]

DIGEST daemon is dying in KA ITS because its list of ITSes doesn't include KA. We shouldn't add the link to the daemon if haven't updated it to include the machine name in its built-in list.

[eswenson1]

Actually, even after you fix the list of ITSes in DIGEST, it still dies. This time not because there is no entry in the table, but due to an ILOPR exception. It appears it is trying to return from a procedure call, and the PDL (stack) is all messed up (references Non-Existent Memory (NEM)).

[eswenson1]

DIGEST gets an two ILOPRs. The first is here:

ILOPR; GOBOPN+4>>MOVEI X,-3(P) X/ 0 E.A. _ CNST20+65

P=17 / -143,,PDL .upc/ 710000,,GOBOPN+4 / MOVEI X,-3(P) ^N GOBOPN+5>>.CALL CNST4+7 (RFNAME) x/ CNST20+65 =10101

Notice that if we step past the instruction that caused the ILOPR, we continue. What gives?

Also, what does it mean to MOVEI the value -3(P)?

Is the ILOPR because this makes no sense?

X, after the MOVEI is:

x/ CNST20+65 =10101

It was 0 before, so something got moved. By when, then, the ILOPR?

@larsbrinkhoff

[eswenson1]

Actually, it appears the ILOPR is on the previous instruction:

adjsp p,4

What is this instruction? I don't see it in the DEC-10 manual. It presumably is supposed to adjust the SP, but it appears to cause an ILOPR on KA.

adjsp has the opcode 105, which is unassigned. However, there is no error assembling DIGEST >, so someone must be defining it. I don't see if defined in any the .INSRTed files.

I wonder if this is a KL opcode that isn't present on KA?

[atsampson]

ADJSP was new in the KL10; the Processor Reference Manual says it's not implemented on the KA or KI.

[eswenson1]

Thanks, makes sense. We need to fix DIGEST to conditionalize its use for KL and/or replace it with whatever the equivalent would be. There is also a RETURN instruction in DIGEST, is this also a KL10 instruction?

Update: actually RETURN is just an alias for POPJ -- it is defined in the source.

[eswenson1]

I think, but haven't tested, that I can replace ADJSP with:

ADDI P, n
MOVS 1,P
ADDI 1, n
MOVS 1, P

where P is the stack pointer and n is the original parameter to ADJSP.

Anyone know a better way (fewer instructions?)

[larsbrinkhoff]

Old KA10 code will usually just do e.g. ADD P,[4,,4] or ADD P,[-4,,-4]. This will work as long as a half word doesn't wrap around.