Re: RCVMSG *DIAG (seemingly) not working

On Tue, May 30, 2017 at 3:09 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 5/30/2017 2:34 PM, Dan wrote:

On Tue, May 30, 2017 at 1:46 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
<snip>
Thanks, Buck. A nice example that will go into my toolbox.

Unfortunately,

1) the REXX code is another program that I couldn't justify for this and,

What does it mean, 'justify'? I'm not asking for an answer; I'm asking
so you can think about it in the big picture sense of how things fit
where you work. And how you'd like them to fit. For me, I write
programs for a living; a few lines of REXX or RPG to encapsulate a
useful function seems like a must-have to me.

The short answer: I am limited with what I am allowed to do.

A few questions:

1) Why did you use COALESCE on message_ID but not on message_type or
message_text?

If you execute the raw SQL in SQL Scripts, you'll see that the service
returns NULL if there's no MSGID (ie for INFORMATIONAL messages). It
always returns a non-NULL value for the other parts. There's no harm
using COALESCE on other columns; I just didn't need to.

Ah. Forgot about informational messages. That makes sense now.

2) Is there really any advantage of using the API or QSYS2.JOBLOG_INFO

over

the method Rob gave in
https://archive.midrange.com/midrange-l/201705/msg00732.html, which I

ended

up using?

Maybe. If the process is trying to winkle out diagnostic messages sent
from one DB2 program to another DB2 program as a result of an SQL
statement issued 3 programs up the call stack, then you'll have to read
the messages out of the job log, because those messages won't be visible
to RCVMSG and friends, due to those DB2 programs no longer being in the
job stack.

If the process is only interested in messages that have percolated up to
the current running program, then RCVMSG works a treat.

Good to know. So, Rob's original solution works in my case, but I will
remember to utilize that next time for a more robust solution.

Thanks,
- Dan