JDE services die.

After nearly a full day of batch & online transaction processing we hit a problem where batch jobs start failing to submit then users are unable to login. A quick bounce of the services clears this problem.

As a result of this we now make sure we bounce the JDE services every night.

We have recently started to get this problem again even though we still bounce every night and have put it down to more user sessions connecting with more transactional load.

The problem appears to be the shared memory - IPC semaphores - at a unix level not releasing, as the count just increases throughout the day finally hitting 485 then JDE starts to die.

Obviously there is a limit here but does anyone know where it is set!?!

Our JDE.INI settings:

[JDEIPC]
ipcTrace=0
startIPCKeyValue=6000
maxNumberOfSemaphores=1000

The mixture of errors we get are:

IPC3100008 - lockSemaphore failed, index=8, errno=22: Invalid argument.

IPC3900002 - ipcGetResourceName lockMutex failed to lock.

IPC3200004 - unlockSemaphore failed, index=1, errno=22: Invalid argument.

IPC2100008 - getResource lockMutex failed to lock eIPCMutex ~~JDERes~.

putExternalQueue (kernel) failed for msg id 804.

Thanks.

aiuk,
while i am not familiar with unix, can't you turn on debug on your enterprise server and track down the ubs(s) that are causing, what appears to be, a memory leak ?
also, you are at a service pack level that should be upgraded (just ask JDE ! this is always their first response).
regards,
dave

I looked on the KG and found where the print job was not releasing some IPCs, fixed in 16.1_011 (SAR 5511580), SP17.1 (SAR 5456648) and SP 18. (SAR 5462571).

But, I'll bet you'll have to take something newer as those probably aren't available anymore.

Yeah we're kinda hitting that one alot at the moment about Service Pack release ... and yep we're in the process of testing SP20 using the multi foundation environment.
Thanks Guys!