Re: Quieter Monitors

[Rory Hewitt <rory.hewitt@xxxxxxxxx>]

No, it's not a formal name :)

I guess I prefer to write code which up-front checks (and caters) for as
many errors as I can think of. Of course this means that the code is full of
little IF-clauses checking for this error and that. So I'd be in your latter
group.

I've never liked the MONITOR op-code, because it allows developers to rely
on the system to catch things which they should have checked for in the
first place. In Scott Klement's article which Kurt linekd to, Scott uses his
CleanUp() procedure to clean up job log errors that might happen if he
attempts to divide by zero. Me, I would have checked for zero before the
divide. Likewise with the other errors.

I *am* anal about job log messages <grin>

Of course, there's no reason why you couldn't write a procedure similar to
Scott's CleanUp() procedure, which cleans up every job log message:

monitor;
 //stuff goes here
on-error;
  CleanUpJobLog();
  // error processing goes here
endmon;

but you'd probably want to use the QMHLJOBL or QGYOLJBL API rather than
QMHRCVPM, since you might want to remove low-level messages which were sent
to IBM sub-programs too.

On Mon, Feb 22, 2010 at 4:32 PM, Jose Antonio Salazar Montenegro <
0jsalazarm@xxxxxxxxxxxxx> wrote:

> Why yes, they are. That's why I'm changing them.
>
> I'm sure it's not the formal name, what I meant was doing what could
> trigger an error and monitor for it rather than programmatically prevent
> all possible error conditions and only act until you think all bases are
> covered.
>
> Some languages, like Python, make it easy to use this approach. When
> Monitors were introduced, RPG did too, with the minor inconvenient of
> spamming the job log.
>
> --
> Saludos
> Antonio Salazar