Sure, we have multiple batch subsystems and we do have a lot of jobs that default to the same job queue. Multiple subsystems can help, but it’s more of a question of job queue management. Any particular job that is known to run long should be submitted to it’s own job queue. Our current iSeries is 40 times faster than the previous model, so job queue management is not really a worry for us anymore. Previously, any job that ran for over 30 minutes would be forced to run at night so that it doesn’t effect day time performance. Very quck running jobs (one minute or less) we have running from a multi-threaded job queue (max. active more than 1). Everything else you may need to group by application or division (GL, Inventory, Sales, etc.).
I’m not sure if Batman47 is fully answering the question here..
A “job queue” belongs to one subsystem.
You cannot have multiple susbsystems that use the same job queue.
You can have multiple subystems that use job queues with the same name, but those job queues would have do exist in separate libraries.
You can have multiple job queues defined for a subsystem.
As far as “jobs normal processing” goes, you have to consider what the jobs are.
As batman47 says, jobs that run for long times should be submitted in a separate job queue. In situations where two jobs running simultaneously could result in problems (like record locks, etc) you should consider a singly-threaded job queue. Considering the speed of the current systems, you can probably get by qith using the QBATCH subsystem for everything, but there are situations when having multiple batch subsystems makes sense.