As a technologist apprentice we had opportunities to use these systems in the late 70's. However in the big company at the time all punch cards were made by a secretarial pool that was 100% female staffed. One of my colleagues who was a straight A type student, brilliant at everything, from a wealthy family, good looking and bizarrely also a nice chap who also was No 1 in all tasks kept failing at computing. He discovered why eventually. The girls in the card typing pool were 'adding' in messages on the job cards for him, asking him out on dates, and these didn't compile. Devil's own job to locate these little 'notes' in a stack of punch cards a foot high.
I had the good fortune to be taught by Professor Brailsford in the late 1970s, and it is great to see his enthusiasm, knowledge and anecdotes still able to educate and motivate as it did me in his lectures all those years ago. Great to see the stack of punched cards - I still have my set from my first year Computing project - a Chess program written in Algol 68!
Professor B. neglected to mention the fact that back in the day, every program was written out longhand --- either on a form, or on a pad/in a notebook. We would "desk-check" what we wrote, and then we would sit down at the keypunch machine to enter our work line-by-line. It took a long time. There was a period in the 1960s when we had mark-sense cards for programming in Fortran, and I suppose other languages. You would use your special IBM Electrographic pencil (in retrospect, I'm surprised IBM product people didn't come up with one of their ridiculous names, such as the 9850 graphite depositing device!), and you'd have a specialized reader/punch produce your source deck. Writing code was a lot of work. You had to write your code, go somewhere to punch it (don't forget you had to punch your data too !!!) , bundle it up, take it to a job entry station or put it in a box for someone to run it for you (assuming compile, link and go), then return later to retrieve your printed output from "your" box. Depending on where you were, you might have to wait as long as 24 hours for your output...and the output might simply consist of compiler messages telling you that you'd missed a comma, or that it tried to compile 5 lines of comments because you'd forgotten to put a C in column 1 (Fortran). Your commands to the compiler might have been wrong....or your code didn't work the way you thought it should... or maybe it worked....and you'd end up with a stack of fan-folded greenbar paper to pore over. Debugging code was an art and a science. We'd spend hours and hours going over our code, using nothing more than paper, pencil and mind to trace the execution of our work. We took a lot of pride in our ability to write clean code and to debug quickly. Each of us would have our own stash of handy routines and test programs to assist in the debugging and testing processes. After we started using teletype text editors (some of the early ones were so bad, arcane and user-hostile, you'd wish for cards!), things became a little simpler. There were no "studios", or syntax checkers, etc. , but at least you could write your code, save it, compile it, and review the output without resorting to cards. Such memories! It's much easier now.
I learned to program on an IBM 1401 computer in 1971, It had 16 K of memory, and no disk drive of any kind. It could output your results onto a printer, onto a tape, or onto new cards. No consoles or terminals, just a big panel with some big buttons on it. Over the summer, the school system (yes, one computer for the entire school system of over 100,000 students) replaced the IBM with a Honeywell computer with 64 K of memory. We could not imagine what we would do with so much memory. Still no hard disks.
In the mid 1960's I punched FORTRAN cards for input to an IBM 360. Sometimes my stack of cards was several inches high. I'd draw on the top of the stack so I could watch them move down as the high speed card reader inhaled a three foot long rack of cards. What a THRILL when my job caused the reader to pause for a second before the line printer started. It meant my job had actually run!
if XP were on punch card(~40,000,000 lines), supposing a .007 inch card thickness and being able to fit all of a line on a single card, the resulting stack would be 4.42 miles tall and weigh 145.5 tons!
11:12 - that trick of drawing a big V, or writing a word across the edges of the cards is also used all the time by woodworkers when they figure out in which order they want to join a stack of boards, but want to work on each individually for a bit, say to plane or sand each before final assembly.
I first learned to code around the 2008-2009 time frame (when I was 24 (!)), and I love learning about all this really old stuff. I never took computer science in school, my only experience was a class I took on a whim that taught VB6, and I really missed out. Recently, I bought an old computer architecture textbook for a few dollars that takes you from all the way from how transistors work through the C language, and it's amazing.
I'm feeling a little old...I started as a IBM 370 mainframe operator in 1981. Computer cards and Hollerith code everywhere. Then we got a data entry system and the cards were gone (as far as programming and most data storage). Doing hex math in my head, pouring over dumps, then looking through card trays of data to find the bad punch that caused a data exception (usually from assuming character data was in packed format for calculations). Collators - patch panels, wow!
Isn't it amazing that nowadays a supercomputer to them can fit inside our pocket! And we just use it to watch cat videos and get into random arguments.
I used the beveled edge to mark cards that needed attention. I would sit at my desk and proof read a program deck. When I found an error I would turn that card around so that it's square edge would stick out of the deck's beveled edge. Therefore keeping my place and additionally marking the deck as not ready for production.
There are some pictures of the kinds of machines Professor Brailsford is talking about in the original Mainframes film - see the description for a link >Sean
It's amazing how UNIX is referred as the "next step" in the whole explanation. Thanks for sharing how punch card worked. I liked the method of drawing pen lines on the side in case they ever fell off. Those were the real hardcore days to be into IT.
@09:27 The corner cut could be in any of the four corners, and intermixed in any order, as long as the card's orientation when read was the same as when it was punched. If the card was punched backwards and upside down, then it would have to be read backwards and upside down to be interpreted correctly, but the equipment could not detect either the corner cut nor the printing.
We worked on a massive Finite Element Analysis program in the late 70s. The master copy was stored in cabinets of trays of punched cards that covered one wall of an office. The usual practice was to use a ruler and magic marker to draw a diagonal line across the edge of each deck. That way, if you dropped a tray, you had at least a fighting chance of getting them back in rough order before having to go through each card to get them into the proper order.
I remember having to read some cards due to an issue that occurred when I was in the military. Our unit was in support of 3D Infantry Division and their supporting units for JUMPS. This was the current pay system (1971). I showed one of the soldiers that worked with me how to use the three zones (0, 11, 12) to translate the punches. To verify what I was reading I had him to run the card through an interpolator which printed the characters on top of a duplicate card. I read the card that had no printing on top. The soldier verified what I wrote out to be exactly what was on the original card. I don't think I could do that today. I also had the opportunity to prepare cards for transmission on the IBM 026 AND 029. We called that "cutting" cards. Normally we would receive a box or decks of cards that had to have a start "Header" and end "EOF" card made. The start card had the routing, serial number, classification, card count. The end card had the same thing to verify the card count. The card count always included the body or deck number and the two additional routing cards. The end or EOF closed the transmission of the deck with four Ns (NNNN). If the Header and EOF card did not match in the card count when the transmission ended, I would have to answer a service message that was generated from the system and recheck the deck by running it through an off-line card counter. I can't remember loosening any cards or sending any decks to the wrong station during my tour. I can say that I really loved doing that job. Thanks for a trip down memory lane with this video.
Everything I just heard I knew already. From my first computer-operator job. And I am relieved to learn that I did not exaggerate one bit all these years.
this takes me back - thanks! - old ibm mainframer here - one could multi punch any of the 256 byte combinations using an 026 keypunch - these values might employ more than 2 holes - also if you dropped a deck, in addition to the methods you mentioned, you could compare to any listing you might/should possess - a dropped deck is rarely completely random - blocks of cards tend to clump together - i think our last card conversion was 1980ish - thanks again!
While using it a lot, it is easy to take the humble "return" for granted, when getting information from one place to another. To have the output physically handed to you on a deck of cards and then having to manually having to insert them to deliver the output to where it's needed, now that is something I am glad we left in the past. Sorry "return", I'll never take you or your automatic delivery for granted again. We young people have it so easy today because of you.
@08:41 I am pretty sure that the mechanism for moving the cards on the IBM keypunches was by friction wheels, like what is used on most (all?) of the consumer printers today for paper movement
Back in the 70s, I used to maintain punch card equipment. As I recall, the official name for the device was "Interpreting Data Recorder". Also, way back in my grade 12 FORTRAN class, we used pencil mark cards. These were the same size and shape as a punch card and could even be read on some card readers. The 12 hole column was split into 2 6 mark columns, staggered so that the mark in one column was next to an unused area in the other. Incidentally, punch cards are why so many terminals and printers have 80 columns.
There was a begin and end card, a run program card and 1 card with 54 numbers whose position and value specified the location of each of 6 colors on the cube. The line printer would then print out a sequence of turns that needed to be made to your unsolved cube in order to solve it. I received an A+ on that project.
this is so cool that there are ppl that can tell u and explain the history of machines we are using today:) i love this channel and hope to see more guests with such great knowledge
I worked for the CEGB in the 1960's and spent many a happy hour loading trolley loads of cards into the reader connected to an IBM1401. We transferred all the jobs for the day onto magtape, to be run overnight on an IBM 7094 running the IBSYS operating system. The IBM7094 had 12 tape units and a giant DRUM. When a batch finished the tape units would go into high speed rewind mode - what a site - just wished I had taken a video of it. It is a shame the video does not show a hand-punch, because if you were desperate for a job, which had failed and you knew which card was wrong, you could hand-punch a new card. I still have a few cards in my desk drawer -for nostalgia's sake. If I remember correctly ICL could also read smaller cards - about half the width and less tall. I'd love to hear some horror stories about punch paper tape problems. Later we had an IBM punch-paper tape device that continually clogged up - IBM was cards - not paper tape. Later as an assembler language programmer on Honeywell 200 series - when a job failed - and you worked out what the problem was - you went to a hand-punch and created a patch deck that was added to the end of the program - all done in octel. Happy days and thanks for the memories
It was a good idea to always use sequence numbers in your cards. For IBM 360 Assembler the sequence number was in columns 73 to 80. You could tell the assembler program to verify that the source deck was in sequence. Column 72 was used to continue the card onto the next card - this was commonly used for 'macros' such as the DTF or DCB declarations. At the place where I learned programming, via OJT (On the Job Training), we had several IBM card sorting machines which were invaluable in the event of having dropped a deck of cards. All serious programmers should know an Assembly language. That way you have a much better understanding of what is actually being done by the hardware. Even in 'C' it is possible to write your code to take advantage of the quirks of both the compiler and the hardware. Of course it IS possible that what is best for one system is not the best for another.
Some columns did have more than 2 holes per column, number used a single hole, letters and three special character used 2 holes. All the other special characters had 3 holes. There were also binary decks that could have any number of holes punched per column depending on the instructions or data. On our old Honeywell mainframe we had a complete binary program stored on a single card that played a simple gambling game. It had many holes per column. You can see 3 holes in column 1 in this video at 8:17
My first job in computing began in 1971, working on an IBM 360/44. One of our card punch machines did not print on the cards at the top. I became adept at reading the holes.
I used punch cards and we had little silver stickers to cover up holes when we made a mistake. Also special characters used 3 holes per column. The electric punch card machines were in great demand so programmers were often forced to use manual ones with a key for each possible hole in a column.
This is great. I am old enough to actually have worked with those cards and related systems. Long before machines could read human writing (scribbles, sometimes) I used to be employed as an alphanumerical datatypist. The machines hummed, all kinds of levers and mechanical things in working. Splendid. Thank you for this movie!
My father used to work with these things many years ago: when I was growing up, there were great stacks of old punch cards in the house that he had brought home (presumably discarded from use), and he would explain to me (approximately) how they used to work. They were already obsolete when I was a child, and I am 36 now!
If you use two different colors and draw an X then it gets really easy to sort them faster because you can easily identify which cards belong in the first half, and which are in the 2nd half. When you have a thousand or more cards little things like this trick make a big difference.
In some shops, programmers would not even punch cards themselves. The programmer would write his program on a "coding form", which came in a notpad, each form sheet having 24 lines of 80 columns gridded out, plus some heading fields for identifying the programmer, department, etc. The programmer wrote his code in blocked letters, one letter per column, one line of code per row on to the form, according to the format of his chosen language. After appropriate desk-checking to make sure the code was seemingly correct, the coding forms would be submitted to a punched-card operator (a typist skilled in the use of the punch card machine). After the program was punched up, the programmer could swing by later and pick up his deck of cards, with the original coding forms for corrections if needed. Once the programmer was satisfied, he would submit his deck to the computer operator with some additional job control cards (as shown in the video). The computer operator would run job decks in order of submission, returning decks and associate line printer output back to the programmer. Whew! The turnaround on logic errors was brutal, often 24 hours or more to make any correction, which is why visual inspection of the original coding form was so important.
The old IBM systems (pre-360) was a computer with a whole series of peripherals: a collator, a sorter, card reader and punch, and a printer. Many functions could be performed directly on the peripherals with only minimal control by the computer. The machine that sorted your cards into order was the sorter; the collator did computations on the column data based on "programming" a hard-wired panel. The keypunches moved the cards mechanically. Some card readers used compressed air to pull cards off the deck quickly; the slot they had to go through was precision set to allow only one card through, and the compressed air kept a warped card from stopping the process.
My first FORTRAN course at university used punch cards and the typewriter ribbon was hardly ever changed so you couldn't read the line on the card. We learned to draw diagonal lines on the card stack very early on and we'd write numbers on the card as the reader would jam all to often. This was the early eighties and as undergraduates we could only use the old out of date computers.
for me as a developer thats like listening to a bedtime story ;) love it! It was really complicated back then, I am glad we have editors and real files nowadays.
As a Business Major in HS I took Keypunch and Collator Classes. When I got into the Marines I ended up applying everything I learned in HS. Interesting work.
I always enjoy your videos on the history of computer technology and programming. My professors would mention the days of punch cards and I always wonder how they worked on a high level. Thanks so much for making this video!
When I was a kid they used to give these cards to the public school. I still remember how much fun it was to build cars, houses out of these cards. Very pre-minecraft
You stated 80 column and the video stated 80 column cards. Professor Brailsford discussed a 6 bit computer in the video and stated it was done to make it cheaper to make. So,you're correcting me on things not discussed in the video. The 6 bit 80 column cards are 480 bits. The ones I used were 8 bit, but that wasn't what was being discussed.
Cool video! I remember my mom telling me about the old FORTRAN 77 days of punching cards. I tell her that the 2008 standard isn't much better. There's still a default fixed-form limit of 72 characters per line, and we still refer to things as "cards" and "decks" despite everything being stored in electronic form.
(continued) Once storage got larger, the operating system stayed in the machine between jobs, but you would still have to load the compiler. Early compilers were "multi-pass," where the computer punched a deck of "intermediate code" because the whole compiler was too big to fit in the computer, so it was split up into "passes."
I remember going out with a girl who was a programmer. Most people were using Monitors to input into for computers by then but some of her programming was still done by punch card so always had rubber bands on her wrists. My Dad while he was programming always had punchcards at home, think he was checking them, I was very young. He ended up running the department,Employment as programming was nwever decided on your Academic qualifications(although he had degrree). If you got an A or better on the IBM aptitude test you were if you interviewed well you were employed.Most had A+ scores.
There were "keypunches" with typewriter keyboards (there were typewriters, too), and there were "cardpunches" that were automated and punched cards at amazing rates. Still, at 80 characters a card, an "amazing rate" was still low bandwidth. Tapes were the way to go for speed. "Never underestimate the bandwidth of a station wagon full of tapes driving down the interstate."
Heard about punch cards for a long time but never cared to find out about them. Today I saw them for the first time. I can imagine how much some old people miss that era, the same way I miss my floppy days. I guess their days were more exciting.
When I started ('80) you wrote programs on paper forms and passed them to a typist to punch the cards. They were numbered but also had a diagonal line. Corrections were hand punched. You then handed it in at the operator window and dropped by to see if your results were there from time to time. We still had a paper tape reader :D
Back in college I asked my professor if I could combine the class projects into 1 larger project. I wrote a Fortran program to solve Rubik's Cube. It was appx. 1500 punch cards and would take so long to load and run the computer lab was tied up for nearly an hour just on my program. This was such a problem I was given permission to store my program subroutines as they were debugged onto magnetic tape so I wouldn't have to load the cards each time. When finished, t only took 4 cards to run.
When I started at my second workplace in 1990 they'd only recently migrated from an ICL 2900 series mainframe to a S39L65 dual node. We had a little ante-room called data prep where there were card punch and card reader workstations, but they had just moved away to rudimentary VDU input directly into wired terminals. So, I never quite managed to witness the world of punched cards in production UK public sector life, but I feel that I was fairly near the start of the VDU era and use of VME rather than TME. There was still a lot of mainframe mentality as much as technology; we would carve up the day into Transaction Processing (TP) and Batch times, with pretty hard immutable rules for what was and wasn't allowed in each window.
My father worked for Defense Computational Resources Working Group, and dealt with writing programs on punchcards. He had developed an optical auto punch card system and had special cards printed up for it. Those cards would have little boxes over the punch area. So you'd must mark it just like those old scantron tests. Then you'd feed it into the keypunch machine and it would automatically detect the mark areas and punch them. This was in contrast to doing it manually on a keyboard like he said. Ok. Then he had a system of transparencies with commonly used snippets of code written out, and an overlay pattern to trace at the bottom of it. He'd put that on a glass table and put the punch card on top of it so he could mark down the spots that were blacked out underneath. So it was a primitive way of using programming libraries, heh. He said he got the idea from a story he heard about Bletchley park where they would use transparencies to help identify numerical patterns in codebreaking. Later on when xerography (that's photocopying) came out, he'd just put the transparencies into the photocopier and then trim down what it spit out and fed them into the optical-punch machine. There were some other cool innovations, such as optical tape for feeding the patterned program data that way. That was just a flim negative with the optical "punch" patterns exposed on it. That of course needed a highly modified reader, but he said the system worked well. The system used for "recording" the data onto the microfilm was real low frills he said, and consisted of a Minox camera. He said he managed to get about 2k info of information onto an exposure of 8x11mm film, a roll of which held 50 exposures (and was dirt cheap).
In 1973 I dropped a whole box of punch cards containing the complete accounting "database" for the organization I worked for. For a few moments there was complete silence in the room till people, including myself, recovered from the shock. Luckily for me, 2 things were in my favour... 1. There were still large blocks of cards still in order on the floor reducing the effort required to place them in sequence. 2. All the cards had sequence numbers in the last few columns so I could verify they were in the correct order. Unfortunately we did not own a card sorter so I had to spend the next few hours putting the deck back into the correct order. The deck was then read into the mainframe's card-reader and the contents printed out so I could visually verify the cards were in sequence. Luckily the cost of the computer time was not taken out of my pay. I never dropped a card deck again after that.
I started programming in BASIC back in the mid 1970's and later wrote some programs in FORTRAN using punch cards. I could type faster on one of the IBM keypunch machines I had access to than I could on an actual typewriter of the day. It was something about the height of the chair, the height of the keyboard on the punch card machine, and the amount of force needed on the keys of the keyboard. I still remember the basic idea on how to read a punch card from the holes in it. I was able to read a few characters off the cards shown before the text was shown at the top of the card. I may still have something that has the details about the characters for each pair of holes in a punch card. I have a couple of programs in a box that are on punch cards, I have a manual for an old IBM keypunch machine in a box somewhere, and I even have the control drum for one of the old IBM keypunch machines. Ah, what memories it brings back thinking of these things.
Kids these days don't know how good they have it. I just barely missed the card punch era, but my professors were always on me not to let the compiler find the bugs in the program, because when they went through school they were charged for their jobs whether they actually compiled or not. I do remember having to type the bootstrap sequence into an ancient DEC machine (PDP 11/03 I think) at RPI for an assembly language class, in order to boot our 8" floppy. Ah, the good ol' days...
Wow, I can't imagine the hairpulling errors that must happen when those cards get mechanically punched incorrectly. It's easy to forget when I write code these days that I don't need to worry about my code not getting mechanically read.
Spuds7er - Yes, I'm amazed that I have any hair left at all; both for the reason you state, and also given that I've been around long enough to have been exposed to that hazard !
I know the 029 punches I used to use didn't print anything, it just punched holes. You had to number them by hand to protect against mixing them up. There was one 029 that did print what was on the card but you had to have an act of congress to be able to use it.
Two major funnies stick out in my mind regarding punch cards, one at the beginning of my career in the late 1970s, one towards the tail end in the 2010s: > Early Career: Straight out of college, I was working at a company developing a new payment tracking system on a Data General "mini-computer". My predecessor was an old mainframe guy, and, as the professor notes, would carefully update his program deck (COBOL), then read in the cards (close to 2,000 cards, if memory serves), compile the program, get his error report, then update the deck and start the process of re-loading the card deck into the computer and compiling again. Very time consuming! I was the hot-shot new kid, who was not only used to mini-computers, but also was quite versant in online text editing. The day after my predecessor left for a new job within the company, I loaded his card deck into the system one last time. I then, in full view of my manager, proceeded to take the box of cards and dump them into the trash bin. Needless to say, I got a horrified look from my manager, but I assured her that any and all corrections could now be done directly using the text editor. Much faster, and a lot less error prone. Of course, I hit my deadlines, so she couldn't complain. Of course, that was not the last of my hot-shot stunts that I pulled on the project. Luckily for me, all of my stunts paid off, and we went live on time. > Late Career: I was working at a large bank that had brought on a lot of young programmer from India to work on the development and support of our systems. One day, I casually mentioned my use of punch cards back when I was their age. To prove the point, I brought to work the next day some sample cards I had lying around my house (they make great bookmarks, by the way). Seeing their amazement and confusion over the cards was a lot of fun. I was only too happy to give them a few lessons in computer programming history, something that they never got in school!
I did computer studies ‘O’ level in 1982 in the tech’ night class and the (hands strictly off) mini computer read punched cards. I searched the house recently and didn’t have a single card left. Used cards didn’t really have any secondary re-use, the holes ruined writing on them. The tech’s ‘mini’ computer was fairly ancient back then and took the best part of an hour to manually reset after a crash. It was the size of a cupboard.
HAH, I still have a stack of about 1000 of these punch cards my grandfather brought home from work he used on his MAZACK (sp?) CNC machine for Kyle/Cooper/EATON Power Systems.
Actually had not just the card drop experience way back then... but turned a corner too quickly with my stack and ran head-on into another student with his card stack. Oh what joy that created :-)
Until the late 70's every bill had a punched card in it with the iconic words "Do not bend, fold, spindle or mutilate" on it. If you were late on your bills you could swap two different cards and claim you made a mistake. You still had to pay the overdue bill next month, but if you were lucky you didn't have to pay a penalty. My mother did data entry on a punch machine 8 hours a day for about 7 years. She said it was the most relaxing job she ever had.
Brady, you should make a playlist just of this fellow. The other presenters are great, of course, but this guy really does hail from a time when computers were maintained by a sort of techno-priesthood and programmers, users and operators had to approach them in a much different way.
I used punch cards in college - we were the last year to do so in that school - it was 1982 at Norwalk State Technical College in Norwalk, Connecticut. I don't miss them, but I'm sure I still have boxes of them in my mother's attic.
Okay. When we ran punch cards using Fortran, we were taught to number our cards, either by writing on them or by adding a printed comment in the code. If you had to add an extra card in the middle, you'd just use a decimal point. Simple, but easy enough to straighten out "n!" accidents. circa 1978.
Looks like this code was an early use of the NAG library. E01AAA - An interpolation function From the NAG mathematical library. This library is still widely used, but was originally released for ICL machines in about 1970.
Card sorters :-) ... & binary puchings Back in my starving student days, I'd dive into the card recycling bins, pull out bunches of cards, and run them repeatedly through the card sorter - one could only sort by a single column at a time. By repeatedly sorting, I could sort down until I sorted out down to all the cards that had the first - or last - 40 columns all blank. I'd then save those cards and return the rest to the recycling bins. I'd then use, as one of the first control cards in my program, a card which effectively said to only read the first 40 columns, and ignore the rest. Thus I managed to avoid the cost of ever needing to buy blank punched cards - which were sold for $0.25 USD per 100. A small percentage of those cards found were also completely unpunched - that was enough to cover the few lead (and possibly also end) cards I needed before the control card that limited the significant reading to the first 40 columns. And all these >= 40 blank column cards, I not only used for the punch card programming, but those >= half unpunched cards I also used effectively as "index" cards for the paper writings and the like, where I first needed to do outlines, and often sort and rearrange various bits before working into a draft and final paper. Binary punchings - though not so commonly done, the cards could be punched in a true binary form - typically done by computer card punch, not a keypunch station. That would give significantly greater data density on the cards - but also a structurally much weaker card, as on average half of all the holes would be punched. I even made some cards with all the holes punched - quite flimsy - and yes, they could be read, but unlikely they could be handled much and repeatedly read very successfully before suffering mechanical damage and jamming or tearing.
Thanks great video, learnt a lot. wish I had been there in the early days, thankfully I got in at the 8bit stage. But to get in to computers today must be a lot harder to get your head around than in them early days. I remember building my first logic state computer and it taught me so much on how to grasp the workings of what a computer is/does etc.
I was an IBM CE starting in the mid sixties. Repairing 024, 026, 029, 056, 059, 080, 082, 083, 084, 557, 088, 1401, 1402, 1403, 360 and related peripheals(tape drives, disc drives, 1403n1, selectric I/o etc.) Was trained by IBM while in the MARINE CORPS and served two tours in vietnam repairing the aformentioned equiptment. Continued in this occupation for many years as a civilian.
When I first began in the computer field, there was a keypunch machine & a keyverify machine. Before that, I used a teletype machine where I learned FORTRAN programming... We've definitely come a long way!
When I was in college there was an outside computer company that ran both cards and remote terminals. A friend wrote a program for it that ignored end cards and continue to run in the background, passing along the jobs but storing ID and password data that he would collect later. The only problem was that a batch would read as soon as it was placed in the hopper. The operators soon complained, but he got enough "free" account time to last his last 2 years, and nobody guessed what he was doing.
I am old enough to have used the punch card machine to punch my programs in FORTRAN (or was it COBOL?) back in the 90's when it was going out of style...
The stack of cards were placed in a hopper that would pull from the bottom of the stack. If the stack was over a few hundred cards the friction of the bottom card against the hopper would prevent the feed rollers from overcoming the friction and cards would get jammed. If a card was sufficiently damaged you'd have to go back to your hand written source code, print a new card and reload the entire program again. One person's job was to feed the hopper with the ideal amount of cards.
I remember my first CS class in 1975. We punched our little program onto cards and the "Perfessur" gave us each a few cards to put in front of each one. These were IBM JCL cards to run the jobs at the computer center. Fun times.
I remember a field trip to the phone company when I was in 4th grade in 1961 or so, and their office had a card computer for customer service and billing information. The switch rooms had floors of relays that connected the calls too...a different era indeed...
In early 90's I was playing with such cards - original from 70's. I used them to color numbers and generally draw on them. I don't have any card left. If I'd know their value back then... Well, even if they are now valuable, I'd love to have it on the wall and of course give most of them to local IT museum. It hurts they ended up in the trash bin.
Yes, many "special characters" were three punches. The IBM 3x0 series used EBCDIC instead of ASCII, and the EBCDIC table used to show the card column combos for each 8-bit EBCDIC character.
The size of the original "Hollerith" card came from the size of the US dollar bill at the time. Herman Hollerith had visited the US Treasury and noticed that they had equipment that could handle that form factor. The professor mentions a "collator". Actually it was a card "sorter" that could sort a deck of cards back into order, but you had to run them through multiple passes on successive columns and re-gather them after each pass. Google IBM 082 sorter. (ID SEQ was in cols 73-80)
i cracked up so much at his n-factorial joke. that was brilliant
Imagine a Windows update shipped as punch cards...
"There is no quicker way to discover what n! means"
Brilliant!
+salmjak LOL His wry comment cracked me up.
As a technologist apprentice we had opportunities to use these systems in the late 70's. However in the big company at the time all punch cards were made by a secretarial pool that was 100% female staffed.
One of my colleagues who was a straight A type student, brilliant at everything, from a wealthy family, good looking and bizarrely also a nice chap who also was No 1 in all tasks kept failing at computing.
He discovered why eventually.
The girls in the card typing pool were 'adding' in messages on the job cards for him, asking him out on dates, and these didn't compile. Devil's own job to locate these little 'notes' in a stack of punch cards a foot high.
I had the good fortune to be taught by Professor Brailsford in the late 1970s, and it is great to see his enthusiasm, knowledge and anecdotes still able to educate and motivate as it did me in his lectures all those years ago. Great to see the stack of punched cards - I still have my set from my first year Computing project - a Chess program written in Algol 68!
Professor B. neglected to mention the fact that back in the day, every program was written out longhand --- either on a form, or on a pad/in a notebook. We would "desk-check" what we wrote, and then we would sit down at the keypunch machine to enter our work line-by-line. It took a long time. There was a period in the 1960s when we had mark-sense cards for programming in Fortran, and I suppose other languages. You would use your special IBM Electrographic pencil (in retrospect, I'm surprised IBM product people didn't come up with one of their ridiculous names, such as the 9850 graphite depositing device!), and you'd have a specialized reader/punch produce your source deck.
Writing code was a lot of work. You had to write your code, go somewhere to punch it (don't forget you had to punch your data too !!!) , bundle it up, take it to a job entry station or put it in a box for someone to run it for you (assuming compile, link and go), then return later to retrieve your printed output from "your" box. Depending on where you were, you might have to wait as long as 24 hours for your output...and the output might simply consist of compiler messages telling you that you'd missed a comma, or that it tried to compile 5 lines of comments because you'd forgotten to put a C in column 1 (Fortran). Your commands to the compiler might have been wrong....or your code didn't work the way you thought it should... or maybe it worked....and you'd end up with a stack of fan-folded greenbar paper to pore over. Debugging code was an art and a science. We'd spend hours and hours going over our code, using nothing more than paper, pencil and mind to trace the execution of our work. We took a lot of pride in our ability to write clean code and to debug quickly. Each of us would have our own stash of handy routines and test programs to assist in the debugging and testing processes.
After we started using teletype text editors (some of the early ones were so bad, arcane and user-hostile, you'd wish for cards!), things became a little simpler. There were no "studios", or syntax checkers, etc. , but at least you could write your code, save it, compile it, and review the output without resorting to cards.
Such memories! It's much easier now.
80 characters per card.
So is this why still, in year 2013, for example Windows command prompt width is 80 characters by default?
I learned to program on an IBM 1401 computer in 1971, It had 16 K of memory, and no disk drive of any kind. It could output your results onto a printer, onto a tape, or onto new cards. No consoles or terminals, just a big panel with some big buttons on it.
Over the summer, the school system (yes, one computer for the entire school system of over 100,000 students) replaced the IBM with a Honeywell computer with 64 K of memory. We could not imagine what we would do with so much memory. Still no hard disks.
In the mid 1960's I punched FORTRAN cards for input to an IBM 360. Sometimes my stack of cards was several inches high. I'd draw on the top of the stack so I could watch them move down as the high speed card reader inhaled a three foot long rack of cards.
What a THRILL when my job caused the reader to pause for a second before the line printer started. It meant my job had actually run!
if XP were on punch card(~40,000,000 lines), supposing a .007 inch card thickness and being able to fit all of a line on a single card, the resulting stack would be 4.42 miles tall and weigh 145.5 tons!
11:12 - that trick of drawing a big V, or writing a word across the edges of the cards is also used all the time by woodworkers when they figure out in which order they want to join a stack of boards, but want to work on each individually for a bit, say to plane or sand each before final assembly.
I first learned to code around the 2008-2009 time frame (when I was 24 (!)), and I love learning about all this really old stuff. I never took computer science in school, my only experience was a class I took on a whim that taught VB6, and I really missed out.
Recently, I bought an old computer architecture textbook for a few dollars that takes you from all the way from how transistors work through the C language, and it's amazing.
I'm feeling a little old...I started as a IBM 370 mainframe operator in 1981. Computer cards and Hollerith code everywhere. Then we got a data entry system and the cards were gone (as far as programming and most data storage). Doing hex math in my head, pouring over dumps, then looking through card trays of data to find the bad punch that caused a data exception (usually from assuming character data was in packed format for calculations). Collators - patch panels, wow!
Isn't it amazing that nowadays a supercomputer to them can fit inside our pocket! And we just use it to watch cat videos and get into random arguments.
Remember this video next time you are about to curse your crashing program..imagine the pain of debugging with set of cards!
I used the beveled edge to mark cards that needed attention. I would sit at my desk and proof read a program deck. When I found an error I would turn that card around so that it's square edge would stick out of the deck's beveled edge. Therefore keeping my place and additionally marking the deck as not ready for production.
There are some pictures of the kinds of machines Professor Brailsford is talking about in the original Mainframes film - see the description for a link >Sean
It's amazing how UNIX is referred as the "next step" in the whole explanation. Thanks for sharing how punch card worked. I liked the method of drawing pen lines on the side in case they ever fell off. Those were the real hardcore days to be into IT.
@09:27 The corner cut could be in any of the four corners, and intermixed in any order, as long as the card's orientation when read was the same as when it was punched. If the card was punched backwards and upside down, then it would have to be read backwards and upside down to be interpreted correctly, but the equipment could not detect either the corner cut nor the printing.
We worked on a massive Finite Element Analysis program in the late 70s. The master copy was stored in cabinets of trays of punched cards that covered one wall of an office. The usual practice was to use a ruler and magic marker to draw a diagonal line across the edge of each deck. That way, if you dropped a tray, you had at least a fighting chance of getting them back in rough order before having to go through each card to get them into the proper order.
I remember having to read some cards due to an issue that occurred when I was in the military. Our unit was in support of 3D Infantry Division and their supporting units for JUMPS. This was the current pay system (1971). I showed one of the soldiers that worked with me how to use the three zones (0, 11, 12) to translate the punches. To verify what I was reading I had him to run the card through an interpolator which printed the characters on top of a duplicate card. I read the card that had no printing on top. The soldier verified what I wrote out to be exactly what was on the original card. I don't think I could do that today. I also had the opportunity to prepare cards for transmission on the IBM 026 AND 029. We called that "cutting" cards. Normally we would receive a box or decks of cards that had to have a start "Header" and end "EOF" card made. The start card had the routing, serial number, classification, card count. The end card had the same thing to verify the card count. The card count always included the body or deck number and the two additional routing cards. The end or EOF closed the transmission of the deck with four Ns (NNNN). If the Header and EOF card did not match in the card count when the transmission ended, I would have to answer a service message that was generated from the system and recheck the deck by running it through an off-line card counter. I can't remember loosening any cards or sending any decks to the wrong station during my tour. I can say that I really loved doing that job. Thanks for a trip down memory lane with this video.
Everything I just heard I knew already. From my first computer-operator job. And I am relieved to learn that I did not exaggerate one bit all these years.
this takes me back - thanks! - old ibm mainframer here - one could multi punch any of the 256 byte combinations using an 026 keypunch - these values might employ more than 2 holes - also if you dropped a deck, in addition to the methods you mentioned, you could compare to any listing you might/should possess - a dropped deck is rarely completely random - blocks of cards tend to clump together - i think our last card conversion was 1980ish - thanks again!
I used to play with these as a child circa 1983 in Russia :) They were very much used in the State Statistics Office where my mother worked.
While using it a lot, it is easy to take the humble "return" for granted, when getting information from one place to another. To have the output physically handed to you on a deck of cards and then having to manually having to insert them to deliver the output to where it's needed, now that is something I am glad we left in the past.
Sorry "return", I'll never take you or your automatic delivery for granted again. We young people have it so easy today because of you.
@08:41 I am pretty sure that the mechanism for moving the cards on the IBM keypunches was by friction wheels, like what is used on most (all?) of the consumer printers today for paper movement
Back in the 70s, I used to maintain punch card equipment. As I recall, the official name for the device was "Interpreting Data Recorder". Also, way back in my grade 12 FORTRAN class, we used pencil mark cards. These were the same size and shape as a punch card and could even be read on some card readers. The 12 hole column was split into 2 6 mark columns, staggered so that the mark in one column was next to an unused area in the other.
Incidentally, punch cards are why so many terminals and printers have 80 columns.
There was a begin and end card, a run program card and 1 card with 54 numbers whose position and value specified the location of each of 6 colors on the cube. The line printer would then print out a sequence of turns that needed to be made to your unsolved cube in order to solve it. I received an A+ on that project.
this is so cool that there are ppl that can tell u and explain the history of machines we are using today:) i love this channel and hope to see more guests with such great knowledge
I worked for the CEGB in the 1960's and spent many a happy hour loading trolley loads of cards into the reader connected to an IBM1401. We transferred all the jobs for the day onto magtape, to be run overnight on an IBM 7094 running the IBSYS operating system. The IBM7094 had 12 tape units and a giant DRUM. When a batch finished the tape units would go into high speed rewind mode - what a site - just wished I had taken a video of it.
It is a shame the video does not show a hand-punch, because if you were desperate for a job, which had failed and you knew which card was wrong, you could hand-punch a new card.
I still have a few cards in my desk drawer -for nostalgia's sake.
If I remember correctly ICL could also read smaller cards - about half the width and less tall.
I'd love to hear some horror stories about punch paper tape problems. Later we had an IBM punch-paper tape device that continually clogged up - IBM was cards - not paper tape.
Later as an assembler language programmer on Honeywell 200 series - when a job failed - and you worked out what the problem was - you went to a hand-punch and created a patch deck that was added to the end of the program - all done in octel.
Happy days and thanks for the memories
It was a good idea to always use sequence numbers in your cards. For IBM 360 Assembler the sequence number was in columns 73 to 80. You could tell the assembler program to verify that the source deck was in sequence. Column 72 was used to continue the card onto the next card - this was commonly used for 'macros' such as the DTF or DCB declarations. At the place where I learned programming, via OJT (On the Job Training), we had several IBM card sorting machines which were invaluable in the event of having dropped a deck of cards.
All serious programmers should know an Assembly language. That way you have a much better understanding of what is actually being done by the hardware. Even in 'C' it is possible to write your code to take advantage of the quirks of both the compiler and the hardware. Of course it IS possible that what is best for one system is not the best for another.
Some columns did have more than 2 holes per column, number used a single hole, letters and three special character used 2 holes. All the other special characters had 3 holes. There were also binary decks that could have any number of holes punched per column depending on the instructions or data. On our old Honeywell mainframe we had a complete binary program stored on a single card that played a simple gambling game. It had many holes per column. You can see 3 holes in column 1 in this video at 8:17
My first job in computing began in 1971, working on an IBM 360/44. One of our card punch machines did not print on the cards at the top. I became adept at reading the holes.
I used punch cards and we had little silver stickers to cover up holes when we made a mistake. Also special characters used 3 holes per column. The electric punch card machines were in great demand so programmers were often forced to use manual ones with a key for each possible hole in a column.
This is great. I am old enough to actually have worked with those cards and related systems. Long before machines could read human writing (scribbles, sometimes) I used to be employed as an alphanumerical datatypist. The machines hummed, all kinds of levers and mechanical things in working. Splendid. Thank you for this movie!
My father used to work with these things many years ago: when I was growing up, there were great stacks of old punch cards in the house that he had brought home (presumably discarded from use), and he would explain to me (approximately) how they used to work. They were already obsolete when I was a child, and I am 36 now!
If you use two different colors and draw an X then it gets really easy to sort them faster because you can easily identify which cards belong in the first half, and which are in the 2nd half.
When you have a thousand or more cards little things like this trick make a big difference.
In some shops, programmers would not even punch cards themselves. The programmer would write his program on a "coding form", which came in a notpad, each form sheet having 24 lines of 80 columns gridded out, plus some heading fields for identifying the programmer, department, etc. The programmer wrote his code in blocked letters, one letter per column, one line of code per row on to the form, according to the format of his chosen language. After appropriate desk-checking to make sure the code was seemingly correct, the coding forms would be submitted to a punched-card operator (a typist skilled in the use of the punch card machine). After the program was punched up, the programmer could swing by later and pick up his deck of cards, with the original coding forms for corrections if needed. Once the programmer was satisfied, he would submit his deck to the computer operator with some additional job control cards (as shown in the video). The computer operator would run job decks in order of submission, returning decks and associate line printer output back to the programmer. Whew! The turnaround on logic errors was brutal, often 24 hours or more to make any correction, which is why visual inspection of the original coding form was so important.
The old IBM systems (pre-360) was a computer with a whole series of peripherals: a collator, a sorter, card reader and punch, and a printer. Many functions could be performed directly on the peripherals with only minimal control by the computer. The machine that sorted your cards into order was the sorter; the collator did computations on the column data based on "programming" a hard-wired panel.
The keypunches moved the cards mechanically. Some card readers used compressed air to pull cards off the deck quickly; the slot they had to go through was precision set to allow only one card through, and the compressed air kept a warped card from stopping the process.
My first FORTRAN course at university used punch cards and the typewriter ribbon was hardly ever changed so you couldn't read the line on the card. We learned to draw diagonal lines on the card stack very early on and we'd write numbers on the card as the reader would jam all to often. This was the early eighties and as undergraduates we could only use the old out of date computers.
Wow, best explanation of punched cards computing i've seen anywhere.
for me as a developer thats like listening to a bedtime story ;) love it! It was really complicated back then, I am glad we have editors and real files nowadays.
As a Business Major in HS I took Keypunch and Collator Classes. When I got into the Marines I ended up applying everything I learned in HS. Interesting work.
I always enjoy your videos on the history of computer technology and programming. My professors would mention the days of punch cards and I always wonder how they worked on a high level. Thanks so much for making this video!
When I was a kid they used to give these cards to the public school. I still remember how much fun it was to build cars, houses out of these cards. Very pre-minecraft
You stated 80 column and the video stated 80 column cards. Professor Brailsford discussed a 6 bit computer in the video and stated it was done to make it cheaper to make. So,you're correcting me on things not discussed in the video. The 6 bit 80 column cards are 480 bits. The ones I used were 8 bit, but that wasn't what was being discussed.
I used punch cards until I graduated from college in 1979. When I was a child, they were everywhere. Now no one remembers what they are/were.
Christ. Programmers these days have it easy.
My father worked in bank data processing until 1980, and they used these. My mother was a keypunch operator.
Cool video! I remember my mom telling me about the old FORTRAN 77 days of punching cards. I tell her that the 2008 standard isn't much better. There's still a default fixed-form limit of 72 characters per line, and we still refer to things as "cards" and "decks" despite everything being stored in electronic form.
(continued) Once storage got larger, the operating system stayed in the machine between jobs, but you would still have to load the compiler. Early compilers were "multi-pass," where the computer punched a deck of "intermediate code" because the whole compiler was too big to fit in the computer, so it was split up into "passes."
I remember going out with a girl who was a programmer. Most people were using Monitors to input into for computers by then but some of her programming was still done by punch card so always had rubber bands on her wrists. My Dad while he was programming always had punchcards at home, think he was checking them, I was very young. He ended up running the department,Employment as programming was nwever decided on your Academic qualifications(although he had degrree). If you got an A or better on the IBM aptitude test you were if you interviewed well you were employed.Most had A+ scores.
just 50 years ago ... we have come a long way
There were "keypunches" with typewriter keyboards (there were typewriters, too), and there were "cardpunches" that were automated and punched cards at amazing rates. Still, at 80 characters a card, an "amazing rate" was still low bandwidth. Tapes were the way to go for speed. "Never underestimate the bandwidth of a station wagon full of tapes driving down the interstate."
Heard about punch cards for a long time but never cared to find out about them. Today I saw them for the first time. I can imagine how much some old people miss that era, the same way I miss my floppy days. I guess their days were more exciting.
The David Attenborough of computer science.
I was a 1401 programmer 1962-1966. And I still have a couple of my old programs as a punched card decks from the year 1963.
When I started ('80) you wrote programs on paper forms and passed them to a typist to punch the cards. They were numbered but also had a diagonal line. Corrections were hand punched. You then handed it in at the operator window and dropped by to see if your results were there from time to time. We still had a paper tape reader :D
Back in college I asked my professor if I could combine the class projects into 1 larger project. I wrote a Fortran program to solve Rubik's Cube. It was appx. 1500 punch cards and would take so long to load and run the computer lab was tied up for nearly an hour just on my program. This was such a problem I was given permission to store my program subroutines as they were debugged onto magnetic tape so I wouldn't have to load the cards each time. When finished, t only took 4 cards to run.
When I started at my second workplace in 1990 they'd only recently migrated from an ICL 2900 series mainframe to a S39L65 dual node. We had a little ante-room called data prep where there were card punch and card reader workstations, but they had just moved away to rudimentary VDU input directly into wired terminals. So, I never quite managed to witness the world of punched cards in production UK public sector life, but I feel that I was fairly near the start of the VDU era and use of VME rather than TME. There was still a lot of mainframe mentality as much as technology; we would carve up the day into Transaction Processing (TP) and Batch times, with pretty hard immutable rules for what was and wasn't allowed in each window.
My father worked for Defense Computational Resources Working Group, and dealt with writing programs on punchcards. He had developed an optical auto punch card system and had special cards printed up for it. Those cards would have little boxes over the punch area. So you'd must mark it just like those old scantron tests. Then you'd feed it into the keypunch machine and it would automatically detect the mark areas and punch them. This was in contrast to doing it manually on a keyboard like he said. Ok. Then he had a system of transparencies with commonly used snippets of code written out, and an overlay pattern to trace at the bottom of it. He'd put that on a glass table and put the punch card on top of it so he could mark down the spots that were blacked out underneath. So it was a primitive way of using programming libraries, heh. He said he got the idea from a story he heard about Bletchley park where they would use transparencies to help identify numerical patterns in codebreaking. Later on when xerography (that's photocopying) came out, he'd just put the transparencies into the photocopier and then trim down what it spit out and fed them into the optical-punch machine. There were some other cool innovations, such as optical tape for feeding the patterned program data that way. That was just a flim negative with the optical "punch" patterns exposed on it. That of course needed a highly modified reader, but he said the system worked well. The system used for "recording" the data onto the microfilm was real low frills he said, and consisted of a Minox camera. He said he managed to get about 2k info of information onto an exposure of 8x11mm film, a roll of which held 50 exposures (and was dirt cheap).
In 1973 I dropped a whole box of punch cards containing the complete accounting "database" for the organization I worked for. For a few moments there was complete silence in the room till people, including myself, recovered from the shock.
Luckily for me, 2 things were in my favour...
1. There were still large blocks of cards still in order on the floor reducing the effort required to place them in sequence.
2. All the cards had sequence numbers in the last few columns so I could verify they were in the correct order.
Unfortunately we did not own a card sorter so I had to spend the next few hours putting the deck back into the correct order. The deck was then read into the mainframe's card-reader and the contents printed out so I could visually verify the cards were in sequence. Luckily the cost of the computer time was not taken out of my pay.
I never dropped a card deck again after that.
I started programming in BASIC back in the mid 1970's and later wrote some programs in FORTRAN using punch cards. I could type faster on one of the IBM keypunch machines I had access to than I could on an actual typewriter of the day. It was something about the height of the chair, the height of the keyboard on the punch card machine, and the amount of force needed on the keys of the keyboard.
I still remember the basic idea on how to read a punch card from the holes in it. I was able to read a few characters off the cards shown before the text was shown at the top of the card. I may still have something that has the details about the characters for each pair of holes in a punch card. I have a couple of programs in a box that are on punch cards, I have a manual for an old IBM keypunch machine in a box somewhere, and I even have the control drum for one of the old IBM keypunch machines. Ah, what memories it brings back thinking of these things.
Kids these days don't know how good they have it. I just barely missed the card punch era, but my professors were always on me not to let the compiler find the bugs in the program, because when they went through school they were charged for their jobs whether they actually compiled or not.
I do remember having to type the bootstrap sequence into an ancient DEC machine (PDP 11/03 I think) at RPI for an assembly language class, in order to boot our 8" floppy. Ah, the good ol' days...
"There is no quicker way to discover what n! means" haha love it!
Thanks for posting this! It's really cool to see where the modern program languages got their semantics!
I'm watching this on a smartphone. The progress is constantly blowing my mind.
Wow, I can't imagine the hairpulling errors that must happen when those cards get mechanically punched incorrectly.
It's easy to forget when I write code these days that I don't need to worry about my code not getting mechanically read.
Spuds7er - Yes, I'm amazed that I have any hair left at all; both for the reason you state, and also given that I've been around long enough to have been exposed to that hazard !
Woah, such a blast from the past. Great history lesson - and to think that it all happened barely 40 years ago!
I know the 029 punches I used to use didn't print anything, it just punched holes. You had to number them by hand to protect against mixing them up. There was one 029 that did print what was on the card but you had to have an act of congress to be able to use it.
Two major funnies stick out in my mind regarding punch cards, one at the beginning of my career in the late 1970s, one towards the tail end in the 2010s:
> Early Career: Straight out of college, I was working at a company developing a new payment tracking system on a Data General "mini-computer". My predecessor was an old mainframe guy, and, as the professor notes, would carefully update his program deck (COBOL), then read in the cards (close to 2,000 cards, if memory serves), compile the program, get his error report, then update the deck and start the process of re-loading the card deck into the computer and compiling again. Very time consuming! I was the hot-shot new kid, who was not only used to mini-computers, but also was quite versant in online text editing.
The day after my predecessor left for a new job within the company, I loaded his card deck into the system one last time. I then, in full view of my manager, proceeded to take the box of cards and dump them into the trash bin. Needless to say, I got a horrified look from my manager, but I assured her that any and all corrections could now be done directly using the text editor. Much faster, and a lot less error prone. Of course, I hit my deadlines, so she couldn't complain. Of course, that was not the last of my hot-shot stunts that I pulled on the project. Luckily for me, all of my stunts paid off, and we went live on time.
> Late Career: I was working at a large bank that had brought on a lot of young programmer from India to work on the development and support of our systems. One day, I casually mentioned my use of punch cards back when I was their age. To prove the point, I brought to work the next day some sample cards I had lying around my house (they make great bookmarks, by the way). Seeing their amazement and confusion over the cards was a lot of fun. I was only too happy to give them a few lessons in computer programming history, something that they never got in school!
I did computer studies ‘O’ level in 1982 in the tech’ night class and the (hands strictly off) mini computer read punched cards. I searched the house recently and didn’t have a single card left. Used cards didn’t really have any secondary re-use, the holes ruined writing on them.
The tech’s ‘mini’ computer was fairly ancient back then and took the best part of an hour to manually reset after a crash. It was the size of a cupboard.
HAH, I still have a stack of about 1000 of these punch cards my grandfather brought home from work he used on his MAZACK (sp?) CNC machine for Kyle/Cooper/EATON Power Systems.
I remember the Keypunch machines back in the 70's and 80's!
Actually had not just the card drop experience way back then... but turned a corner too quickly with my stack and ran head-on into another student with his card stack. Oh what joy that created :-)
Until the late 70's every bill had a punched card in it with the iconic words "Do not bend, fold, spindle or mutilate" on it. If you were late on your bills you could swap two different cards and claim you made a mistake. You still had to pay the overdue bill next month, but if you were lucky you didn't have to pay a penalty. My mother did data entry on a punch machine 8 hours a day for about 7 years. She said it was the most relaxing job she ever had.
Thanks, I love this guy. I recall using punch cards in the 1970s when I was in public school as well.
This video makes me feel old.
Brady, you should make a playlist just of this fellow. The other presenters are great, of course, but this guy really does hail from a time when computers were maintained by a sort of techno-priesthood and programmers, users and operators had to approach them in a much different way.
I used punch cards in college - we were the last year to do so in that school - it was 1982 at Norwalk State Technical College in Norwalk, Connecticut. I don't miss them, but I'm sure I still have boxes of them in my mother's attic.
I had stacks of these as a kid, used them to make all kinds of things. My dad was a COBOL and Databus programmer starting in the mid 60's.
"No best way to learn what N! is" love it.
Okay. When we ran punch cards using Fortran, we were taught to number our cards, either by writing on them or by adding a printed comment in the code. If you had to add an extra card in the middle, you'd just use a decimal point. Simple, but easy enough to straighten out "n!" accidents. circa 1978.
Looks like this code was an early use of the NAG library. E01AAA - An interpolation function From the NAG mathematical library. This library is still widely used, but was originally released for ICL machines in about 1970.
Card sorters :-) ... & binary puchings
Back in my starving student days,
I'd dive into the card recycling bins, pull out bunches of cards, and run them repeatedly through the card sorter - one could only sort by a single column at a time. By repeatedly sorting, I could sort down until I sorted out down to all the cards that had the first - or last - 40 columns all blank. I'd then save those cards and return the rest to the recycling bins. I'd then use, as one of the first control cards in my program, a card which effectively said to only read the first 40 columns, and ignore the rest. Thus I managed to avoid the cost of ever needing to buy blank punched cards - which were sold for $0.25 USD per 100. A small percentage of those cards found were also completely unpunched - that was enough to cover the few lead (and possibly also end) cards I needed before the control card that limited the significant reading to the first 40 columns. And all these >= 40 blank column cards, I not only used for the punch card programming, but those >= half unpunched cards I also used effectively as "index" cards for the paper writings and the like, where I first needed to do outlines, and often sort and rearrange various bits before working into a draft and final paper.
Binary punchings - though not so commonly done, the cards could be punched in a true binary form - typically done by computer card punch, not a keypunch station. That would give significantly greater data density on the cards - but also a structurally much weaker card, as on average half of all the holes would be punched. I even made some cards with all the holes punched - quite flimsy - and yes, they could be read, but unlikely they could be handled much and repeatedly read very successfully before suffering mechanical damage and jamming or tearing.
Thanks great video, learnt a lot. wish I had been there in the early days, thankfully I got in at the 8bit stage. But to get in to computers today must be a lot harder to get your head around than in them early days. I remember building my first logic state computer and it taught me so much on how to grasp the workings of what a computer is/does etc.
My dad used to bring these cards home for us to play with. He also used to bring home the peaces of punched out card.
I was an IBM CE starting in the mid sixties. Repairing 024, 026, 029, 056, 059, 080, 082, 083, 084, 557, 088, 1401, 1402, 1403, 360 and related peripheals(tape drives, disc drives, 1403n1, selectric I/o etc.) Was trained by IBM while in the MARINE CORPS and served two tours in vietnam repairing the aformentioned equiptment. Continued in this occupation for many years as a civilian.
When I first began in the computer field, there was a keypunch machine & a keyverify machine.
Before that, I used a teletype machine where I learned FORTRAN programming...
We've definitely come a long way!
When I was in college there was an outside computer company that ran both cards and remote terminals. A friend wrote a program for it that ignored end cards and continue to run in the background, passing along the jobs but storing ID and password data that he would collect later. The only problem was that a batch would read as soon as it was placed in the hopper. The operators soon complained, but he got enough "free" account time to last his last 2 years, and nobody guessed what he was doing.
I am old enough to have used the punch card machine to punch my programs in FORTRAN (or was it COBOL?) back in the 90's when it was going out of style...
I used to draw a diagonal line with a felt marker...
The stack of cards were placed in a hopper that would pull from the bottom of the stack. If the stack was over a few hundred cards the friction of the bottom card against the hopper would prevent the feed rollers from overcoming the friction and cards would get jammed. If a card was sufficiently damaged you'd have to go back to your hand written source code, print a new card and reload the entire program again. One person's job was to feed the hopper with the ideal amount of cards.
I remember my first CS class in 1975. We punched our little program onto cards and the "Perfessur" gave us each a few cards to put in front of each one. These were IBM JCL cards to run the jobs at the computer center. Fun times.
I remember a field trip to the phone company when I was in 4th grade in 1961 or so, and their office had a card computer for customer service and billing information. The switch rooms had floors of relays that connected the calls too...a different era indeed...
In early 90's I was playing with such cards - original from 70's. I used them to color numbers and generally draw on them. I don't have any card left. If I'd know their value back then... Well, even if they are now valuable, I'd love to have it on the wall and of course give most of them to local IT museum. It hurts they ended up in the trash bin.
Soooooo many people needs to hear that.
Yes, many "special characters" were three punches. The IBM 3x0 series used EBCDIC instead of ASCII, and the EBCDIC table used to show the card column combos for each 8-bit EBCDIC character.
The size of the original "Hollerith" card came from the size of the US dollar bill at the time. Herman Hollerith had visited the US Treasury and noticed that they had equipment that could handle that form factor. The professor mentions a "collator". Actually it was a card "sorter" that could sort a deck of cards back into order, but you had to run them through multiple passes on successive columns and re-gather them after each pass. Google IBM 082 sorter. (ID SEQ was in cols 73-80)
My first paper was done on punch cards, back in 1984. Switch to Unix machines at the end of that year, and VT100 terminals