In the days of batch computing with turnaround time of several hours, a good idea was to take the deck of cards to a machine that right away would just list the deck, that is, print the cards. Then go over the listing line by line to desk check.
In those days, some of the job control cards were tricky to get right. So, at a big meeting about the computing services, one frustrated user stood and explained that when he had a job control card that worked, he would laminate it in plastic, punch a hole in one corner, and hang it on a chain.
As someone who enjoys playing around with MVS on an emulator just to get an idea of how the IBM mainframe stuff actually works, I can understand the pain of job control cards.
I heard someone mention that only a single JCL statement has ever been written. All others are copy-pasted from another one and just modified.
I believe this is true, since I had to try a lot of times just to be able to change JCL script to read FORTRAN code from a separate dataset.
He (not me!) used clear plastic so that, sure, he could see the holes, but, really, usually the top edge of the card had printing for the characters so that for a human doing the reading, didn't really have to see the holes. And for the machines, no way would they accept the plastic! He was so desperate to find a way to get errors out of the control cards that he wanted the plastic for durability and was willing to copy the card at a key punch machine.
Once I was working in fluid flow calculations at the Naval R&D Center, the one with the ship model towing tank. I was at a keypunch machine typing in my code and comments, and the head of the place, a Navy guy, said that I should use the keypunch machines only for small changes and otherwise should write my code in the little blocks on the coding sheets and have the keypunch staff do the typing. I responded that I was good with a keypunch machine, since I could make control cards maybe better than the keypunch staff, and could sit at the keypunch machine and type my code just from my rough notes faster than I could fill out the forms AND could ad lib and type in the comments without ever writing them down, in total MUCH faster. The Navy guy let me do it my way!
E.g., for extended comments, say, at the top of some code, could have a simple control card that would type the 'C' Fortran comment delimiter in column 1, indent to, say, column 7, permit typing, and at column 73 automatically move to the next card, type the 'C', and stop at column 7 again. Semi-, quasi-amazing!
For moderately advanced jobs the IBM JCL (job control language) was so tricky that a good solution was to use a keypunch machine to make copies of control cards that had actually worked! Then either use the exact copies or make small changes -- net reduce JCL errors, important when job turn around time was in the hours.
At one time I was writing PL/I code to run on an IBM 360/91, the one at the JHU/APL Navy lab, to read 7 track tapes written in submarines at sea. Each reel of tape had data from several trials. The guys on the submarines were really good about putting delimiters between the trials: They used a Dymo label maker and put the sticky plastic label on the tape. Then on the 380/91 -- you guessed it! -- the tape started reading, really fast, powerful tape drive motors, and suddenly BAM, WHAM, POP, CRACK, SNAP, flutter flutter, the Dymo label hit the reading heads, stopped cold, and the tape broke and flapped in the vacuum columns! It was IBM's job to fix it!
When we got tapes with the dymo labels off, I had to read the data in in binary, lay over it a based structure, based because it was relative to a pointer. The structure had lots of bit string fields for the intricate structure on the tape. Then my code had to do various conversions and return easy to use data! It was a box of cards -- took a while.
Later one week I raced through Blackman and Tukey, The Measurement of Power Spectra, got smart on power spectral estimation (mostly chi-squared statistics), typed PL/I code furiously, for about 1000 lines of code, and had the code generate white noise, pass it through a filter, record the resulting power spectrum, and show that as the noise signal continued the estimated power spectrum converged to the one used in the filter.
The code illustrated clearly how long a stream of data was needed for an accurate estimate of the power spectrum. Basically what is needed is enough cycles at the frequencies of interest. But since their data was to be from ocean wave noise, the frequencies were really low so that for enough cycles the length of data they needed for accurate estimates was quite long, in uncomfortably many HOURS.
But my illustrative code cleaned up a technical point in a competitive proposal for some software, and as a result of my little PL/I effort got our little company "sole source". Ah, punched card days.
When I got to Ohio State as a B-school prof, the students were STILL forced to use punched cards. I mounted an effort to get a good time-sharing computer, with ADM dumb terminals, for the B-school. The CIO opposed me. IBM and their super salesman Buck Rodgers opposed me. The Deans took my advice, and I won.
We got a Prime, nice computer, a single board bit-sliced super-mini version of Multics, maybe the one Mike Bloomberg started with. Nice multiple virtual storage machine, with security rings (Intel 386 borrowed?) with a nice hierarchical file system with security from capabilities and attribute control lists, all in 40 KB of code! Nice machine!
I was appointed Chair of the college computing committee and put on a committee to pick a new CIO for the university. I taught a grad seminar in the selection and evaluation process. Fun days!
In those days, some of the job control cards were tricky to get right. So, at a big meeting about the computing services, one frustrated user stood and explained that when he had a job control card that worked, he would laminate it in plastic, punch a hole in one corner, and hang it on a chain.