We had an intensive debugging session this afternoon, watching serial line transmissions on the 2065. There were irregularities in the parity bits on some of the transmissions, so we experimented with non-standard settings on the Lantronix boxes we used as test equipment, then on the Cisco terminal server lines which we had defined as outbound ports for Kermit sessions.

DEC communications equipment of this era generates 7-bit characters with even parity, and accepts both 7-bit even parity and 8-bit no-parity input; however, for Kermit file transfers to work properly, we have to set the outbound ports to expect SPACE parity (constant 0 in the high bit) on the terminal server. We have no explanation for why this works, but we are satisfied that it does.

We are now experimenting with various file transfer settings in Kermit-10; so far, 7-bit text files appear to work fine, but 8-bit and 36-bit files are not being transferred as expected. Now that we know about the sensitivity of the outbound ports to parity settings, this should be simpler to debug.

From a report to the owner:

STATUS: The system continues to run reasonably well; in the past two weeks it has crashed twice due to momentary glitches in front-end disk access, but it re-boots easily and runs like a champ.

        Status of KLD DEC10 Single-CPU at 18:01:23 on 21-Feb-105

        Uptime 148:02:20, 93% Null time = 93% Idle + 0% Lost, 7% Overhead
        13 Jobs in use out of 120.  12 logged in, 11 detached.

The disk replacement interface is coming along nicely; signals between the 2065's I/O channel and the disks on the Massbus are clearly defined on the logic analyzer screen. We will experiment with driving signals starting later this week.

We have determined that the "Kermit protocol problem" is not a Kermit problem at all, but something going on with the terminal server. We are able to connect a PC to one of the serial ports on the 2065 or to the Toad-1's console port with a null-modem cable and transfer files perfectly well; as a further experiment, we have connected two of the serial ports on the 2065 and run Kermit at both ends, successfully transferring files that way. We will determine what the best solution to the problem is this week.

Connecting line 12 (outgoing) to line 16 (incoming) via the null modem and a small kludge tower—no 25-pin female-to-female gender benders at hand, so used a 9-pin and a couple of 9-to-25s—we were able to login to the system, run a Kermit server session, and

1. transfer a file
2. get a directory of the remote end of the connection
3. log off the remote end by issuing the BYE command to the local end

We can once again conclude that the terminal server is getting in the way.

SUMMARY: System running strongly, awaiting debugging of Kermit and disk replacement

    Status of KLD DEC10 Single-CPU at 17:21:26 on 04-Feb-105

    Uptime 102:11:36, 93% Null time = 93% Idle + 0% Lost, 7% Overhead
    13 Jobs in use out of 120.  13 logged in, 11 detached.

Networking has created a mechanism with which we can watch the serial-line transactions of Kermit over the network, which will allow us to determine the source of the protocol error that prevents file transfers. The hardware is now installed on the terminal server.

We have begun pulling heads from the non-working RP06 drives to assess how many are usable as replacements in the working drives. So far, most look like they will suffice after a good cleaning.

From a report to management:

With the power supply tweak in early January, we were able to run the system for almost 17.5 days (419:33) until a transient I/O problem took it down temporarily; current uptime is three days since that reboot. This is stable enough to concentrate on other parts of the project (Internet access, additional disk drive repairs).

We are working with Networking to resolve a file transfer issue across the terminal server we are using to provide Internet access to the system since the system has no native networking available.The ability for users to transfer files electronically rather than via physical media is the last operational issue with making the system publicly available.

Additional disk space for user files is not a gating item for public access, but does need to be considered. We have a dual approach to providing this: First, we will repair an additional disk drive to give ourselves room to grow, and second, we will implement a disk drive replacement system so that the historically important disk drives can be taken out of regular daily service.