View previous topic :: View next topic
|
Author |
Message |
mtaylor
Active User
Joined: 20 Feb 2009 Posts: 108 Location: Kansas City
|
|
|
|
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 |
|
|
Bill Dennis
Active Member
Joined: 17 Aug 2007 Posts: 562 Location: Iowa, USA
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
mtaylor
Active User
Joined: 20 Feb 2009 Posts: 108 Location: Kansas City
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
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] |
|
Back to top |
|
|
mtaylor
Active User
Joined: 20 Feb 2009 Posts: 108 Location: Kansas City
|
|
|
|
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 |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
|
|
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 |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011 Posts: 556 Location: USA
|
|
|
|
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 |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011 Posts: 556 Location: USA
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
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
d |
|
Back to top |
|
|
|