Re: how to RCVMSG and NOT get CPF9999

There is a technique for getting all messages that have occurred during some process - there is a knowledge base on this.

These days, when messages may appear in the job log but are coming from some other process, this technique is very useful.

The idea is to send a message before calling the process, that message having a message key - then receive that message and remove it but keep the key.

Do the same after the process is done, to get an ending key. Then loop through all the message key values, maybe from end to beginning, to get all you need.

Chuck, I'm sure you're familiar with this KB - I forget the link - and it might be overkill for this situation.

To find the KB - it is doc #28942837 - title is "*Receiving Messages from the Joblog after the Program Is off the Callstack"*

Cheers
Vern

On 1/29/2013 3:34 PM, CRPence wrote:

While the Subject of that discussion is apropos [i.e. "get MSGID of
error that caused abend (instead of CPF9999 errorID)"], that specific
link replies to a modified topic. That specific message describes how
to get the prior diagnostic after having changed the monitored message
from the CPF9999 [i.e. the *FC condition; monitoring every condition
irrespective of message prefix] to a monitor of CPF0000 [which monitors
for any error message prefixed with 'CPF']. Joel is asking [again] to
receive the prior Escape [, Notify, or Status] message which was left
unmonitored, and thus origin for what resulted in the CPF9999. Neither
the CL run-time nor the Message Handling component changes the exception
message [sent prior to the CPF999] to a Diagnostic, so the message that
caused the CPF9999 is still MSGTYP(*EXCP).

With the [left unstated] invocation which could result in that
eclectic set of error messages, including one defined as an inquiry, one
could imagine there are any variety of others that might transpire...
and thus be left to a *FC monitor instead of a CPF0000 monitor which
would still end up handling the CPF9999 condition. And that CPF0000
monitor would be right back in the same place... where the handler gets
the CPF9999 instead of the original exception condition. So likely just
best to monitor separately for the *FC\CPF9999 and code the two RCVMSG
MSGTYPE(*EXCP).?

Regards, Chuck

On 29 Jan 2013 12:48, Mark S Waterbury wrote:

See:
http://archive.midrange.com/midrange-l/201301/msg00611.html

On 1/29/2013 3:27 PM, Stone, Joel wrote:

I have the following code at the top of CL:

MONMSG MSGID(CPF2103 CPF2104 CPF2105 CPF4520 +
CPF1023 CPF2110 CPF2111 CPA7025 CPF2125 CPF7030)
MONMSG MSGID(CPF9999) EXEC(GOTO CMDLBL(ABENDPGM))
...
ABENDPGM:
RCVMSG MSGTYPE(*EXCP) MSG(&ERRMSG) MSGID(&RTNCODE)

When I RCVMSG, the &ERRMSG is always CPF9999

How do I RCVMSG after the MONMSG GOTO and get a useful msg (the
msg PRIOR TO CPF9999)