management: Savings Options for Usage Based Mainframe Costs
In our previous article, we looked at mainframe software licensing basics. This licensing buys the rights to use the software, free upgrades
(to a point), and access to support. The bulk of mainframe software costs are based by usage- the more you use, the more you pay. So we all want to
reduce our CPU usage. The good news is that we have two things helping us: z/OS, and IBM.
Any system running under PR/SM or z/VM can be soft-capped. This means that you manually set the maximum number of MSUs available to that system.
Well, not quite. IBM uses a four-hour rolling average MSU figure (4HRA for short). So the MSU figure is the average of this hour's MSU, and the previous
three hours. So if you soft-cap at 800 MSU, the 4HRA will be limited to 800 MSU, though this could peak higher for short periods if needed.
I've seen many mainframe managers who are afraid of soft-capping, and use a conservative capping strategy. This means that the MSU cap is set somewhere
near the maximum MSU usage - so little real capping is done.
However a possibility is to use a more aggressive soft-capping strategy, sacrificing performance for cost. This may sound like madness, but it can provide
savings with no impact. Let me explain.
z/OS has been designed to run at 100% CPU usage, and includes sophisticated workload management facilities. These can allow high priority workloads like
DB2 and online IMS or CICS to continue to use as much CPU as they need, maintaining service levels. However lower priority workloads such as COBOL compiles
and batch report generation get what is left. These lower priority workloads can run for longer periods without affecting service levels.
This isn't something to undertake lightly, and you want to make sure that your z/OS Workload Management is setup correctly. However many users enjoy large cost
savings without impacting service levels by intelligent use of soft-capping.
Some software doesn't need to run on every z/OS system. For example, reporting software such as SAS and CA-Easytrieve, and output management and routing
software such as CA Bundl and Beta 92. So placing this software on one system - ideally the smallest, may save software licensing costs.
Some mainframe users take this one step further and use a 'Penalty Box'. This is a dedicated z/OS with a very small MSU allocation that is only used to
run these specific software products. Not everyone is a fan of penalty boxes, and any savings need to be greater than the effort in setting up and
maintaining an extra z/OS system, not to mention the extra CPU overhead used to run that system. A rough guide is that penalty boxes are best for
larger z/OS users.
Another strategy is to have dedicated z/OS systems. For example, rather than having DB2, IMS and CICS all running on all z/OS systems, one system is
dedicated to DB2, one to IMS and one to CICS. Of course, disaster recovery and service levels need to be considered before taking this option.
Intelligent software placement may also help in using better software licensing options. For example, IBM offers better licensing for zEnterprise users
with their AWLC option. So placing more processing overhead on zEnterprise processors may gain savings. Similarly IBMs zNALC option gives better pricing
for new workloads. So isolating traditional and new workloads may also reduce software costs.
Many mainframe users will have a period of each month where CPU usage is particularly high. I've seen this from end of month processing, when employees
are paid, or product delivery dates.
If there is such a monthly peak, then this is the figure that will be used for capacity-based software charging. The rest of the month is effectively
free. So it makes sense to look at this peak period more closely. An obvious first step is to tune the system during this period.
It may also be possible to manage workloads so that non-essential processing isn't performed during these peak periods. There are many ways to do this,
from adjusting automation settings to discussing processing options with business units.
I've also seen larger shops with different MSU peaks. For example, their overall MSU peak may have occurred on the first of each month, but the peak
for systems running CICS were on the tenth. So there may be more than one peak to look at.
I've seen many mainframe managers who assume that software licensing costs are set in stone, and cannot be reduced. However there are many ways to
decrease the cost of software licensing. IBM can help us here with different software licensing options. z/OS also helps us out with workload management
features to make the most of the available CPU.
Anyone with a mainframe system would be wise to look closely at software licensing options, and the z/OS system CPU usage.