|
On 11/07/2006, at 2:06 AM, Darrell A Martin wrote:
All of the instances of program C that process through this data queue are submitted to the same single-threaded job queue. Am I wrong in wonderingabout the point of doing it this way? The question arises because we occasionally bottleneck at the job queue, but nobody wants to mess with the structure of the processing (12 year old code and configuration, in this area).
On the face of what you describe this is dumb. The SBMJOB imposes a probably unnecessary overhead and bottleneck (due to the single stream job queue but also the batch job start overhead). The obvious approach is for the interactive jobs (running program A) to send to the data queue directly.
You'd need to look at program C to determine if it does anything useful before sending the entry to the queue for program D to process. It is highly likely that any work done by C could be moved to A with little impact.
Even if C is doing work better served by being in batch you could avoid the SBMJOB overhead by having program A send the data to a new data queue processed by program C and then program C could forward its result to the data queue for program D to process. Or you could have program C call program D and remove the second queue. Or you could have program D call program C and avoid the SBMJOB and the proposed first queue.
Certainly sounds like the process could be improved--never mind the obvious signs of no-one knowing how anything actually works.
Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
