|
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 <snip - from Chris Bipes> Well thousands of people having the same open data path that would be added to each program that is bound to the module is a waste of resources. But then if you do not have enough servers running to process all the data queue request, the system will fall behind. We use the data queue approach for similar type of request and have a quick time stamp check, if on the queue for more than xx seconds, start another server after completing the current request. If a server times out, we use 60 seconds, more that xx number of times, it ends. We use a data area to track how many are currently running, min number to be running and max number allowed. I prefer the data queue request idea. Never thought about it for zip code lookups. We also have other files that are widely used for lookup of values. Since I have to re-do our current zip code stuff, I am going to try the data queue server approach. Good luck and let me know what direction you go and how it works. <end snip> +--- | 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 +---
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.