UBE multi threaded queues

Hi everybody,

I am interested in seeing how people who are using V9.0 or 8.12 are managing their job queues. We currently have a dual threaded (ie one queue in which 2 jobs can run simultaneously) queue which is fine for Xe/coexistence but when we are live on 8.12 we will have much more UBEs running and will need to decide how work management is implemented. I think the main options are as follows...

Do you recommend

one single threaded queue for each application area (such as AR, GL, distribution etc). The issue with this is that there is a lot of version configuration/maintenance required to implement. You can do this with different link user profiles which causes issues with connection pooling being less efficient.

one multi-threaded queue (perhaps 5 jobs at a time) for all default UBE's. Those that need to be single threaded (such as overnight batch) could be run in a seperate queue. This is my preferred option but the issue is identifying UBE's that have to run single threaded (the assumption is that during the daytime operations there won't be many of these).

any thoughts...?

thanks,

Rich

Rich,

Most of my clients have implemented the default multi-threaded queue and then placed UBEs that require single threading into departmental single thread queues.

-Ethan Bearman

Attached is an old Xe document; perhaps you could find another one, more up to date than it, on the Knowledge Garden

We have done the same. We have a multi-threaded queue default and then we separate out the single threaded jobs into queues like PAYROLL, POSTING, and LONGRUN.

thanks Adrian, that is a very nice document, I shall see if I can find an updated version on the KG, although I shall probably end up logging a call as I have already tried numerous searches.
I suspect that these UBEs are not radically different in 8.12 / 9.0 anyway.
Rich
PS If I find a newer one I'll post it on the list.

There are two options you can implement. The first is the standard multi-threaded queue as default, and then map certain jobs to a single-threaded queue.

This works if, say, you never run more than a half dozen jobs in parallel - and you do not mind a long GL Post job holding up, say, a pickslip or something similar. You can adapt this by moving certain jobs to yet another, specific single-threaded queue (pickslips for example) - but be aware of what other jobs could be running in parallel in the other single-threaded queue.

But what about very large customers - those that have tens of thousands of UBE processes running in a day - or even hundreds of thousands ? What about those customers that have multiple application servers to run their processing load ?

For those customers, mapping UBE's by updating versions is not ideal. Instead, those customers need some sort of automated system in place that will check to see what jobs are running, and then take jobs based on priority and process them.

I created a "queue daemon" about 10 years ago for a very large customer that literally had more than 100,000 batch processes running per day on a large unix system with thousands of concurrent users running hundreds of thousands of individual orders. In this situation, I wrote a program that would run on each of the individual application servers, checking the F986110 table looking for new jobs. When a job entered the table, then the first available application server would take ownership of that job, then - based on a variety of checks, would compare the job name, version name, user ID submitting the job etc against a custom "job priority" table. Then with the type of job (approximately 9 different types of processing could be then assigned to the job), it checked running jobs in the F986110 before then updating the job and processing it.

With a number of checks in the system, this process meant that a large number of separate application servers could be running - and jobs could be running single threaded, multi threaded or even single-threaded by process/version/branch etc etc ! That way, certain "single threaded jobs" could actually run in a multi-threaded manner without necessarily impacting other jobs.

I know other companies have created similar "queue daemons" - I've seen at least one similar setup written for an AS/400 out there. What seems to be occurring is that there is more of a need for these types of queue daemons as customers move to E1 away from Xe - whether it is based on the functionality requirements from the new version or whatever.

Hi Jon,
that is a good idea, I seem to remember you mentioning it one of you past missives. I think it would be relatively easy to cobble together some CL to reallocate jobs based on some logic and the F986110 file. That depends upon knowing which ones can single thread and which ones can't. Fortunately I've got confirmation from Oracle that The doc #626133.1 is applicable for 8.12 as the list for UBE are designed to run in single threaded mode. I'll upload a copy of it so people can have it. It looks remarkably similar to the Xe document, but with the Xe bit taken out.
Thanks to everyone who responded ,
Rich