10/22/2015 Ten things(well, 11) not to forget in z/OS Capacity Planning Greg Caliri BMC Software, Inc. Waltham, MA, USA

04/20/23

Ten things(well, 11) not to forget in z/OS Capacity Planning

Greg Caliri BMC Software, Inc. Waltham, MA, USA

These foils = For a few days find it at

› ftp://ftp.bmc.com/outgoing/philacmg

› Or e-mail me [email protected]

› Or call me 978 372 3685.

© Copyright 04/20/23 BMC Software, Inc.2

ftp://ftp.bmc.com/outgoing/philacmg

mailto:[email protected]

Capacity planning for z/OS systems

› Not a simple process if done correctly

– Consider more than CPU capacity– Several other important facets to be considered– Overlooking them could cause problems

Essential premise …

› Look beyond the CPU› Go beyond trending and sizing› Leave few stones unturned

DISCLAIMER….

› Some, but not all of the ideas presented here were presented in IBM capacity planning Redbooks some time ago

› Latent demand, Balance, a few others…

› This has been augmented with several other points

› One reference I used – Business Intelligence Capacity Planning

› http://www.redbooks.ibm.com/redbooks/pdfs/sg245689.pdf


http://www.redbooks.ibm.com/redbooks/pdfs/sg245689.pdf

Ten (no, eleven) things to look out for

› This is largely intro, but there’s something in it for all

› You will likely think of 12, 13, 14, etc. items

› But I only have 60 minutes!

1) Failure to correctly categorize work along Lines of Business (LOBs)

› Discern critical (business-drivers) vs. Important (business-developers) vs. Discretionary (“this can wait”)

› Quiz – what would you put into each?

› Political obstacles may have to be overcome


How to accomplish this – a four step process…

› Use the framework you do know –– Identify the company’s main line(s) of business– The enterprise’s development activities– Future activities that will be incorporated into your capacity plan

› What you don’t know – Ask, interview, inquire – user communities, business planners– Keep ear close to the ground– Keep asking, things change

› Seek, and obtain upper management approval– If you don’t , cooperation is difficult to obtain


Step four … doing the work.

› Implement categorization in your data collection system– Make use of WLM Report Class reporting

– Categorize batch work as best as you can• SMF type 30 information • Job naming standards• Account coding standards• Data security and scheduling package information Watch for more political issues!

– Categorize online work as best you can• Transactional information collected and identified• Terminal, transaction, program, user identifiable• Turn on monitors and analyze


War stories

› Finding out who’s doing what

› Finding out WHAT’S doing what


2) Failure to collect sufficient data and compile it into useful information

› SMF data– Jobs, subsystem activity (CICS, MQSeries, IMS, DB2, WebSphere)– SMF type 30, all RMF, all subsystem monitors active– DB2 can be voluminous, activate carefully – Newer zIIp, zAAP information– PROJECTCPU option

› Collection usually available (2010) but often information is not compiled accurately

– Flashback to 1) – a sea of data, but limited information

› Solution – resolve 1) as quickly as possible


3) Forgetting about performance, and concentrating only on capacity

› Trending can give adequate answers– Provided that no performance problems are encountered– Provided that you understand your workloads– Provided that you can project not just CPU but other factors

› The average-peak-85 theorem– Most find it effective – explanation– Other factors can cause the philosophy to fail

› Knee of the curve increase– Sudden Death – “Hockey Stick”


“happy days” – my point being … note the clothing


Whenever I compare pure trending to capacity planning with modeling tools, I always harken to this…

I can FIT into those clothes, but I had better not try WALKING in them.

Trending / capacity – the counter argument to it

› It can provide you with quick answers easily but may miss the major point – can the projected work effectively RUN with the new capacity?

› The GOOD news – Capacity on Demand gives you some leeway, and today you may have some margin for error, but you still don’t (necessarily) want to go there.


4) Latent Demand is forgotten, or not assumed or calculated correctly

› Latent demand defined =

It can be best explained as work that would have arrived on the system had resources been available to accept and process it...

What can cause it?- Human behavior

- Unforeseen queuing (particularly, CICS)look for out-and-ready, in-and-ready workRMF type 70 contains several countersSporadic patterns – look for high counts

-


How is latent demand missed?

› Wrong segments of time chosen for study

› Averaging might cause latent demand indicators to be “normalized out”

› Assumptions that the only work coming in will be that in the business plan

› (In general) forgetting that it might be present

› Ballpark analogy – latent demand is desired….


5) Overlooking balance …

› It’s not just CPU !!– I/O activity– Memory Utilization– Controllers– Coupling Facilities

› Device Saturations– Tape devices, might not be foreseen in simple linear CPU studies– Disk devices, can saturate if not running under PAV, causing delays

› Memory / Storage– Rare today, with extended memory addressing, but when/if it does occur, there are problems


6) Unforeseen workload changes, throwing capacity plan out of accuracy

› Capacity plans usually incorporate– Business changes

• “organic growth”• Special events, one-time or recurring• New lines of business … acquisitions• Departures of business

