Reducing XCF usage for Datacom MUFs

Products

• Datacom
• Datacom/AD

Issue/Introduction

We have 4 production LPARs with a JOBTRAC primary task running on one LPAR and all other 3 LPARs are connected to MUF (MUFNAME= PRODMUFP). During the nightly batch process, we see lot of requests going between the primary MUF and the Shadow MUF. I wanted to know if there is tuning that we can do to reduce the number of requests going between two MUFs and reduce the CPU burn of XCFAS.  

Environment

Component : Datacom/AD

Resolution

 A review of the RMF reports and the MUF logs shows no problem between the primary MUF (PM) and Shadow MUF (SM) for XCF usage.

Looking at the RMF reports for the LPAR where the Primary MUF was started, I see no activity between the PM and SM, as the SM is in a waiting state and is not active. This is expected, as the SM should not show activity until it is activated. However, there is a lot of activity from both CA 11 and Jobtrac coming to the PM and going back again. The primary Jobtrac output shows more than 26 million XCF requests exchanged with the PM (seen in the DB00139I messages in the Jobtrac log). By looking at the MUF log for DB00102I messages, you can see what jobs were run, and if they ran locally or via XCF.

In general, the best course of action is to have the majority of your work that requires Datacom services run on the same LPAR as the MUF. This cannot be a total workload answer, as some tasks must run on certain LPARs, whether the MUF is there or not (hence the need for XCF), and there may be a need to move the MUF to other LPARs or use a PM/SM configuration when conducting IPLs or other maintenance activities on the LPAR where the PM normally runs. The main point here is that if you want to reduce the XCF processor consumption, you need to eliminate the number of XCF connections being made by managing the location of the workload that is being run.

Some customers have implemented some sort of system processing where they would use a SYSAFF card (like /* JOBPARM S=PRODMUFP), and the system would route the user job to the LPAR where PRODMUFP is running. This could help reduce XCF usage as well as improve job execution times since the requests do not need to go back and forth through XCF. As this is not a Datacom solution, you would need to determine if or how you might configure your systems to perform a task like this.

Additional Information

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