eswenson1
commented
5 years ago I just confirmed that MLDEV replaces the contents of JBCDEV and FDEVN with $1' DSK' in some situation. I expected to have it do this if the host specified in these locations originally matched that of the local host. But I don't see how it does this. Here is the relevant code:
MOVEI A,BUF
PUSHJ P,NETWRK"HSTLOOK
.VALUE ;Host not in host table?
MOVEM A,HOSTN' ;Host number
MOVEM TT,NETWRK' ;Network number
PUSHJ P,NETWRK"HSTUNMAP ;Don't need host table any more
.VALUE
LDB A,[3000,,JBCDEV] ;Right-hand four characters
JUMPN A,.+2
MOVE A,[SIXBIT / DSK/]
LSH A,14
MOVEM A,JBCDEV
MOVEM A,FDEVNNote the "MOVE A,[SIXBIT / DSK/]" instruction. It is executed when the contents of A is not equal to 0. The instruction that setup A was "LDB A,[3000,,JBCDEV]" and the comment is right-hand four characters. The original contents of JBCDEV was $1' ES', so the right-hand four characters would be $' ES', which would never be equal to 0. So it appears it replaces these with $' DSK' in all cases (unless, I guess, the value of JBCDEV was 0).
So the fact that I found $1' DSK' in these locations in my post-mortem doesn't appear to prove that we're trying to perform file system i/o on ES. I would have had to look at the HOSTN location, where the host number is stored after the host lookup (and before patching JBCDEV and FDEVN). Next time I see one of these jobs dead, I'll look in HOSTN and NETWRK (the latter holds the network number).
bictorv
larsbrinkhoff
I have UPTIME running hourly on ES. Frequently, I log into to find one or more dead (stopped) MLDEV jobs lying around:
The PC is 2067 (LOSE2:) and the instruction there is .VALUE
The instruction that precedes this instruction (2066, LOSE1:) also has a .VALUE. This means that the actual reason for stopping was the .VALUE at LOSE1. The only way MLDEV transfers to LOSE1 is by doing a "JRST @CMDTB(A)" where A is 0. Inspecting the A register at the time of fault shows that it is, indeed, 0. The command table is laid out thus:
This suggests that the slave (MLSLV) responded with a reply of 0, which the above code suggests is invalid. The call to jump through the command table is preceded by:
The call to NTCHK (from the comments) tests the input network channel status. If there is input, NTCHK does a skip return. Since we are getting to the JRST @CMDTB(A), we must have had input and skip-returned. We then call REPLY1. This processes a reply from the server (MLSLV on the destination host). This does an NTIIOT and then moves the result to the A register. It checks for a RLOGIN reply and doesn't skip, but returns the result in A.
I was curious to see what host MLDEV was talking to. I think the device should be found in the JBCDEV address. That value was $1'DSK'. Maybe it is in FDEVN -- that value was also $1'DSK'. I expected to find a foreign address here. My UPTIME DATA file has entries for DB, ES, NO, and UP in it. I wonder if this is happening due to the entry for ES and it is the attempt to read M.F.D. (FILE) on DSK: that is dying. I checked both of the dead jobs I saw in PEEK, and they both have $1'DSK' as the device.
Does anyone know what happens when you attempt to access a file on the ES: device from ES? -- that is, rather than using DSK:, you use the machine name as the device? JOBDEV ES is linked to ATSIGN MLDEV. But is there any short circuiting done because the device (ES:) is specifying the localhost?
I'm going to patch my UPTIME DATA to not use ES, but rather some non-existent host, like MC. I will look to see if this cures my problem of dead MLDEV jobs.
I'm wondering, since all the deal MLDEV jobs are for the device DSK, whether these only fail when the host is my localhost.