RE: Quieter Monitors

Monitoring in RPG is analogous to monitoring in CLP.
The OS will may throw an exception which will appear in the job and the RPG or CLP program may die as a consequence unless it handles the exception.
The issue of handling in RPG is also analogous to CLP.
In CLP, if you don't want the message lingering in the job log you must code to explicitly remove the message.
In RPG, you must also code to remove messages.

In my experience, it is far more acceptable to provide explicit validation code in the RPG to prevent the situation where the OS has to invoke it's default handling routines to manage exceptions.
It is less efficient to let the error escape out to the OS and then handle it on the way back in than it is to trap it in the program before it gets out.

Date and number validation are prime candidates for this scenario. Without explicit validation within RPG, the job log can end up verbose.
The Monitor opcode makes it easy to omit proper validation during development for errors which would be known to occur.
In my view it is better used as a catch-all to provide for events that are genuinely exceptions.

Peter


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jose Antonio Salazar Montenegro
Sent: Tuesday, 23 February 2010 7:54 a.m.
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