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


Article ID: 19004


Updated On:


CA Compress Data Compression for MVS CA Compress Data Compression for Fujitsu CA Datacom CA DATACOM - AD CA Disk Backup and Restore - MVS CA DISK BACKUP AND RESTORE- ADD-ON OPTIO CA DISK BACKUP AND RESTORE CA Ideal CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware CA Datacom/AD



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?


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.


Component: CA90S