× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.