Re: QRCVDTAQ

On 7/10/06, Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx> wrote:

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

While true, sometimes you don't want/need one.

modules have to throw exceptions. that's my rule! ahem.  If you cant
throw exceptions then you are not modular and you are going to have a
terrible time debugging and maintaining your application.

Consider what it takes to change a background processor application.
How do you get a list of the transactions the server handles?  Not
easy. All the clients are sending a flat 80 characters that can have a
number of formats.  What clients are feeding the server?  You probably
cant tell because all the clients use a direct call to the qsnddtaq
api.

One of the great
advantages of DQs is that they can be used for async processing. In that
case, while you do need some way of reporting errors, the logic assumes
that there is no return code since the server job hasn't looked at the
sent request, and may not for a long time.

Another advantage is that you can have several jobs reading from the
same queue (and obviously many jobs sending to it) so if you've got a
resource intensive server process you can start as many jobs as you need
to keep the queue size "reasonable."

What type of resource do you have in mind Walden? In my experience
background jobs are used because, at least when the application was
written, there are CPU restraints on the system. This is the same
reason why batch processing was much more prevalent in the past than
nowadays.

I just think IBM is killing us with these underpowered systems it is
selling. A 1200 CPW 520 is a dead end in terms of the modern work load
it can handle.

-Steve