Re: This is a software design question - ILE related

At 06:07 PM 7/31/00 -0700, you wrote:

In a 24/7 environment, there is no "perfect" way to resize a 
*DTAQ.  However there is a TAA Tool that will do what you want, however it 
does require quiescence to a certain degree.

See:

http://www.taatool.com/document/L_rpldtaq.htm

Al


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



+--------------------------------------------------+
| Please do not send private mail to this address. |
| Private mail should go to barsa@ibm.net.         |
+--------------------------------------------------+

Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.  
400 > 390

Phone:          914-251-1234
Fax:            914-251-9406
http://www.barsaconsulting.com
http://www.taatool.com

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