× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi, Simon:

Thanks for the response. More research is obviously needed, because (just 
as obviously) I am one of those who doesn't know exactly how things work 
here.

The programs involved are part of an ERP package that we have massively 
customized (no support or updates). A long time ago, somebody figured out 
that the order in which jobs ran that fed the data queue was predictable, 
and we began to depend on the job queue for sequencing other, related, 
jobs as well. I suspect this has worked only because the data queue has 
almost always been quick enough not to be "overrun" by the next job. For 
years, there have been rare, undiagnosed, record locks that stopped jobs 
in this job queue.

I am wondering what the effect on efficiency would be if I eliminated the 
data queue altogether, since its asynchronous nature may actually be a 
problem, not a benefit.

BTW, we have other data queues that work "as designed," based on the crash 
course offered by this thread. It's just the one setup that has me 
scratching where my hair used to be.

Darrell

Darrell A. Martin  -  754-2187
Manager, Computer Operations
dmartin@xxxxxxxxxxxxx

Simon Coulter wrote on 07/11/2006 12:15:34 AM:

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





This e-mail, including attachments, may contain information that is 
confidential and/or proprietary, and may only be used by the person to 
whom this email is addressed. If the recipient of this e-mail is not the 
intended recipient or an authorized agent, the reader is hereby notified 
that any dissemination, distribution, or copying of this e-mail is 
prohibited. If this e-mail has been delivered to you in error, please 
notify the sender by replying to this message and deleting this e-mail 
immediately.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.