Working on some peripherals

1053 CONSOLE PRINTER RESTORATION

The main erratic behavior left on the 1053 concerns carrier return operations. Sometimes it oozes leftwards and won't disengage. More often, it skips over the left margin stop and is typing from too far to the left of the page. I will keep running this while I debug various SAC adapter functions, hoping that repeated use will relieve any residual stale lubricants and make this perform more consistently well.

PERTEC MODEL 31 DISK DRIVE RESTORATION

In the sunlight, signs of corrosion were more apparent. A spring had a light rust coat and the brushed aluminum front trim was quite oxidized as well. I spotted crumbling insulation at the air inlet to the disk cartridges, an expected problem area. This further reinforces my belief that this drive deserves a tear down to find and fix or replace any such damaged parts. Fortunately, the key parts like the heads, arms and access methods are problem free, as are all the electronics boards.

DIGITAL TSZ07 9 TRACK TAPE DRIVE RESTORATION

I received this tape drive yesterday and did some initial checkout. It seems clean and intact, powers up and passes its self test, and runs through an unload cycle without a tape inside. This morning I stuck in a blank tape and checked on its ability to self load. With that proved out, it was time to try writing and reading tapes.

To test the write and read capability, I started the built in service aid #211, which writes 32K byte blocks on the type all the way to the EOT marker, then reads those backwards to the beginning of tape, reads forward to the EOT, then rewinds. This was done at both 1600 BPI and 6250 BPI densities.

Initially, it failed with excessive write errors - one track errors found while writing the blocks - but I thought that was likely due to the vintage 'new in box' tapes. I ran service aid 222, which was a motion tester, moving the tape back and forth in short yo-yo patterns all the way to EOT and back to the beginning. I then reran test 211 which only found a couple of bad spots during write and then read backwards and forwards at 1600.

Next up was 6250, which is more sensitive to short flaws in the tape because of the higher bit density. It failed, as I expected. When I reran 1600 it also failed immediately, so I took out the tape and re-cleaned the heads and key transport points. That done, I restarted the tests from the beginning. I can hear that there are a couple of bad spots right at the beginning of the tape,then it settles down to long error free writing. Worst case, I will move the load point in about five feet to skip over the known problem areas.

After the cleaning, it ran the 6250 test successfully so all that remains is to test that the SCSI interface works properly. I set the unit to SCSI address 4, to allow it to co-exist on the SCSI chain with my IBM 9348 tape drive. I then moved the drive into the data center shed where it could join the other drive and the P390 system.

P390 SYSTEM CHECKOUT

I hooked the Digital TSZ07 tape drive to the P390 and brought it up to do some testing. I can successfully rewind and rewind/unload but my initial attempts to do any forward spec, write tape mark or other operation met with command reject errors. I discovered these are caused by the default mode of the CMS tape command, which requests the tape drive to set itself to 800 BPI.

Since my drive supports only 1600 and 6250, it correctly responds with the error. When I go back to testing this, which is low priority for me, I will figure out the CMS Tape command options to set the tape for 1600 or 6250. That should clean up the problem.

My IBM 9348 drive decided to spiral downhill and refuse to run its power up diagnostics at all. The first time I turned it on, the diagnostics completed, but when I tried to do so again in order to run it through its complete set, something went wrong. An even lower priority that the Digital drive verification, so this can sit there until I get back to it.

It is quite annoying to have to wait for the default 70 seconds for each screen of the virtual 3270 to clear. I had found a command to shorten the timeout once but I can't locate it in any of the manuals or online references. The cause is that VM/370 used an attention key called CNCL on the 3270, which was used on 'system' type keyboards but wasn't found on most 3270 terminals that end users would access.

This means that the 3270 emulators like Procomm don't include a mapping for that key, which is the only way to immediately clear the screen and see the next screenfull. While there are mapping files to customize things, one has to figure out where those are, how to modify them, and most mysteriously discover exactly what keyword the program uses for the CNCL attention key. Using VM without fixing this turns every session into a long and tedious one, with enforced 70 second delays every time the screen fills with lines.