Portal | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Forum Index
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
The Cost of JCL Complexity

Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> FAQ & Off Topics
View previous topic :: :: View next topic  
Author Message

Active Member

Joined: 30 Nov 2013
Posts: 860
Location: The Universe

PostPosted: Tue Jun 10, 2014 3:16 am    Post subject: The Cost of JCL Complexity
Reply with quote

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!
Back to top
View user's profile Send private message


Active Member

Joined: 06 Jul 2010
Posts: 692
Location: Whitby, ON, Canada

PostPosted: Tue Jun 10, 2014 6:21 pm    Post subject:
Reply with quote

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". icon_lol.gif

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> FAQ & Off Topics All times are GMT + 6 Hours
Page 1 of 1


Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Report cost in CA-dispatch Nileshkul CA Products 3 Wed Jun 07, 2017 10:32 pm
No new posts Cost of an UPDATE query when executed... sasanka DB2 3 Sun Oct 13, 2013 12:06 am
No new posts Cost of mainframe job! fredrick andrews JCL & VSAM 2 Thu Sep 05, 2013 12:54 pm
No new posts COST*RATE Vs MIPS Vs CPU Rohit Umarjikar DB2 10 Fri Apr 26, 2013 3:14 am
No new posts REXX utility required to generate a C... tmaheswara CLIST & REXX 10 Tue Apr 09, 2013 5:14 pm

Back to Top
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us