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



We use a static keyed queue here.  The key is the 6 digit job number.  The
batch server program reads entries with a key value of '000000'.  The sender
ID, which is automatically sent when the data queue is created with sender
id = *yes, hold the return key to use.  One queue for input and output
simplifies management.  A nightly job that peeks at the messages in the
queue and deletes responses over x hours old.  (Hey interactive jobs crash
once in a while.)  We don't use the queues for loading sub files, more for
real time transaction processing where there are many files and steps
involved.  We also have several batch server jobs reading the input queue
and dynamically start more if a transaction sat for more than x seconds on
queue before the server job pulled it.

Like the idea of loading sub file thru queues.  Have to look at that
further.

Christopher K. Bipes      mailto:Chris.Bipes@Cross-Check.com
Operations & Network Mgr  mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.          http://www.cross-check.com
6119 State Farm Drive     Phone: 707 586-0551 x 1102
Rohnert Park CA  94928    Fax: 707 586-1884


-----Original Message-----
From: Larry Bolhuis [mailto:lbolhuis@arbsol.com]
Sent: Thursday, June 13, 2002 4:25 AM
To: midrange-l@midrange.com
Subject: Re: Data Queue


We have used similar tactics to move data between interactive and batch
jobs. In our case the interactive job creates a unique queue, and sends a
request for data along with the unique queue name to a batch process on the
input queue for the batch process. The batch process does it's thing and
begins returning entries in the queue. The interactive process reads up to a
subfile of records and displays them to the user. When the user presses page
down the program simply reads another pagefull from the queue. Since the
background process was still running and filling the queue while the user
reviewed the first screen the second and subsequent screens are essentially
instantaneous. Should the user enter different search criteria (thus
requiring the batch job to stop and change course) it simply deletes the old
queue and creates a new one. The coolest part was that because we couldn't
know how many records the batch job would return and didn't want to wait to
find out in case it was *waytoomany we just deleted the queue. There are no
locks on queues even when reading or writing them! The batch job then gets a
nice clean little error on it's next attempted write which we coded to mean
'Quit this request and move on'. The whole thing avoids the 'Interactive
Tax' quite nicely and a single batch job can service many interactive users.
Overheard creating and deleting queues has never been an issue.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.