Re: QRCVDTAQ

Applications send to data queues to trigger the execution of code
that processes the data queue entry.  Where there is code there is
the need to debug that code. Here is the scenario: you are using the
debugger to step thru your code. You come to a program call you
decide to step into the program or not. When the code gets to a
QSNDDTAQ you might want to step into the code that runs to process
the dtaq entry. But for a lot of practical reasons you cant.

Then you have a different problem ... if you want to debug the code that
processes the queue entry, then that's what you need to debug.

This is absolutely no different than debugging a communications program
... if you need to debug the whole process, then you need to debug both
the sender and receiver.  Are you saying that communications programs
are bad for the same reasons that data queues are bad?

classify the dtaq however you want. In my thinking they are 
functionally being used in place of a program call.

Data queue does nothing by itself ... it's only a way to communicate
between two programs.  One program sends, the other program receives.
That's all there is to it.

Sending a correctly formated dtaq entry is just one source of an
error. That is the equivalent of calling a program with the correct
arguments. What does the data queue application do when the customer
number is invalid?

It's the responsibility of the receiving program to make sure the data
queue entry is correct .. if it's not, it needs to communicate a message
back to the sender indicating so.

I would say stay away from interfaces and OSes that dont provide 
integrated exception handling support.

So we should stay away from RPG programs that don't throw exceptions?
I've seen darn few RPG programs that throw exception messages.

Why use Unix when there is .NET?

Maybe because the unix API's are pretty much standardized across many
platforms and have existed for decades, while .NET is not on multiple
platforms and have only existed for a handful of years.  AFAIK, there is
no .NET api built into the iSeries yet.

In practice data queue driven server jobs crash because of invalid 
data queue entries.

Only poorly written ones.  A properly written data queue driven server
job should report invalid data to the sender and move on to the next
queue entry.

They also fail to start after the system backup.

That's an operational issue that's easily solved by having properly
implemented procedures.

Sometimes they end because the entry that tells the server job to end
 has found its way onto the queue or was there when the server job 
started.  All of these points of failure dont exist if the
application simply calls a program to perform a transaction.

The only way an entry can find itself on a queue is if it's put there
... if it was put there, it should have been put there for a reason.  If
it was put there for a reason, the server job should obey the command.
Nothing just 'happens'.

The background job transaction does not run under the authority of
the user who initiated the transaction.  There are ways to get around
this but it is work and does not solve all the problems.

Depends on how it's implemented and what it does.  Any client / server
system should have some form of security and authentication mechanism
built in.

Program call is much better.

Depends on the application requirements.

Both techniques have their place ... both are tools that can be used or
misused.

david