Re: QRCVDTAQ

On 7/9/06, Vernon Hamberg <vhamberg@xxxxxxxxxxx> wrote:

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.

come on.  networking is different story. I have not worked on MQ
applications but I have written a number of dtaq applications. I wrote
a fax system that used a lot of data queues between the PC that had a
fax board and the as400 that had users that wanted to fax stuff. It
started as something that seemed doable, but it got very complicated.

The fundamental problem with data queues is your client code does not
get a definitive return code from the server.

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.

That is a good example.  Learning the message loop is also the hardest
skill to master in windows programming. C++ Windows programs would
lock up a lot because the program would fail to pump messages like it
was supposed to. VB was a great success partly because it freed the
programmer from having to deal with the message queue.

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.

that seems fundamentally flawed to me. The server has to validate the
transaction before it is applied to the database. If the client does
validation also that is a duplication of work.

4. RPC - remote program calls, for some reason, creep into my
thinking here. Or call it asynchronous processing or think about MQ.

Can RPC throw exceptions back to the remote caller? If it can it is
superior to 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>

Hah! i5/OS had to run on a 1 CPW B10. Queues and batch processing are
efficient. That is their advantage. The downside is you dare not mess
with the system once you have it working. IBM for example cannot get
the interactive subsystem to support multi threading. The spawn and
SBMJOB APIs are also very slow.  Is that the nature of the beast or is
it that all the queueing and dequeing cannot be circumvented at risk
of breaking the entire mechanism?

-Steve