JDE scheduler

jacobw123

Well Known Member
We are running into an issue where when we run back to back versions of R3483 with Parallel processing with 6 subsystems assigned. The first job appears to process normally however as soon as the first subsystem becomes available the next scheduled parallel processing version starts and eventually errors out. When these parallel versions are executed by themselves they run without error.
Has anyone had experience running multiple parallel processing versions on a scheduler? Any suggestions on how to accomplish running a series of parallel processing jobs sequencially with JDE Xe?
Any help is appreciated.
Jacob
 
Hi Jacob,
You may want to assign a Single Threaded Queue to the versions running now in the default (blank) Multi Threaded Queue (the thing you name 'parallel processing').
It may sound obvious, but, if you do not have the Single TQ available, you may need to create it
grin.gif
 
Andrian, Thanks so much for replying. However, what I mean by 'parallel processing' is something specific to MRP where you specify in the processing option on the Parallel tab the number of subsystems to use for the process.
Thanks again,
Jacob
 
I see Jacob,

But my solution still may solve your issue with subsystems (they are jobs, too) running "one on top of the other".
The single threaded queue helped us so much I just created a second one, only for the new module we just went live with, Transportation Management. This way we avoid having too many jobs waiting for this bottleneck to clear.

Now please repeat A-dri-an. There you are.
 
But if they will run back to back on a single threated Q wat is the gain of running Parallel?
 
jacob

You obviously need some help understanding what "Parallel MRP" means.

First of all it doesn't mean you can run 2 versions of MRP at the same time. That will never work.

What Parallel MRP does (and I helped create it when I was at JDE) is that it creates a number of threads that are configurable and utilizes the subsystem queue. Then for each "level" of the BOM - a "master" job spawns subsystem tasks for each item at that level. As the tasks start to finish, the subsystem threads go to sleep, and when the subsystem table is empty, a thread promotes itself to become the next levels' "master" job, and spawns additional tasks.

Now, if you run your R3483 in a single threaded UBE queue, it won't affect the subsystem jobs - which utilize a different system. I think thats what you needed to do, and have seen results, since Parallel MRP is still operating in the multithreaded subsystem queue. You still need to go through and evaluate how many threads to run - plus, I'm sure theres lots of DBA work to make sure the threads aren't stepping on one another as they process.

Parallel MRP is a fantastic technology - its a differentiator between JDE and every other product out there. In theory, given enough horsepower, Parallel MRP will always be able to dramatically improve performance of a single threaded MRP process - PROVIDING the BOM is very wide at the different levels. It the BOM isn't wide, but is very deep - then Parallel MRP can't perform as well as single MRP.

Lastly, be careful of the messages. You'll likely see a dramatic difference in messages between single threaded and parallel - as single threaded has the ability to "summarize" for certain items. Parallel, given its nature, has difficulty doing that.

Theres a number of articles on Parallel MRP I wrote on here in the mists of time, far far long ago....
 
Jon, you obviously know your stuff and know what you are talking about and I appreciate your response very much.
I understand you can’t run two versions at a time. That is Concurrent Processing available starting 8.9. We are on Xe.
What raised my question is a document on the knowledge garden stating that you have to create a multi-threaded JOBQ if you want to run parallel processing. It doesn’t mention you have to run it on a multi-threaded JOBQ. And hence my confusion. Do you have to submit a parallel processing job to a single-threaded or multi-threaded JOBQ?
Thanks again,
Jacob
 
Back
Top