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