› They often DON’T incorporate (among other things)– Technical changes

• Rewrites of business applications, functionality changes• Time shifting of work• Major workload changes• Time shifts in offices


Avoiding unforeseen workload changes

› Weekly or monthly capacity meetings– Assess changes– Assess the IMPACT of changes

› Model, or otherwise plan with test cycle information– Functionality changes are almost always planned– Sample of work to test from

› Before allowing changes to occur– Ensure they’ll fit– Incorporate them into the capacity plan

› Study your reports– Has anything new shown up recently?


7) Not looking beyond the “Z” (z/OS)

› Distributed systems affect the flow of work in and out of your z/OS enterprise

– Do you check “upstream” – talk with the folks responsible for front-end, or even back-end interfaces with z/OS systems

– Have there been network changes? (latent demand !!!)

– Special events planned? (TV commercial campaign, holiday sale, extended hours, high demand ticket sale, etc.)

– Will they be changing the way they do things, such as using different architecture, or different program interfaces, or passing different packet sizes down to z/OS?

– Expansion of networks or network configuration changes?

– Virtualization in progress ?


Beyond the world of “Z”

› COMMUNICATE!

– Invite those in Distributed Systems to provide you with information;

– Political tactics – inform them that what you do may have an impact on their efforts;

– Inform others of changes

– Attempt to get upper management sign-off on capacity efforts


Beyond the world of “Z”

› Commercial computing is no longer siloed

– Within z/OS, the operating system, and subsystems all are integrated

– Beyond z/OS, the network, various distributed systems, servers, and even the enterprise’ s Internet activity could have an impact what you will be doing


8) Only providing one option, or limited set of options in your capacity plan

› Capacity estimates, with performance estimates can provide you with multiple options

– Different performance results with different hardware configurations• Performance vs. Cost Benefit• Use and benefit of specialty engines? Will you have an advantage?

– Capacity on Demand = turning it on, turning it off, turning it on….• Often used when critical periods are short and can be anticipated• Or can we live with it shut off? … reminisce…

– Deferral of work• Performance options, reviewed, can go at another time


Multiple options … with performance results

› Acquisitions?– Measure performance results based on a number of strategic moves

• Incorporate new company into enterprise processing?• Leave it as is?• Continue to review work on an ongoing basis?

› The more practical information, the more corporate agility that’s provided

› … but even without performance….


Multiple options….

› MANAGERS AND EXECUTIVES WANT AND NEED OPTIONS ….

– There is often more than one path to success

– The desired path to success is one in which the least amount of money will be spent while keeping objectives in place

– You can tie “Natural Forecasting Units” (the US Dollar is a good one) to various iterations within a capacity plan

– Management can alter the plan as they see fit.

– Requirements change over time --- and in either direction.


9) Choosing the wrong interval(s) or information on which to base capacity plans

› Quite often the case in years past– Most sites have multiple “environments”

• Classic “Day” processing of the past, and still in many environments today– Serving one to four time zones (U.S.A.)– A mix of

» Online business-driving activity (CICS, IMS, DB2) » Development batch and testing» Minor operations and maintenance activities» Standard internal tasks, queries, browsing

– Work composition varies from day to day during any month


“Night” Processing

• Classic “Night” processing of the past, and still in many environments today

– Batch cycle– Data Transmissions– Online Test Cycles– Operations crews , problem resolution– Work, not directly related to the business (RMF, SMF-related analysis)– Again, work composition varies from day to day during any month

• Classic “Weekend” processing of the past– Data Base Administration, reorganization– Full-scale backups– Major conversion projects– Operating system maintenance, stress testing


Today?

› There’s no typical “processing environment” that can be applied to every enterprise site

› 24 x 7 x 365 plus global activity

› WebSphere, online activity, sporadic business cycles, mandate that you get a grasp on multiple processing environments that exist in your site

› Trending is extremely useful for identification – BUT --

› As before, if modeling to determine performance impact, you must view your environment as having a series of different processing time cycles -- TODAY you may have more difficulty identifying them.


Today?

› Different time frames require different “what ifs”…

› If changing / upgrading / downgrading hardware and you can perform modeling to measure performance – do it for all possible environments that perform business processing.


10) Failing to relate business impacts within your capacity plan


› A note about reporting – the end result of your efforts….

› A carry-over from item 9 … but , the main purposes of a total capacity plan can include

– Definition of capacity requirements to meet current and projected processing needs

– Assessment of anticipated performance

– BUT – include impact on specific business elements

11) General failure to communicate at the recipients’ levels of understanding

› Different audiences require different explanations

– Compare = operations desk vs, application programming group vs. business end user vs. Operations management vs. Executive levels.

– Each has a particular interest, and needs to know how that interest will be served in terms that are understood AND pertinent to his/her question.

– This may require separate reports – section by section, and written in different fashions

– DO NOT CHANGE THE DATA / INFORMATION! But tell each audience what they need to know in relevant terms.


Documents

10/22/2015 Ten things(well, 11) not to forget in z/OS Capacity Planning Greg Caliri BMC Software, Inc. Waltham, MA, USA