Re: CL: Identifying the 'real' message.

I was told that we can't depend on the messages having consecutive keys - the system sometimes sends messages that we don't see, cuz they get removed - MAYBE not in this case, but not to be trusted - that's why the loop from the &hikey.

Now the other posts may have given you the way, too - what the approach you modified handles is when messages come from different threads (or something) - might be outside the call stack.

In the words I often got from Scott - you might have been lucky!

Cheers
Vern

On 9/17/2014 3:08 PM, rob@xxxxxxxxx wrote:

I simplified it down to
PGM
DCL &MSGKEY *CHAR 4
DCL &MSGID *CHAR 7
DCL &LOWKEY *CHAR 4

SNDPGMMSG MSG(TEST) TOPGMQ(*SAME) KEYVAR(&LOWKEY)
RMVMSG MSGKEY(&LOWKEY)

chgatr '/barneyphil' atr(*alwsav) value(*no)

MONMSG CPFB414 EXEC(DO) /* Object not changed */
/* Figure out why the object was not changed. Might not exist, or you
may +
not have authorization to it. */
/* Get the diagnostic message then delete it */
CHGVAR %BIN(&MSGKEY 1 4) (%BIN(&LOWKEY 1 4) + 1)
RCVMSG PGMQ(*SAME (*)) MSGKEY(&MSGKEY) MSGID(&MSGID) RMV(*YES)
/* Remove the CPFB414 exception message */
CHGVAR %BIN(&MSGKEY 1 4) (%BIN(&MSGKEY 1 4) + 1)
RCVMSG PGMQ(*SAME (*)) MSGKEY(&MSGKEY) RMV(*YES)
DMPCLPGM /* &MSGID = What I want. CPFA0A9=Not exist */
EndDo

END:
ENDPGM

Now I can take the &msgid from here.
Sure would make more sense if I could simply do the monmsg, receive the
exception, then receive the previous message. Just can't get the darn key
to work right with that logic though.

I really did research the archives. And Chuck seem to allude that the
technote shouldn't be necessary within the same program. I just couldn't
get anything else to work right.

Rob Berendt