I did fail to explain that. It worked two ways.

For example, if it was a 1-shot deal, say I wanted to print out a statistical analysis of xray diffraction data (an actual project I remember), I wwould code up the program, get a bunch of data cards from the diffractometer and append it to the back of the deck, wrap some JCL around it, and take it down to the computer center and drop it in the inbox.

The job would compile, link, execute, and write the results to the printer. I re-ran the job over and over until it was working the way I wanted it to, making changes in it as needed. This is what my student work was like. In the next installment, which I will post soon, I was working at an oil company. Here’s how the batch concept works in a production environment with dumb terminals.

Suppose the guy I was working for said he really liked the program, but he wanted to run it himself, pointing it to different input datasets, and he wanted the ability to change run-time parameters and have the choice of directing the output reports to an accessible file, a printer in another building, or to a tape, and he wanted to be able to do other things, like delaying the run til late at night when system usage was light, or send the results to his office terminal.

I would take his specs and modify the program, making the I/O statements generic, (read or write to file 1, file 2, file 3, etc). JCL cards could then be added when the job was submitted so each identified file 1 as the printer in bldg 6, file 2 is the tape drive y in the computer center, etc. When the program tried to write to file 2, the operating system would send a message to the night operator’s terminal that job x was requesting a tape mount on drive y, and he would hang it for you. Next day, your tape, printouts, etc would be delivered to your mailbox.

You could also have the data on files in the computer itself, so you didn’t have to actually type up cards yourself. For example, some wellog data could come in on telephone lines and be stored in a memory location on the mainframe’s disk drives. You could add a JCL card to your program identifying the location of the data as say, file 77, which is the generic name you had called that file in your program. THe operating system would say program z needs the data at memory location w for his input statement reading file 77.

THe program itself could be compiled and linked and stored on computer memory, so you could simply give the user some JCL cards saying which program to execute, and where its input and output destinations were.

The programs would usually do the same thing, but you had control over many parameters, which were entered in as control cards, so you could select options like “which averaging method to use” or “what filter size”. A typical job would consist of JCL cards identifyin I/O devices and file names and connecting them to generic read and write statement numbers in the FORTRAN program, followed by control cards giving the program parameters and options, and a JCL card identifying where on the computer the assembler code for your linked code was
residing.

Those JCL cards could also be virtual, existing on a file themselves, and editable from a terminal, this was called a Catalogued Procedure, and it migh have multiple programs passing data back and forth to each other, reading and writing files to multiple devices. THis is how most people actually did their jobs, exevuting on-line catalogued procedures, making changes in control cards to customize the jobs for their own problem or task.

As a programmer, much of my work was maintaining catalogued procedures, not only correcting or enhancing the FORTRAN at the heart of it, but also giving the program access to different files, devices and so on. For example, every time a new map plotter was purchased and installed, I had to modify all my catalogued procedures so my users could direct their maps to it.