I am running CA Datacom with a Primary MUF and a Shadow MUF. How do I shut down only the Shadow MUF?

Products

• Compress Data Compression for MVS
• Compress Data Compression for Fujitsu
• Datacom
• DATACOM - AD
• Disk Backup and Restore - MVS
• DISK BACKUP AND RESTORE- ADD-ON OPTIO
• DISK BACKUP AND RESTORE
• Ideal
• CIS
• COMMON SERVICES FOR Z/OS
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware

Issue/Introduction

Description:

I am running my CA Datacom primary Multi-User Facility (called MUF) on one LPAR, but I inadvertently started my Shadow MUF on the wrong LPAR. How do I shut it down so I can start it on the proper system?

Solution:

In order to set up the Shadow MUF for processing, you have to enable XCF functionality within the MUF. This also means you can run a job on any other LPAR in the Sysplex (provide the necessary CA Common Services/CAS9 pieces are in place), and the job will communicate with the primary MUF.

Because this process is in place, the only way to shut down the Shadow MUF is to run the DBUTLTY command COMM OPTION=EOJ or issue the console command /F mufname,EOJ on the LPAR where the Shadow MUF is running. When the job is run, it looks to see if there is a corresponding MUF on the local LPAR first, and it will shut down the Shadow on that LPAR. If the job runs on any other LPAR, the command will be passed to the Primary MUF, shutting down the operational MUF.

If the MUF is started on the "wrong" LPAR, the best way to guarantee this process works as desired is to manually issue the EOJ command from the console on that "wrong" LPAR, since many firms use workload management policies that might move a batch DBUTLTY job to an unexpected LPAR. However, if you can control where the batch job runs, submitting the DBUTLTY will work fine, too.

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

Environment

Release:
Component: CA90S