QMHRCVM and QSYSOPR -- MIDRANGE-L

I have an issue with a program that I can't sort out. I won't post the
source because it's rather lengthy, but I'm hoping that if I describe
the general issue someone might have an idea of something else I can
check. The worst part of it is that the program never really 'fails' (as
in generates an error), but it just seems to stop working.
 
The purpose of the code is to check QSYSOPR for certain messages, and if
any are found direct them to a special message queue for handling by
another process. The program uses the QMHRCVM api to retrieve the
messages from QSYSOPR, and always uses a wait time of 0 (no wait). The
overall flow is as follows:
 
The program starts, and asks for the *LAST message of type *ANY from
QSYSOPR. 
The Message key is stored.
If the right message type is found, a *COPY of the message is sent to
the appropriate queue.
 
The program then enters a loop:
    Check a DTAQ to see if there is a command to end the job. This also
serves as a defacto wait to delay the program.
    Call QMHRCVM looking for the *NEXT message in QSYSOPR (based on the
previous message key)
    Check to see if this is a message to be actioned (based on a table).
If so, make sure the message has not been replied to. If it hasn't,
direct a *COPY of the 
        message to the appropriate queue. The action for the message in
QSYSOPR is always *SAME (i.e. do not change the message status)
    Store the most recent key
    Return to the top of the loop
 
Any errors from any of the API's are logged, and I don't get any reports
of problems. At some point, usually while the program has been running a
few days, messages stop getting sent by the program. Again, there are no
errors reported. It just acts like it doesn't see any messages in
QSYSOPR anymore.
 
I had been suppressing an error in the QMHRCVM call - CPF2477 (Cant Read
Queue). I got to thinking that perhaps this error was causing me to lose
the Message key somehow, so the *NEXT request would fail. I'm currently
testing that possibility, but naturally I can't get the program to fail
in our test environment.
 
Does anyone see any inherent problems with the above structure? I'm
looking for things I maybe haven't thought of yet. It works so well for
quite a while, then just seems to 'give up'.
 
Thanks for any help
 
Jim Wiant
Foodstuffs, Akl., Ltd. 
 
 
 
Quality is remembered long after the price is forgotten. 
Slogan, Gucci Family
 

This message has been sent from Foodstuffs (Auckland) Limited ("Foodstuffs").

The information contained in this message and or attachments 
is intended only for the person or entity to which it is 
addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon, this 
information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from any 
system and destroy any copies.

The views and opinions expressed in this message may be those
of the individual and not necessarily those of Foodstuffs, 
and are not given or endorsed by it.

Please note that this communication does not designate an 
information system for the purposes of the Electronic 
Transactions Act 2002.