Execution order of waiting UBE jobs

[jolly]

Hi All,

On an Xe sp24 Windows enterprise server (oracle DB on unix db server), I have a UBE that rapidly submits about 80 jobs to a single threaded queue. The waiting jobs then execute in a seemingly random order but I need them to execute in the submitted (i.e. job number) order. It seems that the UBE kernel is sequencing by time submitted only - if I delay 2 secs between each job submission they then execute in the sequence I intended.

This is rubbish! There's no way this sort of cr#p would happen with iSeries servers!

Can't find anything about this on the KG - is this a known shortcoming or is there a way to get around this?

Cheers
JohnO

 

[Larry_Jones]

"This is rubbish! There's no way this sort of cr#p would happen with iSeries servers"

I'm sure you're right John. Most iSeries servers would have difficulty reaching that sub-second processing time.

Just kidding - I couldn't resist!

 

[BOster]

I would submit to you that if you are relying on a single threaded queue and the internal implementation of the queue to control execution flow for your process then you need to rethink your design. Of course if it is a pristine UBE then I guess you are stuck.

 

[brother_of_karamazov]

[ QUOTE ]
Hi All,

On an Xe sp24 Windows enterprise server (oracle DB on unix db server), I have a UBE that rapidly submits about 80 jobs to a single threaded queue. The waiting jobs then execute in a seemingly random order but I need them to execute in the submitted (i.e. job number) order. It seems that the UBE kernel is sequencing by time submitted only - if I delay 2 secs between each job submission they then execute in the sequence I intended.

This is rubbish! There's no way this sort of cr#p would happen with iSeries servers!

Can't find anything about this on the KG - is this a known shortcoming or is there a way to get around this?

Cheers
JohnO

[/ QUOTE ]

I would guess that E1 uses JCSBTIME to order submitted UBE's based on submission time. This field reads as hhmmss giving it a one second precision, which sucks. JD Edwards could have done better with date and time in E1 by using a group of trained monkeys with stopwatches and day timers.

Does the iSeries do this any differently?

 

[jolly]

[ QUOTE ]
[ QUOTE ]
Hi All,

On an Xe sp24 Windows enterprise server (oracle DB on unix db server), I have a UBE that rapidly submits about 80 jobs to a single threaded queue. The waiting jobs then execute in a seemingly random order but I need them to execute in the submitted (i.e. job number) order. It seems that the UBE kernel is sequencing by time submitted only - if I delay 2 secs between each job submission they then execute in the sequence I intended.

This is rubbish! There's no way this sort of cr#p would happen with iSeries servers!

Can't find anything about this on the KG - is this a known shortcoming or is there a way to get around this?

Cheers
JohnO

[/ QUOTE ]

I would guess that E1 uses JCSBTIME to order submitted UBE's based on submission time. This field reads as hhmmss giving it a one second precision, which sucks. JD Edwards could have done better with date and time in E1 by using a group of trained monkeys with stopwatches and day timers.

Does the iSeries do this any differently?

[/ QUOTE ]

Hi BoK,

The iSeries queue subsystem will always execute jobs in priority order and then job number order within priority.

Cheers,
JohnO

 

[jolly]

Hi Brian,

[ QUOTE ]
I would submit to you

[/ QUOTE ]

Just make sure if you "submit" things to me you space it out at 2 second intervals so I don't get your messages out of order

[ QUOTE ]
that if you are relying on a single threaded queue and the internal implementation of the queue to control execution flow for your process then you need to rethink your design.

[/ QUOTE ]

If the queue implementation is not FIFO then you are unarguably correct!

But to create a job control mechanism, call it a 'queue', that is not FIFO? The word that comes to mind is 'muppets'.

So I have been forced to "rethink my design", having to submit each job with > 1 second delay - a kludge I would prefer to avoid.

Cheers,
JohnO

 

[jolly]

[ QUOTE ]
"This is rubbish! There's no way this sort of cr#p would happen with iSeries servers"

I'm sure you're right John. Most iSeries servers would have difficulty reaching that sub-second processing time.

Just kidding - I couldn't resist!

[/ QUOTE ]

Heh! Well, Larry, I do remember when iSeries boxes cost several years' salary, required an industrial power supply and air conditioning, a re-inforced load bearing floor and were slower than a wet week.

None of the above applies nowdays though! :-D

 

[brother_of_karamazov]

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
Hi All,

On an Xe sp24 Windows enterprise server (oracle DB on unix db server), I have a UBE that rapidly submits about 80 jobs to a single threaded queue. The waiting jobs then execute in a seemingly random order but I need them to execute in the submitted (i.e. job number) order. It seems that the UBE kernel is sequencing by time submitted only - if I delay 2 secs between each job submission they then execute in the sequence I intended.

This is rubbish! There's no way this sort of cr#p would happen with iSeries servers!

Can't find anything about this on the KG - is this a known shortcoming or is there a way to get around this?

Cheers
JohnO

