Re: QRCVDTAQ

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

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!