Re: This is a software design question - ILE related

[Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx>]

Actually we use keyed job queues and the sender sends with a key value of blank 
then waits with a key value of its job number.  The server reads key value 
blank only, and parses the job number out of a standard header then post the 
response with the parsed job number as the key.

It works for me...(Just have to clean out old job responses once in a while.)

Christopher K. Bipes            Mailto:chrisb@cross-check.com
Senior Programmer/Analyst    Http://www.cross-check.com
CrossCheck, Inc.                707 586-0551 x 1102
6119 State Farm Drive       707 586-1884  FAX
Rohnert Park, CA  94928

----- Original Message ----- 
From: "Nathan M. Andelin" <nathanma@haaga.com>
To: <MIDRANGE-L@midrange.com>
Sent: Monday, July 31, 2000 5:02 PM
Subject: RE: This is a software design question - ILE related


Chris,

Thanks for your perspective.  I've spent a good part of the day reviewing
IBM manuals dealing with ILE and Data Management and have not come to any
conclusion, yet.

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.
You don't want to run into a case where one job puts a request on a queue
and a different job retrieves the response.

One technique I've used in the past is to have a single request queue for
the server, but a unique response queue for each client.  When a client
makes a request, it also tells the server which queue to respond to.

But, then I begin to wonder whether having all those separate queues and
calls to QSNDDTAQ and QRCVDTAQ is any more efficient than multiple open data
paths managed by the OS.

Maybe the new "Thread" support in V4R4 ILE RPG could take care of the
synchronization problem?

Any more insights you can offer?

Thanks.

Nathan M. Andelin

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