F986110 Duplicate Key

We use Tivoli Maestro for scheduling and occasionally get a duplicate key error on inserts into the F986110 - Job Control Status Master. This is random in that they never happen at the same time and only started happening since moving to 8.95.O1 last summer.

I opened a call with Oracle but they couldn't help because a) we were using Maestro and b) I couldn't generate a debug file by duplicating the problem using the E1 Scheduler.

These 'collisions' occur about 2/3 times a day/night but I can't think how to go about resolving the problem.

Anyone got any ideas?

We had this issue at my old company. We were on XE and using ROBOT scheduler on the AS/400. We only got it 2-3 times a day too until we started implementing more and more companies, then it became a really big issue because it happened more and more.

A long story short, we were able to convince JDE somehow that the issue was on their side and they eventually gave us a POC to update one of the kernels, the UBE kernel I would imagine, so that it changed the way it read and updated the F986111 so no two jobs would get the same job number from there.

That was back in either SP 21 or an early release of SP23. Sounds like either they never made the change for the Unix platform or they broke their code again. If I find the call number or SAR we had for the issue I'll send it to you.

It would be very useful if you can locate that SAR.

Many thanks for replying.

We are interested in the ESU too.

We are getting the same issue - All UBEs are submitted from JDE (from other UBEs)

If two UBEs are submitted within 1 second of each other, the F986111 fetch gets the same number and hence only one F986110 record is created.

(We see a F986110 insert failure in the UBE log of the calling UBE)

It is happening on standard UBEs (R09110Z, R03B5005) and custom ones.

it happens with Standard Call UBE commands - and BSFNs using jdeLaunchUBEEx API calls.

We are on 8.10, tools 8.97.1.2

We are trying to get Oracle to accept this as an issue - quetioning why no lock is placed on F986111 when batch number is fetched.