[todd8]

I started programming around 1967-1968. In my high school, there was an old keypunch machine used for school administration purposes. I had a friend that was able to submit any program I keypunched to the school district's IBM computer; I never saw the computer but it's likely that it was something like an IBM 1130. My my friend would bring the output back a couple of days later; so fixing even one typo required a few days.

This old keypunch machine was a model 026, not the much nicer model 029 that was ubiquitous while I was in college. The 026 had a very basic keyboard, see [1], one could punch the columnar code for the upper case letters and numerals along with a handful of symbols: #@,%$./ and space. This isn't enough to even program in early FORTRAN, the language I was trying to use.

To type say an equals sign one had to use the multi-punch key that allowed punching a combination of the basic symbols that would properly encode the equals sign. It was slow going. One mistake and the card (corresponding to a line of code) was ruined and had to be redone.

I had just finished reading a book on solving linear programming problems, which come up often in operations research, using the simplex algorithm (I still have this book too). Naturally, I decided that that would be the first program I ever wrote. That definitely wasn't the best "hello world" program to try first. I wish I still had a listing of that program; it would be good for a few laughs.

The first working program I wrote printed out a table of sine and cosine values for angles from 0 to 90 degrees. The rest of my programs in high school were not much more sophisticated. I was just trying to learn it on my own as a hobby. I still own my book on Fortran that I bought with my newspaper route income back then, McCracken's book on Fortran IV [2].

A couple of years later I got to write more serious programs and used the IBM 029 keypunch machines that were a lot better. Programs got long enough (hundreds of lines!!) that card management became important. Sturdy cardboard boxes or even long metal drawers designed for holding the stacks of cards were the main tool for source code management.

In college, I was able to use IBM's data processing equipment for punching line numbers in columns 73-80 on each card (these columns are ignored by FORTRAN IV); this allowed dropped cards to be sorted back into order through a series of passes (one for each digit of line number) on IBM card sorting machines. This was my introduction to radix sorting, [3].

One complication when numbering cards was inserted new code between existing cards. Because of this, my initial punching of line numbers in columns 73-80 had to be done with gaps, usually I'd leave one or two zeros at the end of each card number. However, to get the auto numbering machine to do this required pulling out a large (1 foot square) plug board from the equipment and physically connecting jacks with switchboard like cables to make the equipment count by hundreds and punch in columns 73 through 80.

It was all quite primitive. But one did learn to review code carefully before submitting it for being run.

Grad school was better, I still frequently used FORTRAN punched on cards, but I was also able to use the mainframe in a timesharing environment where I used TECO as my text editor at a terminal, there must have been around twenty of these terminals connected to the CDC 6400, [4].

[1] http://www.columbia.edu/cu/computinghistory/026-keyboard.jpg

[2] https://archive.org/details/guidetofortraniv00mccr

[3] https://ibm-1401.info/KensSorter/type83-a.jpg

[4] http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/kronos/60407...

[commandersaki]

When you program FORTRAN with punch cards, does the computer run the program and provide the output, or is there an intermediate step of having the compiled executable output which you then need to feed back into the computer?

[dboreham]

Note, I never actually used punch cards, but they existed when I was in college. The user interface was like this:

1. You prepared you cards, offline using a punch machine.

2. You got a form from the computer center and filled it in with various details for your job.

3. You wrapped the form around your card deck, secured with a rubber band and placed the assembled package into a box/shelf in the entrance to said computer center.

4. You went about your business for a day or so.

5. You checked your pigeon hole outside the computer center, or perhaps your department mailbox.

6. Eventually your card deck would show up there, accompanied by a line printer (fanfold) output that was whatever your program printed when run.

There were more complex workflows allowing things like tape input/output where you'd specify the tape label either on the form or in the deck.

This is where "Job control language" (JCL) comes from -- a scripting language to facilitate running batch jobs. The precursor to Dockerfiles and Github Actions YAML.

[euroderf]

IBM JCL was where the truly magical incantations entered the picture. We had grad students who hung out in the punch card room and they were the go-to guys for getting your JCL sorted out. SYSIN DD *, baby!

[fghorow]

Back in the Usenet days, I saw some greybeard's .sig line:

\\GO.SYSIN DD *

DOO DAH

DOO DAH

(Checks beard color and blushes.)

[rnk]

I used to know some jcl, those were the days. It was used in a few "advanced" classes when I was an undergrad. Was that the one that had the little hello pamplet with details, or was that yellow pamplet describing sys/360 assembly.

[ansible]

I've also never used punch cards, but I had seen the equipment in the computer lab at university.

