You might be pleased to hear Fred Brooks apologised for JCL in 2015:[1]
> If we had been smart, we would also have done a schedule-time mode of PL/I instead of doing JCL, the Job Control Language. But we weren’t smart. The worst mistake we made was JCL. Its existence was a mistake. Building it on a card format was a mistake. Building it on assembly language was a mistake. Thinking of it as only six little control cards instead of a language was a mistake, because it had no proper subroutine facilities, no proper branching facilities. That we did not see it as a language was the fundamental problem; we saw it as a set of control cards.
Once at the Watson lab I rode in the elevator with Brooks and nearly kissed his ring for his The Mythical Man-Month but was nice enough not to mention JCL!
It was the interface for users essentially all of whom were programmers since there was essentially no on-line access then.
Calling JCL a scripting language is one heck of an insult to Rexx, etc. When Cowlishaw's Rexx became available right, away it swept IBM, e.g., ran the service machines that ran VNET, IBM's early thing to do internally for IBM what the Internet later did for the world.
Rexx could have run on MVS, etc. -- some people at Watson wanted that, but I doubt if it ever did.
I wrote a lot of JCL for MVT on the 360/91 and later on other 360 boxes, and I never saw anything like environment variables.
The horror was the DCB statements: They were to fill in control blocks needed in assembler to do I/O; if didn't understand those assembler control blocks, then DCB statements didn't make a lot of sense.
Perhaps I should clarify that I was referring to OS/MVS JCL. MVT was before my time. By "environment variables" I meant the ability to tie a logical device name (at the program level) to a physical device (or instance thereof, like a particular generation of a tape volume), like how environment variables link a logical name to a value.
I used to do all the JCL for my project group. Having come from being an operator first, I knew how to set up the JCL exactly how I wanted (including comments for instructions to / clarifications for operators and job control center staff) and syntax-test it. Meanwhile, the other groups stumbled through either hand-keypunching or laboriously filling out keypunch sheets. Many didn't even know we had a JES2 spooled card punch available before I came in.
The worst pain in the back side for me with JCL was that the job turnaround time was about 4 hours. So, miss one comma in JCL, and KaPOOF lose 4 hours of work.
I had two solutions:
(1) Walk my deck of cards to a card/printer remote terminal (about 300 yards away from my office) and have it print my card deck, then back at my office stare closely character by character by character at the printout.
(2) When a job did run, rush to copy the crucial JCL cards and KEEP them as something that WORKED.
In those days, the job control card struggles were not just for MVT or MVS but more general. At one meeting of users, a guy stood and said that he wanted the control cards that worked laminated in plastic with a hole in a corner and hung on a chain!!!
My later encounters with the IBM mainframes were via 3270 terminals, VM, Rexx, and with nearly no use of JCL. And in those days I was becoming a happy as a clam Prime customer. Did some good things with some Prime computers.
Then it was on to PC/DOS, OS/2, and Windows 9X, 2000, XP, 7, 10, .NET, SQL Server, the .NET version of Visual Basic (as far as I can tell, just a better flavor of syntactic sugar than C# -- I hate the idosyncratic syntax of C/C# -- wrote it? Yes. Like it, NO!), and soon Windows Server.
Here in the Mid Hudson Valley, IBM is running ads for people who know CICS to rejoin!!
Long turnaround is a property of batch not of JCL. While it was not pretty neither was the control deck for the CDC 3500 or the CDC 6400 and likely Burroughs big iron of the time.
But it sounds like you have a lot of issues with how a lot of the computer languages work.
"Issues"? Not really: As in Kernighan and Ritchie, C has "idiosyncratic syntax". To me the full generality of the type statement is unreadable; the book even has some code to show how to parse it. Also there is the notorious
i = ++j+++++k++
which is legal but on two compilers I tried it on got different answers.
To me idiosyncratic syntax is not a proof of worth or a trial by fire for admittance to the inner sanctum but just something more difficult to teach, learn, read, write, and debug than necessary.
C was designed at Bell AFTER IBM had PL/I running, and PL/I makes C look like kindergarten drool: Right off PL/I beats C in
(1) Scope of Names. What C has is a toy;
what PL/I has is powerful.
(2) Arrays. C doesn't really have any and asked the programmer to write pointer arithmetic using the usual array addressing arithmetic. PL/I has real arrays, and the compiler can pull constant expressions out of loops, optimize register usage, and otherwise have freedom to do things that the programmer can't see so that don't have to provide guarantees to the programmer.
(3) Strings. C doesn't really have any; the idea of ending a string with a null is the cause of too many buffer overflows. Each operation on a string is an external subroutine call, that is, resolved by the linkage editor. The PL/I people noticed that Fortran programmers did that, had a string package with a subroutine call for each little string operation, and some of the early IBM implementations of stings in PL/I did something similar, but by F level version 4 IBM saw that really compiling strings was MUCH faster. Basically PL/I and Fortran can be faster than C in array handling, and PL/I is faster than both C and Fortran in string handling.
(4) Structures. PL/I structures are just brilliant: Get to lay out some complicated looking trees with structures of arrays of structures of whatever elementary data types, and, still, ALL the addressing is just from the standard array addressing logic. And get to set the array bounds during execution via Automatic, Controlled, or Based -- powerful stuff. Then in tasking Controlled is tasked based so goes away on its own when not wanted.
(5) Exceptional condition handling in PL/I is gorgeous.
I like old Basic, Algol, Fortran, PL/I, the scripting language Prime used, the scripting language CMS on CP67 used, Rexx, Open Object Rexx, Kexx (with KEdit), the .NET version of Visual Basic. Is that enough? Oh, might as well consider TeX -- terrific stuff. I will probably like Power Shell when I take time out to learn enough of it. Am I out of the dog house now? Am I permitted to have a cookie, please?
Sometimes I wonder if anyone can write a JCL from scratch. A new JCL is always copied from an existing one and the gets modified. The first couple of lines of a JCL are particularly scary if I recollect properly.
The PDP-10 family ran a few operating systems in its life, some of which had better or worse user interfaces, but one of the things the all had in common was a focus on interactive use as opposed to batch operation or even block-mode terminals. Interactive use means each concurrent user represents more system load compared to the alternatives.
