Re: CPF376E - Error -- MIDRANGE-L

I might add that if it's really a message that is to be ignored, do a RCVMSG with delete set to *YES - this will give you a much cleaner job log. You would do this inside the DO/ENDDO loop;

Too bad MONMSG doesn't have a cleanup parameter - hey, that might make a decent requirement!

JMHO
Vern

On 10/31/2011 10:54 AM, CRPence wrote:

I am not sure what "do this with the 'I' reply" asks. So rather than
any Inquiry Message Reply handling to provide an 'I'=Ignore reply, I
would suggest instead to /correct/ the code to monitor the failure;
optionally perform some coded recovery actions in response.

If the desired response is simply to ignore the error, then in the
CLP source, any of the following [ordered from most to least desirable
implementation, IMO] would effect that.

<code>

pgm
... /* declarative */
/* no global monitor(s) */
... /* code */
savcfg /* monitor following request ignores cpf376E */
monmsg cpf376E /* the specific error will be ignored */
... /* code through endpgm */

</code>

<code>

pgm
... /* declarative */
monmsg cpf376E /* global monitor ignores specific message */
... /* code */
savcfg /* global monitor ignores cpf376E; assumed this +
is the only request which issues that message */
... /* code through endpgm */

</code>

<code>

pgm
... /* declarative */
/* no global monitor(s) */
... /* code */
savcfg /* monitor following request ignores "function check" */
monmsg cpf9999 /* allows any XXX####, though prevents default +
CL[LE] handler; the *FC logged in joblog; +
DftPgm for an unmonitored remains enabled. +
EXEC() processing should inform of failure */
... /* code through endpgm */

</code>

<code>

pgm
... /* declarative */
/* no global monitor(s) */
... /* code */
savcfg /* monitor following request ignores "function check" */
monmsg cpf0000 /* ignore any CPF#### for which no *FC logged; +
undesirable since all errors are ignored; +
EXEC() processing should inform of failure */
... /* code through endpgm */

</code>

Within the non-global MONMSG the EXEC enables a DO\ENDDO to do
whatever other processing in response to the generic or specific error
condition, including perhaps retrieving and reacting to prior logged
errors. However the save\restore messaging as I recall, had been [IMO
poorly] implemented to leave messages in the SR program message queues
instead of making them available [by move message processing, up to the
program message queue of the invoker], so OUTFILE() processing [save
feature or dspjoblog] or other means to perform reactively to the error
condition may be better than attempts at RCVMSG.

Regards, Chuck

On 31-Oct-2011 08:13 , Willie J. Moore wrote:

Would you have any examples of how to do this with the 'I' reply? I
have some monitoring of message, but most to just see if file active,
etc.