Datacom MUF wont stop running DB00244I EOJ DELAYED ACTIVE TASK

Products

• Datacom
• DATACOM - AD
• Datacom/AD
• Datacom/DB
• Datacom/Server

Issue/Introduction

There may be times when the Datacom Multi-User Facility (MUF) will not come down when you issue a COMM OPTION=EOJ (normal shutdown).

The following message is issued:

DB00244I   EOJ DELAYED, ACTIVE TASKS: task1, task2,...,taskn

Environment

Release: 15.1

Cause

The  DB00244I message  will tell you what active tasks exist in the MUF that are delaying the EOJ. These tasks have to complete before the MUF will end successfully. From the DB00244I message documentation:

Reason:

This message occurs if the Multi-User Facility (MUF) is told to EOJ while jobs are still connected. In this process, MUF must allow no new connects to start and must wait for current jobs to end. This message provides information that allows the operator that requested the EOJ to know what jobs are still connected and why the MUF is not yet ending. In the message text, task1 is the ID of the first task that is still active, followed if necessary by any other tasks that are still connected.

Action:

While this message is for informational purposes, be aware that some jobs might need to be told to disconnect from the MUF in order to allow the EOJ to complete.

Resolution

There can be several reasons why this happens. Here are three of the most common reasons why the MUF will not shut down:

1. Existing batch tasks are still running in the MUF.
   
   The MUF will not come down until all tasks have finished. The MUF has to finish the tasks that were pending when the EOJ was accepted. Once you submit the EOJ request to stop MUF processing, any new jobs sent to MUF will get a return code 68. MUF has quit accepting new work at this time.
   
   For example if you have a batch job that has opened an URT, it will have a task attached within the MUF. Until this batch job closes the open URT or the batch job ends, the task will remain in-use and the MUF will not shut down (normally). To end the MUF normally, you will need to either force the batch job to end or cancel the batch job. The  DB00244I message  will tell you what batch jobs are active. 
   
   You can request the MUF to end immediately  with a z/OS operator CANCEL command, but this will cause the MUF address space to cancel and cause jobs that are attached to the database to receive a "bad" return code on their next database request.
   
   
2. Existing online tasks are still attached in the MUF.
   
   Online facilities such as CICS (using Datacom CICS Services) and Datacom Server use special logic to attach a number of tasks in the MUF to their regions. These MUF tasks are considered in-use even though there may not be a current CICS transaction or Server (ODBC/JDBC) task currently using any of the MUF tasks.
   
   For Datacom CICS Services, you will need to do a DBEC PERFORM,DISCONNECT to release the MUF tasks. Closing all (open) URTs  or terminating the CICS region will also release the attached tasks.
   
   For Datacom Server regions, the MUF tasks are attached when the region is started, and they are not released until the region is ended. So in order to successfully end the MUF, you will need to terminate the Server region.
   
   
3. Other Broadcom products are still attached in the MUF.
   
   There are a growing number of products that either interface directly to the MUF (like Sysview ) or use the MUF as a data repository (like CA 11, CA 7 and Scheduler ). These products have the ability to attach multiple MUF tasks to their address spaces. If one of these products has an attached MUF task, the MUF will not be able to end normally.
   
   Depending on the product, you may have a product specific command that will suspend the processing being done against the MUF and release the MUF tasks. Consult the product documentation for more information on the availability of these commands.
   
   Terminating the product's region automatically disconnects the attached MUF tasks, and allow the MUF to end normally.

In summary, a MUF that is processing a lot of requests is not going to come down immediately. How busy the MUF was at the time the EOJ was requested can make a difference in how long it will take for it to end. If you decide to "operator cancel" the MUF to get a quick end, the RESTART process of the next startup of the MUF will have additional work and can actually take longer than usual to come back up.

Additional Information

See documentation sections DB00244I, Terminating the MUF,  COMM EOJ (End MUF Processing) and article 280097 - Disconnecting multiple CICS regions when recycling a MUF