RE: This is a software design question - ILE related

Nathan M. Andelin wrote:

>If you create a "server" to return data through a 
>queue, you run into one challenge - you must 
>ensure the correct data is returned to the correct
>user.  If you use only two queues (request queue 
>+ response queue) you must somehow synchronize 
>the requesting procedure to only one concurrent job.

The answer to that is a keyed data queue.  You can use a generated "request
ID" as the key which will allow you to recover across IPL/job abend, etc. or
perhaps use the fully qualified job name (handles group jobs) of the
requester.  The requester reads entries off the "return" queue that match
its key.

I was intrigued at Chris' suggestion of a client/server model for this.  I
have been using a client/server model in cases where I need to enqueue
requests to a limited resource (like a communications line, the next invoice
number, etc.) but looking up the City from the Post code seemed to be a
simple CHAIN...  Then I thought some more.

A simple CHAIN can return only one record.  The data queue can return
multiples.
CHAIN must share working storage with the requester.  DQ does not have to.
CHAIN has no "extra" maintenance.  DQs must be deleted/re-created
periodically to reclaim storage.
CHAIN is readily understood by junior programmers.  DQs may not be.
CHAIN requires no separate job.  DQ does.

The beauty of wrapping this in a procedure is that you can readily model it
either way, run it for a week and compare results.  I honestly don't know
which path I'd use but I would advise you not to worry about enqueue/dequeue
overhead of the DQ method - it seems negligible.  In fact, if it's a
high-performance application, I might go with the DQ because there's one
more thing to help me tune performance (the server job's memory pool.)

Please let us know which path you choose and how it worked out for you.

Buck Calabro
Aptis; Albany, NY
"We are what we repeatedly do.
 Excellence, then, is not an act, but a habit." --Aristotle


Billing Concepts Corp., a NASDAQ Listed Company, Symbol: BILL
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---