Re: This is a software design question - ILE related

["James W. Kilgore" <eMail@xxxxxxxxxxxxxxxxxxx>]

Hi,

Just to drop in my 2 cents, don't queues just keep growing, eating up
disk, even if you remove the entries upon read?  Or has IBM come up with
an RGZDTAQ command or something like that?

The reason I ask is, if you choose the data queues method, how do you
manage the delete/recreate in order to reclaim disk storage in a 24/7
shop?

If zip codes are the example, and this would not hold true for other
files, there are approx. 42,000 zip codes in the US, with the longest
city name being 21 char (last time I looked).  So this places the file
into the category of a good use of setting object access and putting the
whole file in memory.

As far as the multiple places for the need of a getZipcode procedure,
IMHO, make that a /COPY member and include it in your getCustomer,
getVendor, etc.


"Nathan M. Andelin" wrote:
> 
> 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
+---