Return to Stories

Punch-Feed Read
by Keith Falkner

You know the machine language opcode 4. It means Punch a Card. What does it mean when R is the D-modifier?

The 1402 can have a special feature allowing cards to be read from the Punch Feed, and 4R is the machine language code to accomplish that. The Autocoder opcode RF produces 4R in object code. If you want to, you can specify a Branch address, as in Punch-and-Branch.

Why would one read cards from the Punch Feed? In order to punch a calculation result or a value extracted from an external file back into the card that was just read. The timing is not critical. The RF opcode brings a card from the Punch Feed under some brushes, and the card's contents are entered into locations 1-80, without disturbing wordmarks in those positions, exactly as from the Read Feed. A later PUNCH command moves data from locations 101-180 into the card just read. It is OK to punch into a column that already has data in it, but there are two constraints: you must not create an invalid character, for example digits 5 and 6 in the same column, nor may you punch a hole that is already in the card. So if a card contains 3 in column 11, you could punch & in column 11 giving C, or 8 in column 11 giving #, but you could not punch L because that would repunch the 3-hole. Punch Check would be the cause of the stop.

IBM's Toronto Datacentre had several Punch Feed Read applications, and these jobs were quite vexing to the operators. Each job involved the mounting of special forms and a special carriage tape, but the programs did not provide a forms-alignment routine. That meant extra work for the operators, because the jobs could not be re-run, in case the forms were not aligned perfectly. Re-running a punch-feed-read job would result in repunching the results and therefore sending the punch dies through holes already in the card; as I said, that is a no-no.

The operators learned to reproduce the first several dozen cards of the input data, and practice with the copied cards until the forms were aligned perfectly. That in turn meant finding an 80-80 rep program (which is one card), and keeping track of the reproduced cards, the rest of the input data, and the copies, and not losing track of which was which. I learned of these troublesome jobs when I was hob-nobbing with some operators, while waiting for weather to improve for my motorcycle ride home. I studied the layout of the forms, and devised a one-card form-alignment routine that could be inserted into the middle of a condensed object deck, anywhere after the bootstrap (3rd card) and the last card. This card printed a period in a certain print position, advanced to a new page, and halted. If Sense Switch B (the standard switch for forms alignment in Toronto anyway) was on, it repeated the process; otherwise, it cleared itself from memory and resumed loading object code. This rudimentary alignment logic was a great time saver for the operators, who had been complaining about the tedious extra work for quite a while.

The card looked something like this:

Starting in column 01:

,021024,/299M0232642F1.B019B/061039

1 11 1 11 11 1 < where wordmarks get set

Starting in column 40:

,008009,013029/001332,0010011040

So long as the period was properly positioned, the forms would be perfectly aligned, and the operators never again had to reproduce some of the input data for practice runs. I enjoy realizing that only the elementary nature of the 1401 made it possible to insert such a routine seamlessly into the loading process.