There may be times when the Multi-User Facility will not come down when you issue a COMM OPTION=EOJ (normal shutdown).
There can be several reasons why this happens. Here are three of the most common reasons:
- 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.
You can request the MUF to end immediately with a COMM OPTION=CANCEL, 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.
- Existing online tasks are still attached in the MUF.
Online facilities such as CICS (using CA-Datacom option for CICS Services) and CA-Datacom Server Option 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 CA-Datacom CICS Services r2.6 or prior, you must close all (open) URTs in order to trigger the CICS region to release the attached MUF tasks. Terminating the CICS region will also release the attached tasks.
If you are running the newer CA-Datacom CICS Services r11, you will need to do a DBEC DISCONNECT to release the MUF tasks.
For CA-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.
- Other CA products are still attached in the MUF.
There are a growing number of products that either interface directly to the MUF (like CA-Sysview ) or use the MUF as a data repository (like CA-11 and CA-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.
If you have submitted the COMM OPTION=EOJ and the MUF has not ended, you can use the COMM OPTION=STATUS function to determine if there are in-use MUF tasks and which jobs are attached to those tasks. The COMM OPTION=STATUS command is described in the CA-Datacom/DB DBUTLTY Reference Guide. The output of this utility job will contain a short report showing the status of all tasks currently in the MUF, along with their current usage.
You can also issue the COMM STATUS as a console command and the task output will be returned as console messages. Optionally, these messages may also appear on the MUF job output.
In either case, the "status" output will tell you what tasks are currently attached to the MUF and if they are actively processing. It is these tasks that MUF has to complete before it will end successfully.
For clients running CA-Datacom r11.2 (r11 SP2), there are additional MUF Job Log messages explaining the MUF EOJ status. New Datacom messages DB00239I thru DB00244I will further assist you in determining the status of the MUF after an EOJ request has been accepted.
Review these messages in the CA-Datacom/DB Message Guide to familiarize yourself with what they offer. The DB00244I message, in particular, will tell you if the EOJ is delayed because active tasks exist in the MUF. The DB00244I message will list all active tasks.
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.