I suppose if you have a looping job which generates thousands of these you
might want to remove them from the joblog so you can focus on the more
critical messages.
Jim mentioned a message handler.
Some of us have written techniques in the past for ensuring messages are
dropped when we don't want them. For example, if we have a MONMSG in a
job to handle a particular exception then why leave that scary message in
the job log?
There are also other ways of handling this.
1 - Change either the job, or the job description associated with the job
to up the severity so it doesn't log those messages: CHGJOBD JOBD(X)
LOG(*SAME 1)
Another thing to consider is to stop using output queues to store joblogs.
We've changed the system value QLOGOUTPUT to *PND many releases ago. So
now, even after a job ends, you do DSPJOBLOG JOB(...). If you just HAVE
to get a print (like to send to IBM) you simply do DSPJOBLOG JOB(...)
OUTPUT(*PRINT). You'll notice that IBM changed many job descriptions to
*PND and they no longer generate these spool files.
Then you also have these cool techniques like
select ordinal_position, message_id, message_type,
message_subtype, severity, message_timestamp,
message_text, message_second_level_text
from table(qsys2.joblog_info('*')) A
where severity>0 and message_id<>'CPCA087'
order by ordinal_position;
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Technology%20Updates/page/QSYS2.JOBLOG_INFO()%20UDTF
Too bad that the above doesn't return message_key like
QSYS2.MESSAGE_QUEUE_INFO does. (Or if MESSAGE_QUEUE_INFO returned your
program message queue also) If it did you could write your own QCMDEXC UDF
to remove the messages from the joblog
select 'RMVMSG MSGKEY(' concat message_key concat ')' as cmd,
myqcmdexcudf('RMVMSG MSGKEY(' concat message_key concat ')')
from table(qsys2.joblog_info('*')) A
where message_id='CPCA087'
order by ordinal_position;
Of course it would be also nice if IBM had their own QCMDEXC udf and not
just a procedure.
Rob Berendt
midrange.com
