× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Simon

I am in complete agreement with you in this matter. I'm glad you tackled it. Allow me to mention a couple scenarios in common use that might further bolster your points and help us in our thinking about queue usage of any kind.

1. IBM's own MQ product is a guaranteed delivery mechanism that uses various kinds of queues - major financial institutions use it all the time. Simple program calls can't handle this kind of thing. 2. The basic inner mechanism of Windows is message queueing - VB and C and Delphi and whatever insulate us from that mechanism, but to get real control of certain things, you SNDMSG to Windows and other processes asynchronously pick them up. Different from DTAQs in several ways but similar in principle. 3. What you have described repeatedly and well is what I understand to be the contract model of development - a "user" and a "service" contract to behave certain ways, such as that the user will validate data and deliver it to the service in the form the service expects to see, then the service will process it and return certain data as agreed upon. I think we do this implicitly, but there is a framework in which this is more defined, IIRC. Even a development environment called Eiffel, I think. 4. RPC - remote program calls, for some reason, creep into my thinking here. Or call it asynchronous processing or think about MQ. 5. As to robust production code that depends on this kind of thing, it is well known that much of the iSeries code is using user indexes and user queues (an even lower-level variant of a data queue). I guess IBM has made a mistake depending on these "unreliable" things. <vbg>

Am I off base here, Simon, or does this go along with your thoughts?

Regards
Vern

At 08:28 AM 7/9/2006, you wrote:

-snip - no need to repeat all this!


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.