How often to recycle Datcom MUFs and CICS regions

Products

• Datacom
• Datacom/DB
• Datacom/AD

Issue/Introduction

Is there a recommended guideline as to how often a bounce or recycle should be performed on CA Datacom MUFs outside of system changes? I would extend that same question for our CICS regions which are currently bounced weekly to avoid short on storage issues.

We are looking at reducing the frequency of recycles. Can we leave these regions running longer and still maintain high confidence that the systems are optimal?

 

Environment

Component : CA DATACOM/DB

Component : CA DATACOM/AD

Component : CA DATACOM CICS SERVICES

 

Resolution

As with tuning, this question about when to recycle a MUF or CICS region is more of an art than a science, and I expect instinct will be more of a driver than experience. Below are some thoughts from the CA Datacom product team about this.

• A number of clients run the MUF for 3-month cycles, some others run 6-month cycles, and one client noted that they had a MUF up for 10 months.
• We have designed our MUF to now run for much longer cycles, and have made many changes to memory management to optimize our processing.
• Using a Shadow MUF configuration, it is possible to roll the MUF processing from the primary MUF to a Shadow MUF (which is essentially a new instance of the MUF), allowing for IPL of the primary MUF's LPAR without having any application outage. With this method, it is possible to recycle MUFs while giving the appearance of continuous operation. We had one site that did this for almost 5 years until they had a hardware failure that crashed the whole Sysplex! Here are some other benefits from using a Shadow MUF:
  
  • Both standard and emergency IPLs can be made without incurring an application outage;
  • The configuration provides fault tolerance for both the MUF and the LPAR/image;
  • Maintenance and start-up changes can be made almost seamlessly, and these changes can be reverted almost as seamlessly;
  • Tuning changes requiring changes to MUF Startup Options can be implemented almost "on the fly" and tweaked as needed by changing to the newly started Shadow MUF.
  • Without a Shadow MUF configuration, the MUF can be cycled with the IPL, whether weekly, monthly, quarterly or longer. However, without a regular cycle or with an elongated cycle, capturing and processing statistics becomes more challenging. In this situation, running regular ALL_INFO_REPORT commands, using AutoInfo or AutoCollect can make this much easier.
• For the CICS regions, it is not as easy to declare the best practices. Since there is a lot of user-code running and changing on a variable basis, it is not always easy to commit to error-free processing. For CA Datacom CICS Services, we don't really have a reason to recycle to refresh these modules, but it is far more common for CICS user applications to have issues with hung threads, memory leaks, runaway processing, etc. A number of sites with which we have worked recycle CICS on a weekly basis since the weekends are usually heavier batch processing and very little, if any, online processing. We would probably want to defer to IBM's recommendation for CICS recycling methodologies and how to determine if a region could benefit from a recycle. Since CA Datacom CICS Services is not overly active or dynamic in its processing, there is no great need to recycle here.

The next question that comes up here is what to monitor to see if a recycle is needed. This is difficult to say, since things like buffer utilization, Covered/Virtual definition, elapsed open time, etc. all need to be considered. Generally, there is no real need for special review of a given database for processing, and with the number of 24x7 tools available, most functions you need to do to a database can be accomplished without an outage. As an example, if your capacity management team need to take a volume offline, you can use the Online Area Move facility to create, initialize, and relocate the data from an area on this volume to a new volume - all while users are accessing that area.

So there is nothing special that a recycle of the MUF provides for application data, other than the deleterious effect of no longer having data in the buffers right away - they would need to be reloaded into memory again. In terms of system components, there may not be much gain from recycling the MUF, other than resetting internal statistical counters to prevent them from overflowing (although we have made most of the counters so large, it is not likely that this would happen). An IPL only would reload the PC module DBPCCPR, used for cross-memory communication, but this module can be reloaded at any time by running the CAIRIM program to redefine it - an IPL doesn't really provide any benefit here.

Consequently, if you wanted to go with a one-month cycle, that sounds fairly normal and we have no concerns for MUF processing. If you wanted to expand that to a two-month cycle, that also seems to be fine and somewhat typical.

Additional Information

As always, please contact Broadcom support for CA Datacom if you have further questions.