Mainframe, MVS and zOS Discussion

Hi,

How can we measure the CPU utilization by a Job?

I have Job which executes a program. Now this program was using linear search while now has been change to use Binary Search. There is change in CPU time which I picked up from SYSOUT of the Job. Can this time be used as to show the CPU utilization of the Job? And how can I convert it to MIPS or MSU to tell how much MIPS it might save over a year?

The SMF type 30 subtype 5 records report at job termination on that job. CPU time (both total and SRB) are reported on the subtype 5 record.

And how can I convert it to MIPS or MSU to tell how much MIPS it might save over a year?

You cannot do this. MIPS / MSU is a measure that applies ONLY TO A MACHINE -- never to a job, address space, started task, or OMVS process. You could calculate how many CPU seconds you save over the course of the year, but that does NOT measure MIPS or MSU. Another consideration -- if your site uses sub-capacity pricing, the rolling 4-hour average (R4HA) is the determinant of price for the month. And if your job runs at a time that is NOT the highest R4HA for the month, the impact of your reducing the job CPU time on the monthly bill from IBM will be … ZERO! If your site converts to the new Tailored Fit Pricing model, then reducing the CPU time won't reduce the monthly bill but make help prevent incremental charges (caused by going over the annual CPU limit). But under no circumstances will you be affecting MIPS / MSU because for a given machine, those are constants. To change the MIPS / MSU number for the machine, you upgrade (or downgrade) the machine. The LSPR / ITR table at https://www-01.ibm.com/servers/resource ... enDocument tells you the MIPS (PCI) / MSU ratings for each machine.

Thanks. But then what is use of saving CPU seconds? How do you showcase them to your managers?

Saving CPU seconds can reduce costs -- but it REALLY depends upon the specifics of the contract with IBM. If your site uses sub-capacity pricing (not all sites do) AND the job CPU reduction lasts long enough to impact the R4HA, then quite a bit of money can be saved (thousands of dollars). But to impact the R4HA, the job has to run for a long time (maybe not 4 hours, but certainly for a while). Even if that one job doesn't change the R4HA, perhaps changing a number of jobs will affect it.

Sometimes small changes can have big impacts -- there was one COBOL batch job I worked on over 20 years ago; it was intensely CPU-bound (source analyzer showed 98% of the CPU time was on a single INITIALIZE statement). Changing the INITIALIZE managed to reduce run time from 75 minutes to 15 minutes with equivalent CPU time reduction of 80+%. Changing a sequential SEARCH to a binary SEARCH can show plenty of CPU reduction (studies I've seen indicate the break-even point is 50 table entries; less than that and sequential is faster but more than 50 makes binary faster and the speed differential improves as the number of table entries goes up).

You would have to just consider "TCB time", and not "SRB time" because "SRB time" is something that we don't have control over as they will be scheduled by some ISV products or IBM code.

@priya I would reckon CPU time savings go hand-in-hand with Elapsed Time savings - which OUGHT to be of interest to your management.

I would also say that ranking jobs by CPU time is the best way to decide which to tackle in an overall CPU reduction effort.