8

Was there any equipment which could directly print out the program or data on a stack of punchcards, without first loading the deck into a general-purpose computer?

In other words, a transfer from the machine-readable hole pattern, printing to a typewritten human-readable listing on a line printer. Decoding the pattern of holes into printer signals is fine, extracting a data field is fine, but I do not mean adding up data. Such a device could print out a source code listing, or print addresses for mailing. (I don't mean making the cards in the first place, nor labeling the card, nor copying a card to another card.)

5
  • 4
    There were machines to directly produce punch cards from a keyboard, or to copy punch cards, if that;'s what you mean. That's how programs were typed in in the first place. – dirkt Nov 10 '20 at 11:07
  • 1
    Do you want the printing on the cards, or a listing on paper? Are the cards intended as computer input or something else? – another-dave Nov 10 '20 at 13:07
  • @dirkt: That's not at all what I asked. See the clarified question. – DrSheldon Nov 10 '20 at 13:35
  • If you wanted to read what was on the punch card, then you printed the contents on the punch card when you made them, for example like in this deck at the top. No line printer needed, no computer needed. – dirkt Nov 10 '20 at 17:21
  • 2
    This question is kind of vague and subjective. What is meant by "without calculations?" What's meant by "computer"? Need to be more specific about the requirements for such a device. – barbecue Nov 10 '20 at 18:28
18

Punch cards predate computers, so yes, of course, there was. A printing tabulator like the IBM 402 or the IBM 407 should be able to do that.

13
  • Could you clarify if these machines could directly print the contents of the cards? The Wikipedia pages talk about adding up data on the cards, which is not at all what I am asking about. – DrSheldon Nov 10 '20 at 13:47
  • Printing tabulators are computing machinery. To make them print a card content meant 'writing' a (plug board) program that directed each column of each card to a corresponding column of the printer output and let it feed after each card.(to enable empty lines). So neither of the machines mentioned can do it without programming. – Raffzahn Nov 10 '20 at 14:05
  • 1
    @DrSheldon - These machines were programmed through wiring for specific tasks. If you look at the picture in the Wikipedia article on the IBM 407, you can see the machines programming on the bottom right. They could be programmed to print certain columns verbatim, sum up other columns columns, and print the total when yet another column changed. If you wired them to just print all columns, you'd get the listing you've asked for. See also the manual at bitsavers.org/pdf/ibm/punchedCard/AccountingMachine/…, esp. p. 16 – Michael Graf Nov 10 '20 at 16:57
  • 2
    @MichaelGraf - "printout on paper" was only made clear some time after I'd posted the interpreter link – another-dave Nov 10 '20 at 17:40
7

Was there any equipment which could directly print out the program or data on a stack of punchcards, without first loading the deck into a computer?

No. Such a dedicated device did not exist.

Neither during the time pf punch card processing (pre-electronic computer) nor and even less after electronic computers became a thing. The simple reason is that there was no need to do so that would justify construction of a special purpose machine.


Then again, it depends on your values of 'program', 'directly', 'loading' and 'printing'.

'Printing'

Now, while there is no card reading printer (at least none I know of), there are (alphabetic) interpreters (like the IBM 557), whose purpose was to read a card and print one or two lines (depending on model) onto the very same card.

Also, beside the fact that they could only print 60 characters per line, they as well need to be programmed to do so. A plug board had to be setup defining the print position, for each column read of the card, to be used.

The reason such a specific device as an interpreter was build was the need for automated production of cheques. So all data for a check was punched on a card with a printed on cheque form by the producing tabulator. The resulting stackwas then moved into an interpreter to translate certain fields into human readable print, making it a valid document, banks (in the US) were required by law to accept.

Without Computer

Before the advent of electronic computers there were tabulating machines, especially printing tabulators, of which some could print alphanumeric characters. Then again, a tabulator is the computing instance of that age (*1).

To make them print a card content meant 'writing' (wiring) a program that directed each column of a card input to a corresponding column of the printer output and let it feed after each card (to enable empty lines).

'Loading'

Now, having a program on card(s) means that we talk about electronic stored program computers - so no printing tabulator. In that case there there no way around using a computer. But the program had not to be loaded, but just processed as data.

How it was done

Keep in mind, (360ish) Mainframes were meant to shovel data, so that printing a card stack is like their perfect job description. All it needs is a simple 'read-card;print-line' loop. Each iteration is simply one machine instruction for reading and one for printing plus a conditional branch executing the loop as long as there are cards in the hopper. Setup is usually all static data or maybe one or two move instructions to get it in place.

So it could be done on bare metal with a few preceding cards holding the program and starting the combined stack as a job.

These copy jobs were that essential, that every OS I've seen, even the most primitive, contains built-in routines to do so (*2), usually accessible via a console command, or by having a card with that command preceding the stack. Essentially a cat <punch: >prn:.

Being such a basic task for a mainframe, it wasn't long that a dedicated spool job was added, waiting in the background for a copy (spool) command coming up and executing it at lowest priority level. This became even more handy with tapes and later disks, as now a stack could be read onto tape, freeing up the card reader (which was usually way faster than the printer) for the next stack, while printing took place from tape/disk.

Heck, having a spooler sitting in background and handling print from disk was so integral to (mainframe) computing, that one does not wonder that IBM requested Microsoft to add a print spool to PC-DOS. Where other micros added printer buffers to speed up printing and still stalled when the buffer was filled, IBM simply ported the idea of a disk based spool to PC-DOS. Programs should not print directly, but always print to a file and issue that file to spool to get it done in background.

The only drawback was that this idea was somewhat alien to all the micro-kids: 'What? A service printing files from Disk? What is it good for? Why on earth should I do that when I can access the printer directly? Also, why does DOS not provide temporary files?' (*3). As a result, PRINT did not get the attention it should have, but that's another story.


*1 - Not to mention that basically every computing center that got an electronic computer would throw out all tabulators right away - allone to save cost. And only computing centers with electronic computers would as well have programs on punch cards, as tabulators were programmed by plugboards, not cards.

*2 - Of course a bit more complex than the mentioned program, as the requirement was to copy between vastly different drive, so a lot of setup was required, with the core loop being exactly the same. So three instructions for the loop and maybe 100 for setup :))

*3 - The classic issue with programmers only seeing their own program and the single task at hand - still today.

18
  • This is not what I asked. See clarifications to the question. – DrSheldon Nov 10 '20 at 13:40
  • 1
    @DrSheldon Thanks for the clarification, still I think I did answer it in the very first sentence: No, such a device did not exist especially not at a time when programs were stored on punch cards. --- Added some emphasis to make it less hard to find – Raffzahn Nov 10 '20 at 13:57
  • 3
    throw out all tabulators right away - allone to save cost - Key to this, which many people may not realize, is that an awful lot of IBM equipment was rented. So it wasn't "keep this already-paid-for equipment around until it breaks", as we might do today with old computers/peripherals, but "send it back to help pay for the new stuff". – manassehkatz-Moving 2 Codidact Nov 10 '20 at 16:02
  • 1
    @supercat But also keep in mind that some mainframes were really, really, good at handling I/O processing in a way that didn't block primary CPU usage. It took a long time for typical microcomputer operating systems to catch up with that architecture. – manassehkatz-Moving 2 Codidact Nov 11 '20 at 16:27
  • 1
    @manassehkatz-Moving2Codidact: Some certainly were. I suppose that raises the question, though, of the costs and benefits of trying to have one CPU with enough RAM to handle all jobs at once, versus having multiple CPUs, many of which would have tiny amounts of RAM. – supercat Nov 11 '20 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.