UBEs that go into Mutex Wait (MTXW) - why?


Legendary Poster

Knocking on wood, hoping one of you guys have faced (and resolved) a Mutex Wait issue with UBEs on the iSeries...

Here's what happens....
- Heavily Enhanced copy of R42565 (Invoice)
* I mean REALLY Enhanced (it becomes the biggest UBE on the system)
- Dozens of the Enhanced UBE get submitted to QBatch
- They start going into MTXW
* I am told the MTXW is targeting the Metadata Kernel
- The jobs eventually end normal - with nothing in their logs to describe the 'why'

We are, currently, trying to recreate the issue in our Development Environment - so we can catch logs / timings to see where the issue occurs.

I'm hoping that a few of you have breezed through the issue before - and can offer some suggestions.

Mutex wait is the AS400s way of protecting the contents of shared memory that is currently in use. (this could be linked to the E1 system getting the specs for your enhanced or large specced UBE - see last note)
So no other job can use that memory until it's free. (mutex is like a ticket to the memory, whoever has that mutex can update the memory)

One thing I always try and do is perform select statements with open + close to free up memory.
So is the custom code not very effecient?

This gives some reasons as to why it might happen but not a fix as such.

Is the R42565 running on a multi threaded queue or the same queue as all your other jobs?
Can you split them out onto different threads?

Could be the threads (or number of threads or the semaphores for those threads)) spawned by that job (so asynch BSFN calls maybe?) can go into this mutex state as they compete or run out of resource. Or just WAIT for some to be become available.



Then there is this for E1 related stuff...?


And this for the JDE.INi file to control such things as the number of semaphores

“maxNumberOfSemaphores”, 100)
jdeipc\ipcinit.c(240) This entry is used to determine the maximum number of semaphore resources that the OneWorld instance will use.
When this value is reached, no more semaphore resources can be created. On NT, two semaphore resources are used to implement each message queue. On UNIX, one semaphore resource is used to implement a mutex resource, and one semaphore resource is used to implement a SWMR lock. On AS400, one semaphore resource is used to implement a SWMR lock.

......and finally, this gem
At one time, the JDEdwards OneWorld UBE applications used mutexes to
serialize access to certain spec files in the IFS file system.

Which ties into the .ddb deletion mentioned in the link above. Especially if your specs are now larger than before
Last edited:
As always, John - thank you for the excellent input!

I'll open a ticket with the Borgacle - and see if we can get some 'current-definitive' answers.

As always, I'll update with my findings - when concluded. Anyone else with suggestions - feel free to chime in!

I'm of the belief that there is a "Too Big for the Meta Data Kernel" type UBE... and it's been hit....

- now we just have to get 'someone' to tell us what that limit really is....

I don't think you'll find a true limit. The more meta data (specs), the longer the process will take to read and convert. Can you strip down anything in the report? Remove unused sections? Replace long ER with a BSFN?