Did any automatic card punches have multiple hoppers to allow insertion of contrasting-color or other special cards?

Question

Many facilities that used punched cards would place many jobs into a system's feed hopper, and then separate them afterward by relying upon jobs starting with color-coded cards.

If a high-speed card punch needed to produce output for multiple jobs that would need to be physically separated, would there have been any means by which it could automatically insert contrasting-color cards to indicate where an operator should separate the stack? If so, how would different card stacks be chosen? Could such systems produce human-readable indications about what should be done with various stacks (e.g. perhaps by heading a stack with a card that the operator would be expected to discard, hole-punched with e.g. two rows of human-readable lettering in a 5x5 font)?

Answer 1

No, not that I know of.

Such an addition would make the machine ever more complex and expensive, while at the same time making not much sense in real shop procedure.

One could see that idea as premature optimization - looks interesting at first but spends effort in optimizing a non existing bottleneck.

---

Card Production is Detatched

A look at card production shows that insertion of dividers at that point doesn't make much sense, not at least as different jobs, even if outputted in sequence, will go to different recipients.

For card production

• a punch would usually go into hold after each stack
• operator takes the stack
• presses start
• next stack get produces
• meanwhile the operator puts the stack in whatever bin system they use for storage

That way no manual interaction (browsing for coloured cards) is neccessary, making the over all handling way faster and less error prone at the same time.

Solution is Cheap

Now if one really wants to have several output stacks combined with coloured dividers, a simple modification of above will do it:

1. A stack gets outputted
2. Operator inserts a coloured card on top of the output
3. Operator presses START
4. Next stack gets outputted
5. Repeat 2..4 for all to be combined
6. Take combined stack and place it in box.

No hardware needed :))

---

[Insert:]

Spool is Docker for Mainframes.

Note also, that this is not really holding up the card producing program (or CPU) due to synchronous output. This is what Spool is for. It collects output when produced, freeing up the CPU for other jobs, and doing real output whenever those devices are ready. Spool is purely operator controlled. It separates job environment and I/O handling from physical devices, their speed and readiness.

Remember, mainframes are all about maximizing usage. So this also goes for input. Spool thus also handles input of jobs. Thus the physical read-in (aka Spool-in) of cards is not related to execution. That way job preparation can happen independent of execution which again is independent of output.

---

Input Works the Same Way

Job input process works the very same way:

• Stack gets placed in input hopper
• START is pressed
• cards are spooled-in
• stack is talken and placed in whatever bin.

No need to form a combined stack to speed up processing. Even better, that way the different jobs never mangle, so no need to spend time in separating them again.

Note, there are of course situations where multiple job are read in an processed in sequence - but they are a single job from a handling PoV. they will never separate and will always be handled as one. So again, any coloured card are of no concern for the operator.

Datacenters are Factories

Sure, I bet many of you - like all students back then - have seen some operator putting a stack in, pressing some buttons then the reader humms, some light flicker and a line printer shoots out a 3 meter high bow of paper. That's a great demonstration, but is misses any relation to a real world datacenter. Having a CPU standing around not working is a huge waste of money - same for readers, punchers or printers.

Like in a factory, a data center is all about the production line, not the single product. It's not to make one job to run as fast as possible from card read to output, but to handle as many jobs as possible over a day. Spool is the main tool to do so.

• Spool-In
• Processing
• Spool-Out

are distinct steps handled independent according to different handling procedures.

Also data centers do not really work ad hoc. It's all on long term planning.

Nostalgia of the Poor.

Beside demonstration, back then for students or nowadays in museums, there was only one area where a direct input-exec-output relation was somewhat common: The lowest possible end - like IBM 360/20 installations. Those were most often direct replacement of mechanical processing.

Than again, those are exactly the installation wich neither need automatic insertion of dividers, as their number of jobs is rather low. Nor can they afford more expensive devices - if they could, they had already bought a bigger system with disks or at least tapes.

---

Long story short: No, that wouldn't helped much nor fit the way datacenters (have) operated.

---

But...

Having all of that out of the way, there were devices that could have been used a bit like imagined. Some card reader/punch combi devices had two output hoppers. The above process could have been speed up a tiny bit by using them in alternate fashion, so the next stack is already punced while the first in emptied. Then again, that's the time you need to grab a stack and press a button. Not really worth it, or is it?

---

Now for the Second Question:

Could such systems produce human-readable indications about what should be done with various stacks?

Why at all? That's what JCL is for and it's already punched as part of the job. Not to mention that job title (and optional remark) is already on the top card.