One more trick for the young ones here that I've heard is: With your completed stack of punch cards, take a marker and make a diagonal slash across the edge of the stack from top to bottom. That way, if you accidentally dropped the deck of cards, you could put them back in at least the approximately correct order very quickly. You would still want to look through the cards one at a time to ensure the order, but the process goes much quicker if the deck is nearly sorted.

I mostly used serial terminals connected to minicomputers like various PDP-11s and Dual VAX 11/780s. I did get to experience the joy of trying to complete an introductory CS assignment near the deadline. The machine slowed to a crawl, but didn't crash. You would type in one character, and wait for it to appear. We were warned to submit our assignments early!

[todd8]

I'm sure it was possible to punch the compiled executable as an option, but I was a student during most of my keypunching days so the cards would be read by a card reader the computer would compile the FORTRAN and then execute the program, reading input data from cards that were stacked behind the source code.

One summer, I worked at an engineering firm and had to run a program frequently on a set of input; it's possible that the executable I was loading into the card reader was already compiled and not the original FORTRAN source, but I don't remember for sure.

[whartung]

Typically, at my school, the decks were standalone. They included the program, the data, and any control cards (like actual commands).

For a COBOL class, your deck was the commands to compile and execute the program text that followed, and then that program operated on the data cards that followed the program cards.

Then, your output would likely be the compilation listing, followed by whatever output your program created.

Mind, this was school, and these were student programs. And while you could wrap up your deck and drop if off at the computer center to be run, it was likely better to take it to the lab to that had the RJE (Remote Job Entry) terminal which had a card reader and a line printer.

Jon’s submitted there would print out on the line printer, but the printer could be used by others as well, so there was typically a queue of printouts that you had to wait for. But in general, the RJE lab had the fastest turnaround.

I remember my friend playing Lunar Lander. He had the Fortran source code, and would add a new burn card, and run the deck through. He’d go over the output, add another card, and run it again. This was the process, but not necessarily an efficient use of paper.

Now, there were also folks that were not programmers, but rather students and professors using tools like SPSS (a statistical package).

A student assignment deck was typically 1-2 inches thick. Not much code, not much data. But these researchers, they had decks measured in feet. They’d carry them around using small carts and hand trucks. The cards were in cardboard trays. Most of that was data. Largest set I saw was probably 10 feet long of cards.

They took their sweet time being run through the feeder. Just grab a chunk, and put it in. As it fed, pile on some more. No rush, it’s an input device, it’ll wait for more cards as you moved the read cards out and fed more in. But it was an endeavor.

[bregma]

Generally, you'd have a deck of cards consisting of JCL, FORTRAN, and data. Your first cards were usually something like $ACCOUNT (for billing) and $JOB (for identification), the program code, then //DATA and the data. You would submit this deck through a card reader using RJE (Remote Job Entry) to either a HSJS or a GPJS (high-speed or general-purpose job streams respectively, depending on your account) on the one computer shared by the entire campus where they were batch-processed and the results sent to a high-speed line printer near your card reader. On good days this would take seconds. On the morning a first-year assignment was due there would be a lag of hours.

There was no 'compiled executable'. There was 64k of core memory and no disk for HSJS jobs. There was just you desk of cards and the resulting printout and everything else was ephemeral.

[cardiffspaceman]

There were “student job” compilers that ran the program from the cards and printed the output. I don’t know how the machine and compiler did this. Probably by compiling to memory and executing said memory.

[KWxIUElW8Xt0tD9]

At the University of Maryland in the late 70s we put the FORTRAN program on punched cards and wrapped some sort of batch language around it all to compile and run it -- as I recall -- has been a long time -- then output was on fan-fold paper that the operators provided back -- UNIVAC 1100 series -- also as I recall. When I discovered ASR 33 dialin terminals it was heaven in comparison.

[Taniwha]

Depends on the system, for many it was possible, more often you could leave a binary on disk (or tape)

[denton-scratch]

> But one did learn to review code carefully before submitting it for being run.

My first experience of coding was COBOL. I was expected to use a pencil and a coding sheet; my efforts were then reviewed by a human, before I was allowed to submit it to a compiler.

[nwellinghoff]

Amazing they didn’t just leave a space on the card for a jump operation of some sort. When you want to add something to your program or fix an error you just use the space to say “jump this many forward” and resume. I guess there is a good reason something like this was not possible?

[spiralx]

Probably not possible because it wasn't thought of when the system was first implemented and introducing such a change would involve getting new hardware with the jump feature and quite probably new hardware both to read the new card format and to produce the cards themselves. And everyone else also having to do so given the dominance of the IBM 12/80 card format.