[/ QUOTE ]

I would guess that E1 uses JCSBTIME to order submitted UBE's based on submission time. This field reads as hhmmss giving it a one second precision, which sucks. JD Edwards could have done better with date and time in E1 by using a group of trained monkeys with stopwatches and day timers.

Does the iSeries do this any differently?

[/ QUOTE ]

Hi BoK,

The iSeries queue subsystem will always execute jobs in priority order and then job number order within priority.

Cheers,
JohnO

[/ QUOTE ]

Hmmmm, a nice feature indeed. I can see how this would be nice on non-iSeries.

A random thought:

- What about multiple enterprise servers with shared server maps? How do we keep the job numbers straight? They would share a WSJ, have separate queue kernels (which decide what to run, when) and have separate job # lists. I can see trouble with running jobs by job # in this (common) scenario.

 

[jolly]

[ QUOTE ]

Hmmmm, a nice feature indeed. I can see how this would be nice on non-iSeries.

A random thought:

- What about multiple enterprise servers with shared server maps? How do we keep the job numbers straight? They would share a WSJ, have separate queue kernels (which decide what to run, when) and have separate job # lists. I can see trouble with running jobs by job # in this (common) scenario.

[/ QUOTE ]

I'd just avoid that scenario, myself. Sounds awful. No worse that the time based sequencing though.

 

[brother_of_karamazov]

[ QUOTE ]
[ QUOTE ]

Hmmmm, a nice feature indeed. I can see how this would be nice on non-iSeries.

A random thought:

- What about multiple enterprise servers with shared server maps? How do we keep the job numbers straight? They would share a WSJ, have separate queue kernels (which decide what to run, when) and have separate job # lists. I can see trouble with running jobs by job # in this (common) scenario.

[/ QUOTE ]

I'd just avoid that scenario, myself. Sounds awful. No worse that the time based sequencing though.

[/ QUOTE ]

I was brainstorming scenarios that would be possible and may have forced developers to code like they did. If a possible configuration would preclude using job # I would think they would have to use submitted time.

 

[gregglarkin]

[ QUOTE ]
Hi All,

On an Xe sp24 Windows enterprise server (oracle DB on unix db server), I have a UBE that rapidly submits about 80 jobs to a single threaded queue. The waiting jobs then execute in a seemingly random order but I need them to execute in the submitted (i.e. job number) order. It seems that the UBE kernel is sequencing by time submitted only - if I delay 2 secs between each job submission they then execute in the sequence I intended.

This is rubbish! There's no way this sort of cr#p would happen with iSeries servers!

Can't find anything about this on the KG - is this a known shortcoming or is there a way to get around this?

Cheers
JohnO

[/ QUOTE ]

Jolly JohnO

If you want a boatload of jobs to execute in a specific order, then you need to add in a sophisticated job scheduler. In my last job, I used Tidal Scheduler. it didn't matter if I was submitting to a multi-threaded or single-threaded queue, I could control the exact sequence of when jobs ran.

- gregg

 

[altquark]

You could always create a "master job" - a UBE that ran a report interconnect to the sub-jobs. Best to make sure you have a wait time between the asynchronous calls though.

Queues are not native on non-AS/400 equipment - hence the issues with trying to "create" a queue-type system, like JDE. The AS/400 has queues and subsystems as standard - Unix and windows uses PID's and Priority of PID's - there is no queue system. So, things can slip through the cracks when you try and create a "queue-like" environment like JDE Batch services.

However, the queues are improving. Expect a total update on the queue architecture in JDE for TR9.1......in the meantime, use those SLEEP statements !!!!

 

[BOster]

[ QUOTE ]
You could always create a "master job" - a UBE that ran a report interconnect to the sub-jobs. Best to make sure you have a wait time between the asynchronous calls though.

<snip>

......in the meantime, use those SLEEP statements !!!!

[/ QUOTE ]

It sounds like he all ready is using a master ube. My whole point was if you need the called UBEs to execute in a specific order then don't submit them asynchronously. Forget the sleep statement and just execute them synchronously, then you can run in any queue, multi-threaded or single threaded.

 

[Segfault]

You sure you're on SP24? I'm pretty sure this was fixed around sp23V1. On sp24, turning on jdequeue logging shows they select by jobnbr ascending as part of the SQL to decide to run jobs.

 

[jolly]

I avoid synchronously launching large numbers of jobs if I can as it is all running in one process and any issues with memory leaks accumulate whereas asynchronous jobs get cleaned up after each job. Also if any one UBE for some reason blows up the who chain goes down. I want to keep everything nice and clean and distinct.

Also, when running all in one process the log fils gets all squashed into one big file. Or is that just with subsystems?

But really, how hard is it to implement a FIFO queue? That's comp.sci.101 at it's most basic.

 

[jolly]

Well spotted, Seg. This particular site is SP23!

Just waiting for them to get going with an E9 upgrade and here's one more reason.

Cheers
JohnO