Re: RCVMSG *DIAG (seemingly) not working

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

On Tue, May 30, 2017 at 1:46 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
<snip>

Here's an example of CLP + REXX that will do what you're looking for.
Both members are imaginatively called SQLTEST4.

<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.

2) any production use of REXX in this shop is verboten simply because no
one else is willing to learn it. (Just remember, whatever y'all got to say
about that, y'all be preaching to the choir.) We still have one developer
who refuses to code any part of RPG in free-format.

:-(

I picked REXX for several reasons:
1) It's on every IBM i
2) It's suitable to the general Midrange list
3) The REXX queue is a useful way to pass multiple messages back to the
caller / CLP. I'd have to set up a data queue / message queue / user
space / database file with RPG, or somehow have the RPG program search /
scan / isolate the one diagnostic message that's 'interesting' to the
caller (and pass that back in a parameter).

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.

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.