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....