Implementing Datacom Shadow MUF
Article ID: 25223
Updated On:
Products
Issue/Introduction
I have a currently running 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 : Datacom/AD
Component : 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 Datacom Core documentation for the "Shadow MUF Environment."
As always, please contact Broadcom support for Datacom if you have further questions.
Feedback
