The Cost of JCL Complexity

steve-myers · Posted: Tue Jun 10, 2014 3:16 am

The Cost of JCL Complexity was opened 2 years ago, and rather than append to it I think I'll start over.

JCL appears complex to a newbie. In many respects it is complex; it was designed for a whole different world; it was an attempt to optimize usage for the world as it existed around 1965; many of the issues in 1965 do not apply any more, but they are still there in JCL.

As I see it there are two costs here.

The cost to prepare JCL, and correct problems.

Labor was awfully cheap in 1965; companies were paying senior analysts $7 or $8 an hour. Computers, on the other hand, were frightfully expensive. Your $500 PC is much faster than a $!,000,000 mainframe computer in 1965. Companies were willing to pay senior analysts $7 an hour to make that $1,000,000 boat anchor run a little better.
The machine cost to process JCL was frightful.

You newbies never had the dubious "pleasure" of watching OS/360 operate a card reader containing JCL.

clunk to read a card, followed by a noticeable pause to process the card.
clunk pause, and so on, until all the JCL was read.

Some of us dinosaurs never saw this. In systems running a system like HASP, we put our cards into a card reader and pressed the Start key. HASP would read a dozen or so cards, the reader would stop for maybe 1/2 second, and then resume reading cards at full speed. The clunk pause cycle was still there when HASP ran your job, but it was hiding in HASP. You never saw it.

Now let's discuss some of the issues that made 1960s JCL relatively complex.

The JOB statement. Remember these $1,000,000 boat anchors were frightfully expensive. Bean counters saw the expense. To some extent they understood the overall productivity improvement the boat anchors produced, but they still wanted to have some understanding about who was using the boat anchor, and how much they were using it. The JOB statement provided this link. In the 1980s I worked for a service bureau type company. Every day the computer produced a report showing the top 10 users. After a while, I called the denizens of this report the "dirty dozen." Invariably the dirty dozen was staff. I was usually in the report. I don't think I ever saw a paying user in the dirty dozen.
The DD statement
- The UNIT parameter
  
  There were quite a few different types of I/O devices in 1965. The programmer, as well as the bean counters, wanted the user to use the best possible I/O device. Even in 1965, there was rarely more than 2 or 3 to select from in any one shop. Now, in a very real sense, everything is virtual, or at least sort of virtual. We have one disk unit type - 3390, and that has been virtualized to any of several different RAID devices. We, as users, neither know or care. For that matter, so do the bean counters.
- The SPACE parameter
  
  I'm guessing the SPACE parameter is at or near the top of the hate list of every programmer. Heck, in Windows or *NIX my files can keep on growing until I literally run out of space. There is a cost to this. In Windows, and also, I suspect, in *NIX, there is a hidden file that shows were the real, related file, has space allocated. Reading through the hidden file to find out where the real data exists adds to I/O time. MVS also has hidden data containing this information. OK, it's not really hidden; it's in the VTOC. When we open a data set, this hidden information is retrieved from the VTOC and saved in storage until the data set is closed. But we don't do any extraneous I/O. One of the purposes of the SPACE parameter is to limit the amount of hidden information.
  
  In 1965, disk storage was very expensive. As is usually true of expensive resources, the amount of the resource was limited. The SPACE parameter was intended to make the relatively cheap analyst correctly determine how much of this expensive resource was really needed.
  
  Now, of course, it's just a source of frustration for the $40 an hour analyst. Well, for those of being paid by the hour, it does add to billable hours. Screw the bean counters!

don.leahy · Posted: Tue Jun 10, 2014 6:21 pm

SPACE: Us old timers have turned an ancient necessity into a professional virtue.

An old systems analyst once growled at me: "If you don't know how much space you're gonna need, then you don't know what you are doing".

It does seem ludicrous however to be discussing tracks and cylinders for DASD that hasn't physically existed (outside of museums) for over a decade.