IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

The Cost of JCL Complexity


IBM Mainframe Forums -> FAQ & Basics
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
mtaylor

Active User


Joined: 20 Feb 2009
Posts: 108
Location: Kansas City

PostPosted: Fri May 01, 2009 3:48 am
Reply with quote

Has anyone ever seen an article or read anything about how much the complexity of JCL may have cost businesses over the years? Ie in terms of lost productivety and staffing departments of JCL experts that handle all an organizations JCL for example.
Back to top
View user's profile Send private message
Bill Dennis

Active Member


Joined: 17 Aug 2007
Posts: 562
Location: Iowa, USA

PostPosted: Fri May 01, 2009 9:53 pm
Reply with quote

Do you want to contrast to poorly written/maintained JCL or is all JCL in general too complex?

What's the alternative?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri May 01, 2009 10:44 pm
Reply with quote

I don't think I've ever heard of any organization having departments of JCL experts. There may be a local expert, but not departments of them.

And the only way to estimate the cost would be to have something to compare against -- and there's nothing available on the market to compare against, as Bill pointed out. Mainframes and JCL are pretty intertwined -- no matter how complex JCL may be, it is pretty much a cost of using the mainframe.
Back to top
View user's profile Send private message
superk

Global Moderator


Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA

PostPosted: Fri May 01, 2009 11:39 pm
Reply with quote

Robert Sample wrote:
I don't think I've ever heard of any organization having departments of JCL experts. There may be a local expert, but not departments of them.


Every shop I've worked in up until the current one always had a Production Support Team. One of their responsibilities has always been to code and implement the necessary JCL/PROC's/PARMLIB members to support all of the applications. So personally I'm very used to the concept, and I very much agree that it's usually necessary.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Sat May 02, 2009 4:44 am
Reply with quote

Hello,

Quote:
Has anyone ever seen an article or read anything about how much the complexity of JCL may have cost businesses over the years?
From my perspective, there has been very little cost to businesses due to jcl complexity. Poorly implemented jcl might have a cost, but poor jcl is often not complex at all.

One of the situations that was quite common when jcl first "hit the street" was to very, very many people, jcl was just those confusing, nasty control cards - just a necessary evil needed to run batch programs. . . Those who understood jcl is actually a language and is far more than some necessary evil to get programs to run fared far better. Still do, IMHO.

I believe far more cost to businesses has been generated by incredibly poor design and implementation. One of the newer practices to which i take exception is the practice of making several passes of large volumes of data simply to avoid writing/promoting a few lines of application code.

Talk about snatching defeat from the jaws of victory. . .

Just my $.02,

d
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Sat May 02, 2009 5:42 am
Reply with quote

Quote:
One of the newer practices to which i take exception is the practice of making several passes of large volumes of data simply to avoid writing/promoting a few lines of application code.
I'll echo that, Dick. One of my previous shops had an update program the development manager "knew" was I/O-bound and he wanted me to push for faster disk drives. We finally had a chance to run it through Strobe and found it was CPU-bound (98% of elapsed time and CPU in 1 COBOL statement). It took less than a week to fix the code and the run time dropped by 65-70%. Even with modern computers, it still takes a good bit of time to move data into multiple terabytes.
Back to top
View user's profile Send private message
mtaylor

Active User


Joined: 20 Feb 2009
Posts: 108
Location: Kansas City

PostPosted: Mon May 04, 2009 2:15 am
Reply with quote

Good points all, thanks. I suppose I had two things in mind when writing 'JCL Complexity'.

1) All the obscure details in the JCL syntax like starting continued string literals in column 16 of the following line.

2) The other is the complexity of interaction between jobs, programs, and datasets in large systems.

The first could be somewhat alleviated with more friendly syntax. The complexity of batch systems really has nothing to do with JCL, ie a batch process of 1,000 jobs would be hard to understand no matter what language was used to describe them.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon May 04, 2009 8:00 am
Reply with quote

Hello,

Quote:
The other is the complexity of interaction between jobs, programs, and datasets in large systems.
Once upon a time, most very large systems were thought thru and there was an operational understanding/plan before implementation.

In the last several (10-20) years, many very large systems are "evolving" rather than being planned. They are being implemented/maintained/enhanced by far less than qualified people (management and developer alike). Systems that might not have been so complicated are becoming unmanagable - and again, not because of JCL or some other part of the technology, but the overall inability of the people working on these systems.

[PersonalRant]
Not so long ago the people who were between 35 and 50 years old were the ones with the "heaviest" design/implementation skills and instutional knowledge (which cannot be bought anywhere). These days, that group is harder and harder to find. Largely because what was management 10 or more years ago bought into the hype that they were doomed if they didn't make the switch to "client server"/"open systems".

In addition to the loss of this core group, many places have passed mainframe support to groups who don't really know the technology well and have no idea about what is really important to the business whose systems they support.
[/PersonalRant] icon_rolleyes.gif
Back to top
View user's profile Send private message
mtaylor

Active User


Joined: 20 Feb 2009
Posts: 108
Location: Kansas City

PostPosted: Mon May 04, 2009 6:13 pm
Reply with quote

I could not agree more. Institutional + system knowledge is now being severely impacted by offshoring/outsourcing. This is the argument against outsourcing that is almost never made. Some systems have grown organically for 20-30 years like Dick indicates, and management assumes they can send maintainence and enhancement overseas and get the same result for 1/4 the cost.

It's a lose/lose/lose for everyone involved because the overseas developers have an impossible task, the veteran US developers see stale wages, and the business loses because their mainframe application becomes even more brittle and slow to ehance.
Back to top
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 580
Location: London

PostPosted: Tue Jun 26, 2012 8:50 pm
Reply with quote

JCL complexity is just a direct reflection of the program it is written to support.

A badly designed and badly written application is more likely to require more complex JCL to fulfill the shortcomings of the application program(s)
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri Jun 29, 2012 12:42 am
Reply with quote

I see a slight possibility that the OP may be asking about JCL when it's really "utilities." I see that sometimes, where there are 20 - 30 step jobs full of ICETOOLs and IEBGENERs and SORTs. Someone looks at that, doesn't see any COBOL programs in the EXEC statements, and calls it "a JCL."

It gets worse when there are database loads/unloads, FTPs, backups and third party utilities. When you look at anything that isn't a COBOL, it's a JCL.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri Jun 29, 2012 12:46 am
Reply with quote

To pile on: We have a guy at our shop that is "not allowed" to write programs, but he is "allowed" to modify JCL.

Most of the data requests he gets turn into an extract/convert job with about 15 data passes. Lots of SPLICE commands, lots of JOINKEYS, tons of OUTRECs, everything in a temp file except the final output.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Fri Jun 29, 2012 12:55 am
Reply with quote

Hi Ed,

Quote:
We have a guy at our shop that is "not allowed" to write programs, but he is "allowed" to modify JCL.

And that possibly includes the ability to update Production files or Insert/Update queries in SQL against Production databases. . . With no proper audit trail and possibly no formal rutnover process.

Several of my clients have a stripped-down turnover process for "JCL changes" which your guy would probably love icon_wink.gif

d
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> FAQ & Basics

 


Similar Topics
Topic Forum Replies
No new posts RACF cost vs. ACF2 cost IBM Tools 2
No new posts Report cost in CA-dispatch CA Products 3
No new posts Cost of an UPDATE query when executed... DB2 3
No new posts Cost of mainframe job! JCL & VSAM 2
No new posts COST*RATE Vs MIPS Vs CPU DB2 10
Search our Forums:

Back to Top