Re: Remove DDM informational messages -- MIDRANGE-L

I thought the idea was to avoid having to modify programs.

If we're going to modify programs, then I'd write a CL to remove any CPI9160- CPI9200 messages from the program message queue, and then put a call to that in any program at some point after it has opened its files, e.g. in *INZSR, or somewhere else if there are USROPN files.

STRWCH starts a system job that monitors various things and calls a program if one of the events occurs. The called program runs in the system job, not in the user job. I know because I tried it.

There is a user-exit for file opens, but it occurs /before/ the file is opened, so the messages wouldn't exist when it was called. I think that program would run in the user's job, but I'm not 100% certain of that.

On 9/2/2020 5:41 PM, Robbin Chewings wrote:

I'm not clear why you are focusing on running this remotely.
I would suggest we try it before finding hypothetical problems.
Make a user exit to remove CPI9200 (informational) and then just call TOE510 and you will see the DDM messages.

On Wed, Sep 2, 2020 at 4:29 PM Peter Dow <petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>> wrote:

Hi Mark,

That's a good question, whether removing the messages from the
joblog would remove them from the program message queue.

Another issue is that the system in question has QALWJOBITP set to
zero. In order to use QWCJBITP without modifying the jobs, that
would have to change to 2.

And reading up on QWCJBITP made me realize that even if that all
worked, there would most likely still be a timing issue, i.e. the
DDM file is opened, the DDM server sends the message to the pgm
msgq, the STRWCH session calls my program, my program does
something to remove the message from the original program's
joblog. Where in all that is the original program loading its
message subfile from the pgm msgq? MIght be hit or miss.

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /

On 9/2/2020 3:25 PM, Mark Waterbury wrote:

Peter,
You could use the QWCJBITP API to schedule a command to run inside another job ... but, I don't think that will help because, although you can remove the messages from the job log, as far as I am aware, they will still be in the program message queue.
Mark S. Waterbury

On Wednesday, September 2, 2020, 5:53:51 PM EDT, Peter Dow<petercdow@xxxxxxxxx> <mailto:petercdow@xxxxxxxxx> wrote:
Hi Rob,

This

STRWCH SSNID(*GEN)
       WCHPGM(QGPL/MyPgm)
       WCHMSG((CPI9200))
       WCHMSGQ((*JOBLOG))
       WCHJOB((*ALL/*ALL))

works great as far as having one place to monitor for those messages
being sent. It gives me the job name, user, and number, and the message
ID and even the message key, e.g..MsgId:CPI9200 Msgq:*JOBLOG
Job:225959/PDOW/PDOWS1 MsgKey:1077952576

However, it has a drawback: RMVMSG only works for the current job. Same
with the QMHRMVPM api. And the QMHRMVM is only for non-program message
queues.

I had some small hope the the MSGKEY parameter on the RMVMSG command was
a global key, but apparently not:

Message . . . . :   CPF2410 received by procedure MYPGM. (C D I R)
Cause . . . . . :   ILE Control language (CL) procedure MYPGM in module
MYPGM in program MYPGM in library QGPL detected an error at statement
number 0000005200. Message text for CPF2410 is: Message key not found in
message queue QJOBMSGQ. Use F10 (if available) or the Display Job Log

Do you know of a way to remove a message from another job's joblog?
Without having to modify any programs in the other job?

Peter Dow

On 9/2/2020 12:59 PM, Rob Berendt wrote:

I've never done something like this but does this have potential?
STRWCH SSNID(*GEN)
WCHPGM(MYPGM)
WCHMSG((CPI9160) (CPI9200)
WCHMSGQ((*JOBLOG))
WCHJOB((*ALL/*ALL))

And then have MYPGM remove the offending messages from the joblog?
You could probably roll this out by customizing the WCHJOB

Rob Berendt