Re: Quieter Monitors

Yes, it would be nice if IBM made it easier for us. However, I agree with your operators. I've been put into the position of having to read through hundreds of pages of "normal/expected" errors trying to find the one error message somewhere in the middle. It's a needle-in-a-haystack situation -- and it's very unpleasant.

Clean up any "expected" messages from your job log. It makes your software much easier to work with!


On 2/22/2010 5:08 PM, Jose Antonio Salazar Montenegro wrote:

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