Not the perfect answer but we had a mission critical application that used
data queues and faced a similar issue.
What we did was the program that did the receive would write the details
to a database file as the very first step of processing the queue entries.
A status would be set to indicate the processing was P=Pending.
Then the processing program(s) would update this status as the step(s)
were completed and finally the status was updated to indicate processing
was complete.
We originally had a nightly process that would check for any incomplete
processing and either report it or attempt to complete the process. This
process was improved over time by adding more information to the database
file to allow the processes to be retried. This process subsequently was
run more often and the ability to halt data queue processing for specific
error conditions.
There was also a purge process that cleaned up this database file and
provided some statistical reporting.
All in all this worked very, very well.
Just my 2 cents.
Don Brown
From: "Javier Sánchez" <javiersanchezbarquero@xxxxxxxxx>
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Date: 24/09/2019 11:43 AM
Subject: Use DTAQ unter Commitment Control to implement
Acknowledgement
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx>
i tried commitment control but it has no effect on sending and receiving
messages to a dataqueue. puting back the message to the queue is no
solution because when an unexpected error occurs commitment-control
would
be the safer way.
If you are not using more than one instance of a job listening on the data
queue, it may be reasonable to resend the entry to the queue. If the
error, for example, was the unability to lock another record of another
file, it's reasonable to reuse the entry, and let ROLLBACK to undo
everything else. A retry may succeed some time later. But if you have
several listening jobs to the same queue, you may get into an infinite
loop
problem.
In general, if you weren't successful in the first try, it may probably be
safer to discard your entry and let the original sender to resend it,
having had an error message from your program.
I imagine you are dealing with a transaction messaging kind of
application. Just like credit card authorization systems, they simply
report a rejected authorization and have the end user resend the message.
Javier Sanchez
midrange.com
