I am trying to start a new instance of CA Workload Automation Restart Option for z/OS Schedulers (called CA 11) on a second LPAR. Why did it fail with a RC 85(002) when I tried to start this second instance?
The RC 85(02) usually means that there is a problem with the XCF subparameter of the MUF Startup Option "TASKS."
Here are a few things that you need to verify for your setup of your MUF in support of local and remote (XCF) processing:
- In your DBSIDPR assemble (found in INSTJCL member AXCUS01), you need to have CONNECT_ALLOW_PRIORITY=(LOCAL,XCF) to run from multiple LPARs.
- In the same DBSIDPR, you need to ensure you have a unique name for the MUF in TARGET_MUF_LIST=(), and that you are using a different TOGROUP from any other MUF. The unique MUF name is very important to keep your data integrity. When you make these changes, reassemble DBSIDPR.
- In your MUF startup options (CUSMAC member AXDATIN1), ensure that the MUF option has an asterisk (*) in the first parameter.
- In the MUF options, be sure that XCF_FROM is uncommented and that the XCF group name has the same value as the TOGROUP from DBSIDPR.
- In the MUF options, be sure the TASKS option has an appropriate value in the 5th subparameter (XCF value) to support the number of tasks you will be running on remote LPARs for your base product. Many clients will set this to at least 50-80 percent of the total TASKS value (e.g., if the first value is 200, set the fifth value to 100).
- To utilize XCF processing, be sure your CAAXLOAD and CUSLIB files are APF authorized on all LPARs where your tasks are running, and that you have loaded the CA Datacom PC Call routines with CAS9/CAIRIM on those LPARs.
In summary, you need:
DBSIDPR assembly (INSTJCL Member AXCUS01)
Note that the MUF name must be different from the TOGROUP name and in the case of a Shadow MUF, both MUFs have the same 1-7 root name plus a one-character suffix.
MUF Startup Options (CUSMAC member AXDATIN1)
- XCF_FROM *,*,GROUPNAME,YES
- MUF *,99,NO
- TASKS 250,32K,0,0,100 << 5th value must be greater than 0>>
These items will cover the greatest majority of causes for applications on remote LPARs to not connect to a MUF.
As always, please contact CA Technologies support for CA Datacom if you have further questions.