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.
CRPence on Monday, October 31, 2011 7:38 AM wrote:
On 31-Oct-2011 06:50 , Willie J. Moore wrote:
Our weekend processing received error 'CPF376E - Not all
configuration objects saved'. The weekend processing stopped
because the default was a "D". I was thinking of added it to our
'Replay List' with the 'I' option. I would be interested in hearing
of any other suggestion.
Adding that message for reply list processing will give no joy, no
matter the Inquiry Message Reply processing [INQMSGRPY] established for
the job. That is because the message CPF376E along with all or at least
most message in the "range" CPF3700, are not inquiry messages.
Presumably the failure in Save Configuration effected the default
handler in the CLP or CLLE for which the message CPA0701 [or equivalent
CLLE] inquiry was responded to [automatically] with the 'D' reply. In
that case, resolution could come from changing the source to include a
MONMSG for the CPF376E and any other messages [as described on the
general help for the SAVCFG command], and then coding the desired
response. <<SNIP>>
midrange.com
