That's exactly what I needed, although my job log is not filling, just a
few hundred messages.
Maybe I'm using Monitor wrong, but it just feels perfect for the "shoot
first, ask later" kind of programming. The workarounds (removal via
message APIs, TEST, Ifs) all seem a little messy.
Anyway, I'll get a little messy, since these harmless messages really
get on the nerves of the current operator. Who knew they actually
checked job logs?
Thanks to all for your suggestions.
--
Saludos
Antonio Salazar
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Kurt Anderson
Sent: Monday, February 22, 2010 1:27 PM
To: 'RPG programming on the IBM i / System i'
Subject: RE: Quieter Monitors
Check this thread out:
http://archive.midrange.com/rpg400-l//200411/msg00780.html
I don't have access to the article that Scott Klement links to in the
archived thread, but it's more than likely worth paying for. Trust the
source. ;)
Kurt Anderson
Sr. Programmer/Analyst
CustomCall Data Systems
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jose Antonio Salazar
Montenegro
Sent: Monday, February 22, 2010 12:54 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Quieter Monitors
Hi.
The Monitor opcode is my favorite approach to error catching, but it has
the disadvantage of filling your job log with already managed errors.
For example, there's a data file where a numeric field is validated to
see if it contains an *ISO date. If it doesn't, a default date value is
used, but the job log lists thousands of harmless but suspicious "Date,
Time or Timestamp value is not valid" RNX0112 messages.
Can Monitor be made less verbose?
--
Saludos
Antonio Salazar
midrange.com
