• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

MUTEX wait


Active Member
We are experiencing a probem with out UBE's. It seems that some UBE's are causing MUTEX holds on all other jobs running in the system. Has any one had similar issues?

Xe Update 6 AS/400 V5R2 SP23 Citrix


Active Member
We experienced same thing which is due to the AS400 update package server deployment but not the regular UBE.


Todd Rorie

Active Member
Had this issue today as a matter of fact. Stop services on your 400 and
delete DDDICT, DDTEXT, and GLBLTBLs. (WRKLNK OBJ('/pathcode/specfile')Then
start services back. That should do it.

S. Todd Rorie
Technical Manager
Enterprise Business Systems
Enterprise Services
Information Technology Services
Metro Nashville Government
(615) 880-1618


From: gjhanson [mailto:gary_hanson@hardinge.com]
Sent: Thursday, August 12, 2004 3:20 PM
To: jdelistsubscribers@jdelist.com
Subject: MUTEX wait

We are experiencing a probem with out UBE's. It seems that some UBE's are
causing MUTEX holds on all other jobs running in the system. Has any one had
similar issues?

Xe Update 6 AS/400 V5R2 SP23 Citrix


The entire <http://www.jdelist.com/ubb/showflat.php?Cat=&Board=> JDELIST
thread is available for viewing.

This is the JDELIST EnterpriseOne Mailing List.
The instructions on how to unsubscribe from any JDELIST mailing list are
available here <http://www.jdelist.com/unsubscr.shtml> .
JDELIST is not affiliated with JDEdwards(r).


Active Member
Is the status "SEMW" - SEMAPHORE WAIT for any jobs in the AS400 Subsystem? Previously some programmers sent Server Packages during the day, and these packages would stop the UBEs from processing (Waiting). The solution is to stop them from sending packages - jobs might go into a SEMW status while deploying a server package. Another reason might be that the Files Backup or some other Locking process is running.
Hope this helps.


Active Member
We have established a theory and did some testing with the following results. If I submit a job with simple data selection, say work orders, of over 12 requests the job on the 400 is in a RUN status but on submitted jobs it is in a Waiting status. It will stay like this all day long. Along with that any other job in the system goes into a MUTEX wait or Semaphore wait and nothing runs.
If I submit the same job with 12 or less data selection requests the job runs every time in less than 1 minute.
Anyone have anything to add to this?


Are you running Mimix or some type of replication of your IFS? Generally, that would put you in a LCKW status, but I have seen MTXW a couple of times.
If that is not the case, then are you getting any output in your logs on the AS400 or in QEZdebug or joblog that might help shed some light?

Jennifer Sharma, Sr. Technical Specialist
AELLIUS Professional Research & Consulting, LLC


VIP Member
Re: RE: MUTEX wait

Actually you don't even need to delete the DD files. Just hold your job queues, cancel the jobs in MTXW, then end/restart services.


Active Member
What we have finally found is that spec corruption was causing this problem. We found it almost always in jobs that have had some sort of version specification override in the manner of Event rules or Forms.


Active Member
Re: RE: MUTEX wait

Hi Jean, just want to share with you. We have tried this before :Dand all pending jobs will be deleted. Users need to resubmit their jobs again. Alternatively, you shld look for JDE service with Status SEMW, put option 5, option 19 (work with mutexes, if active) and then end one of the job. Those pending and active jobs in Mutex status will continue processing.


I have the same problem.
I have V5R1 with oneworld XE SP23_J1
verry often i see one job in RUN, an oter in SEMW and all the other in MTXW, the Call object kernel too.
It stay like that for a minute and that it start run again.
It look like this:

Have anybody idea on how to fix this?


VIP Member
FWIW we get this issue occasionally also. We have tracked it back to an IFS lock on the spec files. (we normally are running 10-30 concurrent UBE's). In our case if we just let it ride the locks eventually resolve themselves. You can mitigate the problem by ensuring that the same UBE is not running multiple times, assuming this is possible, in our case it is not.

The best advice we have is to make sure that you are up to date on all IFS related PTF's.

Hope this helps.

Tom Davidson


Well Known Member
Mutex wait on UBE and Call object kernel is good sign of the package deployment. This means that the resources are being used by package deployment. As soon as deployment finishes these kernel automatically get out from Mutex wait status