I agree with Ed. There are always cases where the effort and cost might
outweigh the benefit of tuning, but there are still many cases where thereis
cost savings. As others have mentioned there is always value in meeting the
business SLA's and the online files being available. A side benefit is the
junior staff have an opportunity to improve their knowledge and skill set.
Also, these efforts tend to invigorate and energize those who might be stuck in
a rut of boring tasks. Most are familiar with the following list of easy
changes to improve performance and reduce costs: 1. Change programs to use
BLOCK CONTAINS 0. Where files are blocked 1x1 during create and then all reads
are improved too. The CA TMS files are blocked 1x1(340/340 or 370/370) at
many installations and should be changed to blksize 8840 and 8880 per CA.
2. TURN on CARECLAIM and then daily/weekly/monthly VSAM REORG jobs can be
discontinued in addition to the disk and I/O savings.
3. TURN on ICEGENER to replace IEBGENER (or SYNCSORT version) at the system
level. Saves 6 to 8% CPU.
4. Find all GDG's that have not been updated in say more than a year by using
LISTCAT and sorting on LADAT(Last Alter Date) and then delete those. Found
over 100K obsolete GDG entries at 3 different sites.
5. Find all jobs creating over 200K lines(or some large number) and do a quick
review to determine if the output is needed and if so drive it to a file. This
can save output to JES and your Archive System.
6. Change large tape(multi volume) file(s) to disk PSE if they are read by many
jobs. This allows two or more jobs to run at the same time.
7. Find all jobs that have DSN WAITING for more than 15 min(pick your number of
min) and review for incorrect disp=old or change job to run earlier or later
or move a step(s) to another job.
8. Find programs that OPEN file read one RECORD CLOSE FILE. This a giant
resource saver and most places have one or more of these.
9. Increase REGION on job card or EXEC to REGION=6M or more for large IEBCOPY
steps/jobs and they will run much faster and use less CPU as memory is used
vs. the SYSUT3 and SYSUT4 work files.
I hope this little sharing effort does not offend the good people on this great
list.
David Mingee
Mainframe Consulting
9206 Aintree Drive
Indianapolis, IN 46250
317 288-9588 Home317 903-9455 Cell
From: Ed Gould <[email protected]>
To: [email protected]
Sent: Tuesday, April 7, 2015 8:28 PM
Subject: Re: A New Performance Model ?
Timothy:
Its amazing what a blocked 1 file cost not so much in processing but
waiting .
Try any program that is fairly IO intensive and you will see the cost
in lengthening run time.
I saw one program go from an hour elapsed to 2 minutes.
Cost to resolve one short compile and link.
Ed
On Apr 5, 2015, at 9:28 PM, Timothy Sipples wrote:
>> Our development management are telling is (Systems & Operations) that
>> it is "cheaper to Upgrade the mainfame than to have the application
>> programmers review their code for performance oppurtunities".
>
> I'm disappointed in the reactions so far. They're quite...old
> fashioned. :-( Yes, there is a "new" performance model, but this
> "new" is
> almost as old as computing.
>
> That assertion from the development team's management is certainly
> possible. Development talent, particularly highly skilled talent,
> continues
> to become more expensive relative to most other factor inputs in
> computing.
> That trend exists on *every* platform.
>
> Whether that assertion is true or not in these particular
> circumstances I
> have no idea. More importantly, neither do you yet. This question
> can only
> be answered with a careful cost analysis (or re-analysis), and that
> itself
> is a comparatively rare skill within IT organizations as you and
> others may
> have just demonstrated. :-) It also isn't free to analyze costs.
> Otherwise
> accountants and consultants, including Al Sherkow, among other
> talented
> people, wouldn't be paid.
>
> As a *generalization*, most organizations are running many more
> "MIPS" now
> than, say, 15 years ago. Typically, though, that's at a similar or
> lower
> real cost in terms of infrastructure and operations. At the same
> time, real
> costs for a given amount of quality-equivalent development talent
> have gone
> up. (Raise your hand if you want to dispute that generalization, but I
> don't think it's particularly controversial.) There have been some
> development productivity improvements but probably not as many as
> on the
> operations side. So the overall trend is that your organization
> *rationally* shouldn't be using as much labor cost to optimize code
> as you
> did, say, 15 years ago. Exactly how much less depends on your
> particular
> situation, but "generally less" is the correct, cost-optimizing
> answer in
> most cases.
>
> Is that so surprising? Raise your hand if you're still hand tuning
> code to
> account for disk rotation. That's at least not a common way
> developers are
> now spending their increasingly precious time. The economics have
> moved on.
>
> What you, on the operations side, can perhaps help do is to help
> lower the
> real costs of evaluating, implementing, and testing performance
> optimizations. If the operations and development teams are working
> well
> together, it's wonderful. Some of John McKown's previous posts, for
> example, suggest he's going "above and beyond" in helping his
> colleagues in
> development. You are colleagues, or at least you're supposed to be.
> So, try
> to give them "more actionable" intelligence that's easier (read: lower
> cost) for them to act on. If it's not actionable enough yet, then
> see if
> you can do better. But keep in mind you cost real money, too. :-)
> Prioritization is important for both the operations and development
> teams.
> Also, most well-run development organizations have some sort of "task
> list." The basic idea is that you can log particular recommended
> performance optimizations, especially if you have some specific
> insight to
> report. They may or may not get worked on right away, but if they're
> officially logged they're better documented. That could mean, for
> example,
> they get worked on with the next major set of application changes.
>
> There are many development organizations that now depend on
> bringing in
> contractors. When those contracts expire, it gets that much more
> expensive
> to bring them back. Some organizations are quite reluctant to do that
> absent a compelling enough reason. Functional correctness to the
> business
> always takes precedence.
>
> Said another way, given enough time, money, and effort EVERY highly
> talented performance expert can find ways to improve the
> performance of a
> real world system. There are even programming contests oriented
> that way.
> That reality is not actually all that interesting. What is more
> interesting
> is whether that hypothetical expert can do her work within a
> particular
> budget, productively enough in terms of real world savings to pay
> for her
> applied and increasingly expensive expertise. Sometimes yes,
> sometimes no,
> but increasingly, for better or worse, no. Whether it's mainframes or
> microwave oven microprocessors, the same general trends apply.
>
> Said yet another way, if you think saving one MIPS is a worthy goal
> in and
> of itself, you've completely lost the plot.
>
> Centuries ago salt used to be extremely precious. Its distributors and
> consumers went to great lengths (and expense) to make sure salt was
> only
> used sparingly, mostly allocated to improving the chances of human
> survival
> (i.e. food preparation and preservation). Nowadays some of us throw
> salt
> over our shoulders, and others throw it onto icy roads. Salt is not
> valueless, but it's far less precious than it used to be. So those
> of us
> who are cost sensitive (most of us) can rationally be somewhat more
> cavalier about how we use salt. Maybe there are a few salt efficiency
> experts figuring out ways to economize on salt, but there aren't
> too many
> highly paid people doing that. The economics matter.
>
> On the other hand, the Western United States used to behave as if
> water was
> unlimited and virtually costless. Thus growing almonds in the
> desert to
> supply 80% of world demand made sense, at approximately 1.1 U.S.
> gallons of
> water per nut. The economics are now changing. Western water is more
> precious.
>
> Your mainframe "MIPS" have become and are becoming less like
> Western water
> and more like salt, quite simply.
>
> Yes, I'm perhaps biased (and always speaking only for myself here),
> but I'm
> also correct. :-)
>
> ----------------------------------------------------------------------
> ----------------------------------
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
> E-Mail: [email protected]
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
