I was wanting to have the message on QSYSOPR automatically and was
checking for this incident specifically so it would not catch any others
(even though I've NEVER seen this message for any other but understand
the concern others have with that. That's why I had check string check
look for specific into unique to this job).
At any rate, I contacted the vendor again and this time they are
forwarding this problem to the developers...
Thanks,
Chuck
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tom Liotta
Sent: Wednesday, April 15, 2009 5:34 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Monitor Message Help
Chuck Lewis wrote:
Duh - yes; Reply List Entries - my fault. This message is landing on
QSYSOPR as an answerable message just like if it was a printer
message,
tape message, etc. so shouldn't I be able to handle it like I do those
via the Reply List ?
Chuck:
Yes, but what message ID are you trying to catch? CPF4131 or RNQ1216?
I assume that CPF4131 is "expected" by the vendor under some
circumstance. AFAIK, the msgdta() contains the name of the file --
OELMUSR1 -- so you can isolate a reply from other files. (Perhaps
they have one function that needs to be recompiled or some odd
date/timestamp kind of bug buried in an infrequent program; so, a
temporary workfile gets created oddly.)
In any case, what exactly are you trying to do? Do you want to stop
the RNQ1216 from reaching QSYSOPR? Do you want to send a reply to it
out of QSYSOPR? Do you want to handle the CPF4131? Something else...?
Tom
As an Amazon Associate we earn from qualifying purchases.