longpelaexpertise.com.au/ezine/ChargebackToSave.php?ezinemode=printfriend

LongEx Mainframe Quarterly - February 2016

From July 2015, Australian employees receiving shares from an employee share scheme will pay less tax on those shares. This is one way the Australian government is using taxation policy to influence what people do. In many ways mainframe chargeback can work in the same way.

The prime function of chargeback is to recoup mainframe costs by charging business units and users for their "share" of the mainframe. This is almost always based on CPU usage, with some sites also billing users for disk, tape and other resource usage. However it is easy to concentrate on recouping costs, and miss some golden opportunities to persuade users to use less resources. Here are eight ways that chargeback policy can be used to save IT costs.

1. Encourage CPU Minimisation

OK, this seems obvious. But there are some interesting ways of helping this along. Simply charging for CPU is the first way to encourage users to minimise their CPU usage. But there are some other things that could be considered:

• Discount for CPU reduction. So if a user reduces their CPU by 5% from the previous month, give them an additional discount.
• Hit them for CPU increases. Any user increasing their CPU by 10% from the previous month could be hit with a surcharge.
• Assistance in CPU minimisation. Many application teams or users will be unaware of how to reduce CPU. So help them. Provide free technical assistance to reduce their CPU. Advertise and market your CPU reduction services.
• Pre-pay. Another idea is to provide a discount if a customer pre-pays for the month. You could then limit the customer to that CPU usage for the month, or charge them a premium for any CPU exceeding that amount.
• Set a budget. Users could nominate a budget they wish to pay. You could then stop processing, or force it to run slower once this budget is reached. You could also generate alerts when a user or group exceeds their budget.

2. Charge For All Use

Many sites will charge for CPU used by batch jobs, TSO users and CICS transactions. But they often will forget some of the other areas, such as

• FOCUS and iWay Connectors
• Database Connection middleware
• Websphere MQ
• Connect:Direct, FTP and other file transfer packages
• Telnet and z/OS UNIX usage
• z/OS UNIX processes

There are ways for many of these to use exits or other methods to write SMF records with CPU usage. Implement these as much as possible so users don't get a free ride.

3. Show them what it costs

Users will only care about CPU usage if it affects them. Providing them with a regular bill is an excellent first step. However the chances are that the management see this bill, but normal users and CPU consumers won't. A good idea is to show them what their processing costs as close to the processing as possible. For example, you could add messages in batch job logs showing the cost of the job in dollars, euros or renminbi. You could also include messages showing them how to reduce this cost. An example message could be:

Your job cost $254.50. On the weekend, it would have cost $32.40.

Another options could be to have a web page that business units, and possibly even individual users can access to see their CPU usage, and how much their processing costs. Breaking a bill down by user also "names and shames" individual CPU consumers within a business unit. This can allow management to identify their CPU guzzlers, and encourage them to change their ways.

4. Bill Them Properly

Most internal chargeback invoices or bills simply show the CPU usage, and how much it cost. Some will break this down to give the user more information.

This can be taken to a new level with other information to help the user see what they're paying, and how to reduce it. For example, a graph of their CPU costs over the last three months could be included. Possibly include some hints on reducing CPU, or advertise some CPU reduction services they can use.

5. Encourage Off Peak

Most sites pay for the highest four hours of CPU in a month. So there are expensive and cheap periods. For example, weekends, nights before the midnight batch, public holidays. So you want to encourage your users to use these "off-peak" periods. A simple solution is to reduce the cost in these off-peak periods by a number large enough to get your users' attention. Say half price.

But don't stop there. Help users use these off-peak periods. One easy way is to provide a job class that only runs in off-peak periods. So an application developer can submit a large job on Friday afternoon in this class, and it will automatically run on the weekend in off-peak periods.

Some sites take this a step further and prevent non-production workloads during short-term peak periods, like month-end, quarter-end, or a special day. This may be unpopular at first, but with good education and advertising, users often will modify their work habits around these "lock-out" times.

Again, you can display messages in jobs, or when users logon to TSO or z/OS UNIX warning that they are running in an expensive peak period.

6. Encourage LPAR Targeting

There's a good chance that some z/OS systems will cost you more than others. For example, a system running IMS will almost always be more expensive than one that isn't, as IMS incurs an extra charge on all CPU used on the system. Similarly large LPARs may be cheaper than small ones, with less z/OS systems overhead. More modern mainframe processors will provide more value for every CPU second than older ones. Even mainframe boxes with more processors will be a little less efficient than those will less.

So it makes sense to herd your CPU users towards your cheaper machines. You could do this by charging more for each CPU second on the more expensive machine. Or make users pay a premium "membership fee" to be allowed to use more expensive systems.

7. Encourage Buffering

The simple fact is that I/O costs CPU seconds. Anyone familiar with tuning will know that efficient buffering reduces I/O, which in turn reduces CPU. So we want everyone to maximise their buffering efficiency. You can encourage better buffering by not penalising users for doing it. For example, it's possible to calculate a service unit charge to charge for memory usage. Don't do it. Maximise your memory in your machine, and make it free. Advertise that memory is cheap, and you want people to use it. Educate application programmers to maximise memory use and minimise I/O.

Another possibility is to charge for I/O. It's possible for some subsystems to calculate the number of I/O operations (EXCPs) a job / user uses. So you could possibly charge for each I/O. This would encourage users to reduce I/O, and the CPU that comes with it. You can also advertise that VIO (virtual I/O) is available and free.

8. Encourage zIIP and zEDC Usage

zIIP and zEDC co-processors are cheaper than normal processors. You will still want to charge for these alternate processors: they're cheaper, but not free. However encouraging your users to maximise the benefits of these processors makes sense.

Most sites already charge zIIP CPU at a much cheaper rate than normal CPU seconds. The more recent zEDC will no doubt follow on this path. Assisting users to move to zIIP usage will further gain benefits for everyone.

Many records such as SMF Type 30 (job) and SMF Type 110 (CICS) also can be configured to record zIIP-eligible CPU usage: CPU that was eligible to run on zIIP, but didn't for some reason. Showing this information to customers on invoices and other information sources can help them determine why processing did not run on zIIPs, and fix it.

Conclusion

Many see chargeback simply as a way or recouping the cost of a mainframe. However chargeback can be used in the same way that governments use taxes: to influence the behaviour of CPU consumers in a way to reduce your (and their) mainframe costs.

David Stephens