The goal of analyzing Sub-Capacity Reporting Tool (SCRT) usage is to ultimately manage and reduce your MSU usage, and thus MLC costs. Even for sites that anticipate adopting the Enterprise Consumption option of Tailored Fit Pricing (TFP), there can be significant long-term benefit from reducing their current 4-Hour Rolling Average (4HRA / R4HA) based expenses.
This is because pricing for Enterprise Consumption is determined using a baseline of the prior 12 months of software expense. So expense reductions that can be achieved in that baseline will create savings for years to come.
I’ve demonstrated in other videos the power of insight into your SCRT that can help you reduce your peak 4HRA, and how SMF 89 data can help avoid unintended usage data. In the video below, I want to focus on the importance of using a powerful interface to filter and customize your views. Using a solution with these powerful capabilities can help you:
- Exclude Dev Test Systems in your SCRT Reporting
- Examine the MSU Impact of Moving Your Batch to a Different Day/Time
- Compare MSU Savings Before Making Prime Batch Shift Changes
- Examine the Impact of Soft Capping on Reported MSUs
Exclude Dev Test Systems in Your SCRT Reporting
If you have a situation where test systems are covered by a dev tests container pricing agreement and aren’t included in the general SCRT reporting, then setting a global filter can exclude only those test systems that you choose to exclude. (Vice-versa, you can use the global filter to look at exclusively those systems.)
This type of filter allows you to only look at the production system and exclude the test systems from your analysis. In the example demonstrated in the video, you can see that after excluding the dev-test systems, the peak MSU values and peak intervals changed.
Easily Examine the MSU Impact of Batch Changes to a New Day
Many sites that have batch occurring on one particular day would like to know the MSU impact of moving their batch to a different day. Here, powerful filtering capabilities can also aid.
In the video above we examine a site whose batch was frequently setting monthly peaks on Sundays. The site wondered what the impact on their MSU values would be if they made changes to that batch cycle and removed the peaks occurring on Sundays.
With a powerful solution at their disposal, they could easily change the days that were included and remove the Sundays and then automatically see what the peak was without that Sunday batch cycle. (Of course in the data being used for the demo, those values don’t change because the peak isn’t occurring on Sundays.)
Compare MSU Savings Before Making Prime Batch Shift Changes
We’ve also worked with a number of sites who currently have batch setting monthly peaks at nights, but have considered changing their cycles so that their day shift online sets the peaks. However, without the visibility to see the MSU savings, they were hesitant to make the change.
Again, powerful filtering capabilities allow you to set the shift and only include the prime shift and then immediately see what your new peak would be either graphically or in the table form as well.
Examine the Impact of Soft Capping on Reported MSUs
Additionally, the capability to apply a global filter to your environment to isolate on, or specifically remove particular systems offers many benefits.
For example, you can choose to select only intervals when soft capping impacted the reported MSU’s. And going one step further, you can limit the interval based on time (like a week) so you can see the impact even better.
This allows you to see at a glance:
- when soft capping affected MSU’s
- on which systems soft capping affected MSU’s
- what the amount of the soft cap value was
- the values of the soft cap when it was in effect
Watch the video above to see all of these examples in detail.
Avoid MLC Charges on Unintended Usage Data Using SMF 89 Records
The SMF 89 record type stores the CPU of each registered Sub-Capacity product over time. This is useful for avoiding MLC charges on unintended usage and much more.
Troubleshoot High CPU and zIIP Utilization in WebSphere Application Server
A common problem performance analysts encounter is high CPU utilization on a server or application without the ability to identify the root cause of the problem quickly and easily.
Monitor WebSphere Data Volumes
This video introduces the topic of transaction reporting based on the SMF 120 subtype 9 record, specifically in terms of data volume per request/response.
Supported Areas in IntelliMagic Vision for z/OS Systems
Monthly License Charges (MLC)
Tune your processor configuration to increase the MIPS you get out of your mainframe hardware.Learn More
Configure Coupling Facilities for optimal availability and proactively identify hidden health and performance risksLearn More
See Buffer Pool imbalances and proactively identify upcoming risks to your Db2 health and performanceLearn More
Save time looking for problems and profile CICS transaction data and see transaction response timeLearn More
Ensure sufficient capacity and consistent performance for IBM zEDC availability.Learn More
Monitor the health of your TCP/IP and analyze traffic from different perspectives.Learn More