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.)

DrSheldon
  • 15,979
  • 5
  • 49
  • 113
  • 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? – 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

2 Answers2

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.

Michael Graf
  • 10,030
  • 2
  • 36
  • 54
  • Interpreters from 1930s onwards – dave Nov 10 '20 at 13:02
  • 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 http://www.bitsavers.org/pdf/ibm/punchedCard/AccountingMachine/224-1614-13_402-403-419.pdf, esp. p. 16 – Michael Graf Nov 10 '20 at 16:57
  • @Raffzahn - I understood "a computer" in the question to mean "an electronic, software-programmable computer". I wouldn't consider a tabulator to be a computer, in the same way that I don't consider a mechanical adding machine a computer, even though both are "computing equipment"; much less a tabulator that is wired straight through and has no chance to do any adding. – Michael Graf Nov 10 '20 at 17:03
  • And no, I don't consider the translation of punch card codes to type wheel positions "computing", either - if you did, you'd have to consider every mechanical teletype a computer. – Michael Graf Nov 10 '20 at 17:05
  • @another-dave - Interpreters only print one or two lines on the card they are reading. Technically, that's also "printing out the data or program on a stack of cards", but I assumed that Dr Sheldon wanted a printout of several consecutive cards on one piece of paper? – Michael Graf Nov 10 '20 at 17:08
  • @MichaelGraf A tabulator is quite a piece of computing machinery (it's worth take a look at what how it was possible). This doesn't change if the programming is meant to only routing input data to output device (which BTW isn't enough, as form contol needs to be executed as well), it will still pass thru the processing part of the tabulator, aka processed. Otherwise a /360 doing a loop around two start device instructions must also qualify as non-computer as it only connects the input data block to the output device. – Raffzahn Nov 10 '20 at 17:14
  • @MichaelGraf Please don't come up with ridiculous assumption - to start with, tabulators didn't have type wheels. but more important, handling/programming of a tabulator was done independent of such codes in a logical manner. – Raffzahn Nov 10 '20 at 17:16
  • @Raffzahn - The Wikipedia article on the 407 says they did: "For printing, the 407 used type wheels, an improvement over earlier tabulators that used print bars." – Michael Graf Nov 10 '20 at 17:21
  • @MichaelGraf True, except that wasn't a wheel but 120 of them and they were not not like wheel printers, but fitted like a drum. A quite nifty parallel design. (oh, and they didn't need translation as they worked by the punch card columns holes split into two movements. – Raffzahn Nov 10 '20 at 17:36
  • 2
    @MichaelGraf - "printout on paper" was only made clear some time after I'd posted the interpreter link – dave Nov 10 '20 at 17:40
  • I don't see how this question could have an answer without that answer being this one. It's debatable if a printing tabulator is a computer - for sure. But if not, then it's not possible to have something do what the question asked, is it? – Joe Nov 11 '20 at 16:30
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.

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 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
  • Tabulators were not "general purpose computers", so they are a proper answer. And yes, they could be used in this mode, and occasionally were, at places in transition from tabulation equipment to true computers. – John Doty Nov 11 '20 at 13:38
  • Did any computing centers have a high-powered computer and a low-powered one, and a means of switching some peripherals between them? I would think that a computer with one or two kbytes of core and an integer-only CPU would be a lot cheaper than one suitable for more sophisticated computing, but could minimize the amount of work the fancier computer spent waiting on I/O. – supercat Nov 11 '20 at 15:30
  • @supercat I don't know of any such use exactly. But historically at many levels there have been smaller processors "helping" with peripherals. I remember at U of MD they had Series/1 mini as a translator for ASCII terminals to emulate 3270 for mainframes. And some 16 or 32-bit multiuser micros using Z80s for I/O processing. And even today consider that a keyboard will have a microcontoller so that output to computer has the right data without a lot of glue chips. etc. The question is whether that was ever done specifically for punch card read/print. – manassehkatz-Moving 2 Codidact Nov 11 '20 at 16:17
  • @manassehkatz-Moving2Codidact: I know that punched card readers and line printers were pretty fast, but tape drives can be so much faster that I can easily imagine that a job that might spend 30 seconds reading cards, 30 seconds computing, and 30 seconds printing (90 seconds of computer usage) might be reduced to 5 seconds reading tape, 30 seconds computing, and 5 seconds writing tape, thus tying up the computer less than half as long. – supercat Nov 11 '20 at 16:23
  • 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
  • In the old days (mainframes, but really through much of the minicomputer era and including MP/M, Concurrent DOS and similar micro OSes), one CPU, possibly paging to disk, was almost always the way to go. Only (relatively) recently has it shifted to individual CPUs (with RAM, I/O, etc.) being so cheap that multiple CPUs for user processes actually works out cheaper. But of course plenty of exceptions at every time & every level. – manassehkatz-Moving 2 Codidact Nov 11 '20 at 16:37
  • @manassehkatz-Moving2Codidact: In the days before interactive terminals, though, why would one want to have a CPU paging to disk? Wouldn't it make more sense to have a CPU read a job from tape, run it to completion, write its output to tape, and then read the next job from tape, run it to completion, etc.? – supercat Nov 11 '20 at 17:07
  • @supercat In many cases, yes. But remember you didn't have tape drives with microcontrollers and RAM buffers and so forth. Something had to control that tape drive - an I/O subsystem of the same mainframe running everything else. So paging to disk may not have made so much sense, but certainly running multiple processes - one slowed by the printer, another by the card punch, another bunch each waiting on a different tape drive - actually did make sense. One big CPU - admittedly clock speed & RAM comparable to an 8-bit or early 16-bit microprocessor - would run a ton (literally) of peripherals. – manassehkatz-Moving 2 Codidact Nov 11 '20 at 17:11
  • @manassehkatz-Moving2Codidact: From what I understand, tape drives were pretty fast, and were designed to start and stop very quickly (which is why they had all the loopy bits in the tape path). In the era when people were trying to produce the first language compilers, I would think a machine which could read and write a couple of tapes would have been practical for many purposes; even if the act of reading or writing a tape would tie up the CPU until it finished, many jobs would spend more time computing than reading or writing tape. The first FORTRAN compiler... – supercat Nov 11 '20 at 17:19
  • ...worked by loading the entire source program into RAM and then processing it, but I would think a compiler could have handled larger programs, with fewer phases, if the first phase read source code from a job tape and wrote an intermediate form to the other, and then a linker/loader phase read that form, performed any necessary fixups, and ran it. – supercat Nov 11 '20 at 17:24
  • All true as far as compilers. Which repeated itself - in reverse - in the micro era. The first microcomputer compilers I worked with were all 1 or more passes to compile, another pass to link, etc. Then along came Turbo Pascal that did everything in RAM! But I think a key change was the 360 - that changed to a "big machine do lots of things for different users (even if not interactive yet) at the same time". – manassehkatz-Moving 2 Codidact Nov 11 '20 at 17:27
  • @manassehkatz-Moving2Codidact: Turbo Pascal could also compile from disk, to disk, or both, and something very similar to it could probably have been practical on a 16K or maybe even 8K machine with a couple of tape drives that had separate start/stop controls. The output tape would be longer than a "clean" binary, but could probably have been written in such a way that it could be loaded directly if desired. – supercat Nov 11 '20 at 17:48
  • @JohnDoty Adding enough adjectives can exclude everything, isn't it? Beside that, your basic assumption is at fault. It wasn't asked if tabulators are "general purpose computers", but if printing could be done without a computer. A tabulator is by all definitions a computer, thus it is excluded by the qording. One that had to be programmed to read the card, process it and finally print it. It doesn't matter hat none of the higher functions have been used. – Raffzahn Nov 11 '20 at 21:34
  • @Raffzan "A tabulator is by all definitions a computer." Really? I've never seen a tabulator referred to as a computer. – John Doty Nov 11 '20 at 21:56