Checkpoints in IMS BMPs:
- You have to have them, but they are expensive.
- They are 100% overhead.
- No productive work gets done while the checkpoint is being taken.
- They elongate elapsed time, consume CPU time, and increase I/O so you certainly would not want to take more of them than you need.
Chances are that a number of your BMPs are taking more checkpoints than they need to take.
How can this be happening? BMPs written a number of years ago included the logic to take checkpoints at intervals that were appropriate for the processors on which they were running. That was likely a number of machine generations ago. The processor speeds today are much faster and the checkpointing interval from those old days is now much too short, resulting in the application taking more checkpoints than are needed.
The faster processors are causing other unexpected problems, too. They are hiding these checkpoint offenders from you. With faster processing, the BMPs finish in the same or less time than they did previously, so there is no indication that excessive overhead is taking place.
You need a way to find BMPs that are taking too many checkpoints. One checkpoint a second is a good pace for most applications. Once you identify the offenders, ideally you would like to fix the problem without changing the application programs. Those changes use developer time, require testing to verify, and ultimately need change control processing to get the modified programs back into production.
Using BMC Log Analyzer for IMS and BMC Application Restart Control for IMS allows you find and fix excessive checkpointing BMPs. BMC Log Analyzer provides the APPCHECK utility that reads the SLDS and provides an analysis of BMP checkpoint offenders. It looks for BMP updaters that have taken more than one checkpoint per second and reports on them.
The report above was from a BMC customer (hence the hiding of the actual job names, etc.) and shows jobs that took from 3 to over 50 checkpoints per second for the duration of the job.
Now that you know the BMPs to target, create a policy that will be used by the checkpoint pacing functionality in BMC Application Restart Control for IMS (AR/CTL) to bypass unneeded checkpoints. When the application issues a checkpoint, AR/CTL intercepts the call and uses the policy you created to determine if enough time has elapsed since the last checkpoint was taken. If it has, it lets the checkpoint call through. If not enough time has elapsed, AR/CTL immediately returns control to the program, suppressing the unneeded checkpoint.
With your policy in place, AR/CTL provides an automated way to control the pace of checkpointing without needing to change the application program. By eliminating unnecessary checkpoints from these serious offenders, you can reduce CPU and elapsed times significantly, sometimes by 60% or more.
Get more information by reading the BMC Application Restart Control data sheet, or contact your BMC Account Manager to start a discussion.