IBM Mainframe Forum

Hi,

I have read in a blogpost title "poor mainframe performance" that bad JCL files can cause real performance problems.

Thinking about this topic it came to my mind that I have no idea how to write a JCL with performance issues in mind...

So I would be interested in Do's and Don'ts, tipps and tricks or just a list of "performance blunders" that you have encountered.

Thank you!

The blogpost can be found here: http://it.toolbox.com/blogs/mainframe-world/poor-mainframe-performance-39612

nothing so great being told there
I wonder with what kind of incompetent people the has worked with
In the land of the blind, the one-eyed man is king
all the issues he deals with are just part of the basics of operation management ...

and all at the end comes to analyzing resource contention issues
and good application documentation, planning and periodic review .

the people writing jcl should follow the application recommendations
so is not jcl that is poorly written, the issue lies at least one step above!

JCL in se is not good or bad, it just implements a process according somebody else requirement
if the application support/planning tells that the outlook for data volume is 382 zillions of megabytes
the people writing JCL must setup things with that in mind ...
when planning for the application deployment somebody else should have already taken care of that

The thrust of the article is that JCL changes and scheduling changes can make major differences. You seem to be ignoring the scheduling changes piece. While it is possible to make big improvements by changing JCL, it really depends upon the site. If the site has already cleaned up its JCL, then the improvement would have to come from scheduling changes.

JCL changes that can improve batch performance:

- ensure every file has plenty (i.e., 50 to 100) of buffers (may require more memory)
- ensure every disk file uses half-track blocking (may require program changes)
- ensure every tape file uses full blocking (as close to 32760 as possible) -- also may require program changes
- check for unnecessary steps (such as sorting a file that isn't used again)

I think it does address something that's been a pet peeve of mine for a while. Which is, for some reason, the task of developing and maintaining the production environment has moved away from dedicated production support specialists and towards programmers. I don't know what has driven this change, but, from those here who know me, I've been outspoken against it for a long time now.

Hello,

the task of developing and maintaining the production environment has moved away from dedicated production support specialists and towards programmers

And most of the new programmers have been taught that JCL is only those nasty // statements you have to use to run your program. . . The concept that well implemented/documented production jcl can make a major difference has been (or is being) lost. Also forgotten is that the L in JCL is Language.

Very few new people actually learn/know JCL anymore and implement some of the most horrible batch "jobs" ever seen.

Well there are several issues here. One issue is the impact "bad" JCL can have on other workloads. For example -

// DD UNIT=(TAPE,2),...

This is good for the job when operators manually "hang" tapes. The operator could "hang" the second volume while the first volume was being processed. It is not so good wen many jobs are being run in parallel and there are only a limited number of tape drives. Also, it is not so good when the tape drives are assigned to a tape library: the robot can "hang" cartridges much faster than any operator. Finally, if there is just one tape volume for the dataset, it's obviously not so good. Production control knows more about the environment than a programmer, who in this day and age may be half way around the world.

Another old issue - it's moot now - has to do with BLKSIZE selection. This really became true in the early days of error correction,when the hardware could correct a single bit error but failed if there were more bits in error. In those days I was a JES2 systems programmer, when the JES2 checkpoint was usually written as nearly a full track. On a 3350, a device that did single bit error correction, I lost about one JES2 checkpoint a year to a data check. Later on the JES2 checkpoint was written in 4K blocks, as is still true today, and the checkpoint failures went from one a year to 0. The only JES2 checkpoint I lost after the change was almost certainly because IBM maintenance people were pulling cables and probably moved an active I/O cable. I came away from that experience with the conviction that very large block lengths were not necessarily a good idea since the chance of a multiple bit error increased linearly as the block length increased, Now, of course, at least on DASD, the error correction unit is a cell, which is quite small, roughly 30 bytes on a real 3390, so the chance of a multiple bit error is correspondingly very low. RAID technology reduces this to 0 by making multiple copies of the real data and scattering the real data all over the real DASD farm.

Robert Sample wrote:...JCL changes that can improve batch performance:

- ensure every file has plenty (i.e., 50 to 100) of buffers (may require more memory)
- ensure every disk file uses half-track blocking (may require program changes)
- ensure every tape file uses full blocking (as close to 32760 as possible) -- also may require program changes
- check for unnecessary steps (such as sorting a file that isn't used again)

I don't agree with some of these ideas.

• I/O buffers. Whenever I've experimented with more I/O buffers I rarely see much improvement. I think the equivalent of two tracks for DASD resident datasets should be enough. That amounts to 4 buffers for datasets using half track blocking, though I would leave the default (usually 5) unchanged. The same for tape.
• Half track blocking. Agreed.
• 32K blocks for tape. Agreed, but ... it is not widely known, but much of the performance improvement you see in tape drives that write "compressed" data comes about because the drive actually writes 64K physical blocks, and pretty much ignores your DCB parameters. This reduces the amount of tape space use for inter block gaps, which is quite large for the faster streaming tape drives that are the norm these days. Earlier today I wrote a long reply (but did not post it) for another topic where I discouraged the use of longer blocks, but that was for I/O devices that implemented single bit error correction for a block, something that is no longer seen. It is much harder to measure the impact of large I/O buffers with "virtual" tape.
• Unnecessary processing. Agreed, unless the output is a feed to something else.

I/O buffers. Whenever I've experimented with more I/O buffers I rarely see much improvement. I think the equivalent of two tracks for DASD resident datasets should be enough. That amounts to 4 buffers for datasets using half track blocking, though I would leave the default (usually 5) unchanged. The same for tape.

Different people, different results. I've seen -- on different machines at different companies -- reductions of 80% in the elapsed time for jobs just by changing the buffering (with significant reductions in CPU time and EXCP counts as well). YMMV but it's worth testing because if it makes a difference, it can make a big one.