|
Simon,You bring up a good scenario here. Long running batch jobs can be quite complex. Going into "recovery" mode might be easier said than done. Some of the many possible area to take into consideration are: *LDA, SWS setting, commitment control, overrides, activation groups, job date retention, *LIBL, any user selected input, communications, etc.
While there's nothing in the list that can't be overcome, there's potentially a *lot* to save and a lot of code to handle the restore. I also find that realistically it's easier for an operator to overlook an informational type message vs. one that screams for attention.
I certainly agree in principle w/ your observations. I'm just putting out a contrasting thought regarding trying to handle everything in a complex, long batch job.
-mark At 11/18/06 04:31 PM, you wrote:
(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.)
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
