Very good day in spite of the remaining gremlin

 INVESTIGATING THE ONEDARK SIGNAL FAULT

I used my voltmeter and quickly realized this was not the same root cause as my earlier hairline fracture, even though the symptoms were identical. I was seeing valid logic levels that would switch to true when the fault was present. In order to debug this further, I would need to trace the individual signals that generate OneDark, thus the machine had to be partially disassembled and the extender board used.

Once I had the extender board in place, the fault was gone! Typical of this possessed bit of machinery. Still, that meant I could do some archiving until it returned. 

ARCHIVING OVER 16,000 CARDS IN A FEW HOURS

I was able to process all the remaining trays of cards with a tolerable, low rate of errors. Sporadically I would get Read Checks or other failures but could rerun to get past the issue. I have lots of system software, utility programs, contributed programs shipped by IBM, games, and other goodies that I have captured.

THE HANGING CHAD PROBLEM - CAME THAT WAY FROM IBM PROGRAM DISTRIBUTION

One program deck repeatedly threw verification errors, across many different cards in the deck. Interestingly, all were at column 6. I inspected the cards where the errors arose and found small hanging chads on the rear of the card, where the machine that punched the hole in the card left it attached along the bottom edge of the hole. It would flop around, so that sometimes it read as a hole and sometimes it blocked the light and read like a 0. 

I had to tear off the chad, rerun, and find the next case until I was able to read and verify the entire deck after a very tedious session of many many runs. This is the only deck where I have run into this problem (and the only time in my entire career working with punched cards). 

I realized this failure could not have been produced on the 1442 card punch that came with the IBM 1130 system, nor from a keypunch. The 1442, like the keypunch and like the Documation readers, reads cards so that the columns move serially through the machine, capturing the 12 rows at a time before advancing to the next column. 

The only way this could recur so many times on exactly the same column was that there was a defect in the card punch only for that column. Few card punching machines from IBM operate with 80 separate punch dies operating simultaneously, moving the card serially from row to row. The IBM 1402 from the 1400 series computer, the 2540 which was its descendant installed on 360 systems, and a few tabulating machines are all that comes to mind. 

That is, a card enters with the top or bottom edge going into the reader throat on a 2540 and it moves past 80 read brushes or 80 punch dies, row by row. The 1442 and the keypunch has the card enter with the left edge into the throat and moves it past 12 photocells or punch dies, column by column. 

This deck was created on a defective machine at IBM and shipped to the owner of the 1130 system from their Program Information and Distribution (PID) department. 

PROBLEM RECURRED AND I NARROWED DOWN TO THE AREA OF THE ROOT CAUSE

The problem came back, the machine moved three cards while transmitting no data and giving a pick check. The OneDark signal was a valid logic true level. I began checking the voltages at the inputs to the Control board, one from each of the twelve phototransistors, and soon found that the row 9 phototransistor was the one reporting a dark situation, all others seeing light. 

Since this entered the circuitry already in error, the cause was elsewhere in the machine rather than on the PCBs. I began to manipulate the various cables and devices that link the read station to the PCBs. It was not sensitive to tugging or moving the cable, which meant I could rule out an intermittent wire in the cable. 

The 'other side' of the phototransistors are a set of 12 LEDs that produce the light which either passes through holes or is blocked by unpunched sections of cards. A set of adjustable resistors inside the base of the reader sets the brightness of these so that the dark and light signals are very reliable - not so bright that it shines through the card stock but not so dim that the light through a hole doesn't cause the phototransistor to conduct. 

These resistors and the wire cable up to the LEDs sit on a daughterboard which plugs into the larger power supply board. I moved the cable up to the LED with no impact, but when I tapped the daughterboard, my OneDark issue went away!

At times while reading all the thousands of cards, the intermittent issue would trigger a difference between the 'read' and the 'verify' passes of the card decks, or trigger a Read Check, but those could be solved by a rerun. A couple of other times the reader settled into the steady OneDark and its symptoms, but all I had to do was gently rock that daughterboard to resolve the issue.

I now know that the problem is in connectivity either on the daughterboard, in the variable resistor (less likely) or in the connection to the main power supply board. I have had sporadic errors where I saw Stacker Check raised along with Read Check, yet there was never a jam or issue in the stacker (where cards are stored after reading). The Stacker resistor is adjacent to the resistor to adjust row 9, increasing the chance that this is a failure on the daughtercard near those variable resistors on the end. 

Once I am through archiving, or if the rate of this failure increases to force me to switch over to repair early, I will pull the power supply and daughterboard, find the cause definitively and eliminate it.  

Daughtercard whose manipulation cures OneDark problem

Location of the daughtercard inside the base of the reader

HUGE BACKLOG OF FILE PROCESSING, VERIFICATION AND ORGANIZATION AHEAD

Because I have read so many trays of cards and so many separate programs, some in multiple segments due to length, I have to concatenate files, organize and document them, study them, and fix some cases where I found a section of a program out of order in the trays. This will take many hours of work while I am away from the shop. 

Ultimately I want all the card decks properly organized, documented and shared so that others have access to all this software. That is the end game for this archiving activity. I also have a few hand written notes on index cards or the backs of punched cards that reflect instructions for use of various utility programs, all of which need to be captured.

This card was stored with DISKDUMP and DISKREAD decks

THINKING ABOUT THE MYSTERY MODIFICATION FOR DOUBLING THE CR81 SIGNAL

The odd modification I discovered in my two Documation readers, that ignored the state of the lower order bit of the column number, resulted in checking for all dark rows twice, at the time of column 81 and again at the time of column 82. This made the machines very intolerant of cards with a diagonal notch on the right side. 

It is a well shared weakness of the machines, yet an odd one since right side notches are a legitimate version of punched cards that were prevalent enough that Documation must have run into them while selling these machines. The documentation does NOT list this as a restriction or warn the user about right side notches. 

One of my machines has a plate on the side listing its ownership as Jefferson County, Colorado, which is consistent with the widespread use of these machines for tallying votes a few decades ago. That led me to think that this modification was made for machines used in vote counting. 

The check that all rows are dark at the time of column 81, the originally designed test, is done to catch times where the card did not move through the read station the amount that was expected. If there is a light at column 81, or any dark rows at column 84, this indicates a movement error and the data is suspect. It generates a Read Check to warn of this problem. 

Installing this modification would add a check for all dark rows at column 82 time, thus making the error checking a bit more stringent. It may be that these were introduced to catch more issues because data integrity is important for vote counting. In the voting role, the reader would only be processing cards specifically created for the election, thus they could ensure that the card did NOT have a right side notch.