×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Just a follow-up on this topic for anyone interested.
The problem is to remove message CPI9200 from a target job before it
loads its message subfile, so that the DDM informational messages do not
clutter the message subfile.
Keeping in mind this is on a v7r3 box, I came close using several pieces.
1. A system wide watch for the CPI9200 which calls program DDMMSGC when
the message is sent.
2. The target job should use the SYSREQCMD or equivalent to create a
message queue in QGPL named WCH_jobnbr.
The SYSREQCMD is from way back in System/38 days, and still works
today. The idea is to create a message queue with a break handling
program attached. The message queue is set to *BREAK mode, and whenever
a message is sent to it, the break handling program receives the
message, and in this case, calls QCMDEXC with the message text expected
to be an OS/400 command, that runs within that job.
3. The watch program, DDMMSGC in this case, looks for the existence of
msgq WCH_jobnbr for the job the CPI9200 message was sent to. If it
exists, it sends a message to that queue "CALL RMVMSGC".
4. The RMVMSGC program, running in the target job, removes the CPI9200
message.
The weak link was getting RMVMSGC to remove the CPI9200 message. The
watch program receives data about the message, including the message
key, except that the message key (in my experience) was always blank.
If it were an actual non-blank message key, I could pass it to RMVMSGC
and it would be able to remove the correct message. I couldn't seem to
have RMVMSGC reliably get the correct combination of call stack entry
info to select the CPI9200 message with QMHRCVPM or RCVMSG.
Another possibility was Rob Berendt's mention of IBM's SQL UDTF
qsys2.joblog_info. That would've been great, because it made selection
of the correct message simple. However, it does not return the call
stack entry information. If we were on v7r4, then it says it will
return the message key which would be ideal, but here we are on v7r3.
So we ended up going with plan B, a simple version of RMVMSGC which has
a single parameter of a program name, then loops on
until it gets a blank &MSGID, and whenever it finds a CPI9200, it does a
RMVMSG MSGKEY(&MSGKEY) CLEAR(*BYKEY)
Each program that wants a clean message subfile has to be modified to
call this program in *INZSR, or at least after it has opened all its
files and before it loads the message subfile.
That works, but requires modifying a bunch of programs.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
