Re: monmsg question -- MIDRANGE-L

IF I see one more monmsg CPF000 at the TOP of every CL written by a
predecessor of mine I am GONNA SCREAM!!!

On 11/18/06, Simon Coulter <shc@xxxxxxxxxxxxxxxxx> wrote:

On 19/11/2006, at 1:52 AM, PaulMmn wrote:

> I take issue with your 'overly clean' job logs--  I -want- to see if
> a data area isn't created.  In our environment, every clue that
> provides insight into why a job had problems is important!  I know
> you'll say that a program that has problems doesn't belong in
> production (I agree), but the reality says that only a "user" can
> find the last bugs!

Which is exactly WHY all programs require graceful error handling. Most
"user" errors should be found during User Acceptance Test but because
unexpected things can happen in production all code needs a way to deal
with the unexpected. The default exception handler isn't good enough.

>
> In the case of the data area, if it doesn't exist and it should, or
> it does but it shouldn't, I -need- to know!

And you -would- know if you follow what I said.

In both these cases the exception is unexpected. Why? Because:
        1) in case A your code expects the data area to exist
        2) in case B your code expects the data area to not exist

Because these are unexpected exceptions there should be no command
level MONMSG for either of these cases. The very presence of a command
level MONMSG says the exception being monitored IS expected.

Both these situations are correctly handled by a global MONMSG for
CPF9999 with a corresponding error handler. Because this is an
unexpected exception you would leave these messages in the job log
otherwise you have no chance of diagnosing the problem. The error
handler should at least resignal the exception but it should probably
also do any necessary diagnostic collection (such as DSPJOB, DSPJOBLOG,
DMPCLPGM, etc.) and notification.

My 'clean up' comments were specifically about command-level MONMSG
statements (i.e., handled exceptions) and unnecessary completion
messages.

The result is a graceful handling of the exception AND sufficient
information to correctly diagnose the problem. In this example however
the real cause is likely some other program or job that failed to
create or delete the data area as necessary.

(I'll bet someone will throw up the example of a long running batch job
that crashes because of a missing something-or-other and because it
does not have ANY exception handling or at least does not have a global
exception handler the default exception handler kicks in, the missing
something-or-other can be created/added/restored/whatever, and the job
allowed to continue. I agree that's nice but not necessary. A properly
written long-running process will have a restart facility so it can
pick up close to where the crash occurred.)

Regards,
Simon Coulter.
--------------------------------------------------------------------
    FlyByNight Software         AS/400 Technical Specialists

    http://www.flybynight.com.au/
    Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
    Fax:   +61 3 9419 0175                                   \ /
                                                              X
                  ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.