Automatically moving queued jobs

johndanter

Legendary Poster
Hi List,

I have a tricky one in that every now and again our warehouse jobs for R46171 are queued behind one another.
We currently have 2 warehouses in E1 but they all use the same versions of R46171. (We plan to have more E1 sites soon)

I know R46171 etc should be running in a single threaded queue to avoid contention etc and that's understood and fine. But I can't see any reason why 2 warehouses could run on their own queue independently of one another.

Now I have proposed a new queue and separate versions, but this goes against our global model of low numbers of E1 UBE versions/menus. We rely on row security to pick the correct records.

So.........

I'm about to propose a different solution:-

* In WSJ there is a row Exit to enable to switch the job queue if the job is at W status.

* Create a spare 'standby queue'

* Leave the versions as they are.

* Develop a UBE that checks F986110 for jobs queued for a defined time and calls the same logic. (it uses BSFN B9861106 ChangeJobQueue)
Rely on the USER ID to get the branch/warehouse of the user who submitted the queued job and move it to the spare standby queue if it's been waiting a long time.
This will move the queued jobs of a specific warehouse B off the busy queue onto the standby queue.

* If all is fine and jobs are not queued, then the system behaves as normal.

Can anyone think of any issues with this? I am on Unix btw, not the 400

Or....Is there another way to skin this cat?

Thanks

John
 

johndanter

Legendary Poster
We have a zero mod policy so sometimes I'm a little stuck on my suggestions.

One I have managed to get working is a slight mod to P98305W form D. A worktable on OBNM VERS and MCU checks the submitted job for a match and then moves the job to the queue specified.

Only way this was entertained is I got it down to 2 lines of code. Call my new screen, come back and click cancel.

I'll suggest a trigger as that gets all submissions, not just user ones
 
Top