Implementing CA Datacom Shadow MUF

book

Article ID: 25223

calendar_today

Updated On:

Products

CA Datacom CA Datacom/AD CA Datacom/DB

Issue/Introduction

I have a currently running CA Datacom MUF and would like to implement a shadow MUF - what do I need to do to accomplish this?

Environment

Release : 15.0

Release : 15.1

Component : CA Datacom/AD

Component : CA Datacom/DB

Resolution

There are several steps required to set up the Shadow MUF:

Setting up JCL for the Shadow MUF

Ideally, both the primary MUF and Shadow MUF will use the same JCL member and the same SYSIN entries. However, if you cannot use one member on both LPARs, then you should create a duplicate copy as needed. If running both MUFs on the same LPAR, you might need to use a unique jobname to allow them both to run concurrently.

Note that if you are using the SYSOUT parameter in the MUF Startup Options, you do not need a PXX file defined in your JCL, and we would recommend you use the execute parm NO_PXX to indicate this. If you are also using the PGMDT parameter as recommended, your EXEC statement may look like this: 

//MUFSTRT   EXEC PGM=DBMUFPR,PARM='NO_PXX,/PGMDT=20200101', 
//          REGION=0M,MEMLIMIT=NOLIMIT,TIME=1440      

Altering the relevant MUF Startup Options

Once you have a single MUF running and configured for your application's use, it is quite simple to change the MUF Startup Options to support the Shadow MUF. As with all changes, we would recommend making a copy of the SYSIN members before making changes so that you can revert to a single MUF if needed. The link for each option will display the documentation for that MUF Startup Option.

MUF - This option identifies the MUFname used, and we recommend that this option is always set to an asterisk (*), so that the MUF name is picked up from the DBSIDPR module in the CUSLIB. When using a Shadow MUF, the MUFname is dynamically set based on the TARGET_MUF_LIST=() setting in the DBSIDPR module (see below), so this value must be an asterisk. Example: MUF   *,99,NO

MUFPLEX - This option indicates that there are multiple MUFs that will be linked together. In a single-MUF mode, this option is not used and is likely commented in the SYSIN. To use this, (1) identify a name for this "Plex" of MUFs—different from the MUF name—and then (2) set the 2nd parameter as asterisk (*), (3) leave this blank, (4) enter the maximum number of tasks that will be used by either MUF, or higher value like 1000, (5) enter 'S' for this value to indicate a Shadow MUF. If you have applied Version 15.1 solution SO05492, you can use S_NO_STRUCTURE here to run the Shadow MUF more efficiently without a Coupling Facility structure. Example: MUFPLEX   MYMUFPLX,*,,1000,S_NO_STRUCTURE

TASKS - Normally in a Shadow MUF configuration, one MUF will run on one LPAR, and the other MUF on a different LPAR. In order to support this, the MUFs must be configured for XCF support through basic Sysplex capabilities. Please see Knowledge Base article 38170, titled "How to configure CA Datacom MUF for XCF use" for more details about this. Here, we need to set the 5th subparameter equal to the 1st. Example: TASKS 250,33K,0,0,250

XCF_FROM - This is also covered in the Knowledge Base article referenced above, and identifies the group name used to link the primary MUF and Shadow MUF to application tasks. This value must match the value of the TOGROUP= setting in the DBSIDPR module. Example: XCF_FROM  *,*,MYMUFGRP,YES

Altering custom DBSIDPR macro parameters

The DBSIDPR module contains identification and configuration details for a specific MUF, and there are certain changes and additions needed to the default definitions to enable a MUF to use XCF and Shadow MUF configurations. For details about these parameters, please see the documentation section titled "Modifying DBSIDPR Parameters."

CONNECT_ALLOW_PRIORITY - this parameter identifies the order in which connections are attempted. We recommend that this value be set to LOCAL first, so that connections will look on the Local LPAR for the MUF, and then XCF second, so that if the MUF is not found on the Local LPAR, the connection will be sought across the XCF connections. Example: CONNECT_ALLOW_PRIORITY=(LOCAL,XCF)

TARGET_MUF_LIST - this parameter identifies the MUF that will be running, and best practice indicates that the value is at most 7 characters. In the case of a Shadow MUF, two entries are required here, and typically, the values are the 1-7 character name of the MUF / CXX, followed by a "1" and "2", or "A" and "B", etc. The names are used dynamically when a MUF starts, so that the first MUF become the primary MUF and uses the first name in the pair, and the second MUF that starts uses the second name. Example: TARGET_MUF_LIST=(MY15MUFA,MY15MUFB)

TOGROUP - this parameter needs to be added to identify the group used for XCF processing. This is noted in the Knowledge Base article referenced above, and the value here correlates with the XCF_FROM MUF Startup Option. Example: TOGROUP=MYMUFGRP

Allocating a unique file for the PXX (optional)

While most of the files can and should be shared between the primary MUF and Shadow MUF, the PXX must be uniquely defined to each MUF. However, if using the MUF Startup Option called SYSOUT to manage the various debugging and trace outputs via the JES Spool within the MUF job, the PXX files are not needed. Please review Knowledge Base article 18269, titled "Using the SYSOUT Multi-User Facility Startup Option" to learn more about this option.

As noted in the section above titled "Setting up JCL for the Shadow MUF," if the PXX is not being used, you can supply a parameter (NO_PXX) to the EXEC statement and eliminate this DD statement from the JCL. In other cases, customers who continue to use the PXX file will need to ensure that the filename used in each MUF is unique.

Additional Information

For more information about the Shadow MUF, its setup and processing, please refer to the CA Datacom Core documentation for the "Shadow MUF Environment."