|
Hi, Charles: I think the possibility of restarting is implicit in the problem as it was stated. Otherwise there is no point to verification. I agree that it is not desirable to have processes that assume failure. In a perfect world, programmers would not write bugs, hardware would not fail, and the effects of configuration changes and upgrades would always be fully understood and anticipated. That world is not the one we live in. So, although failure should not be ACCEPTED it must be ANTICIPATED. Eventually, one would fervently hope, the programs in question would run so reliably that the multi-step verification would not be necessary. At the same time, it would probably be a good thing if the verification steps were handled programmatically and the recovery were likewise "automatic". But if that combined programming effort would require 50 hours; and if the human verification takes only 1 hour a year, and there are no other objective or subjective costs; the project to eliminate verification will be dead on arrival for business reasons. If verification takes a lot longer, then of course at some point the ROI could be acceptable. Darrell Darrell A. Martin - 630-754-2187 Manager, Computer Operations dmartin@xxxxxxxxxxxxx midrange-l-bounces@xxxxxxxxxxxx wrote on 09/27/2006 12:12:22 PM:
You didn't ask about restarting, just how to pause the job stream. I assume that if your check fails you cancel the current job stream and restart at the appropriate place. As a side note, I absolutely abhor this kind of processing. It seems to me that by processing this way, failure is an expected and acceptable occurrence. IMHO, that's an indicator of something seriously wrong with the design and implementation of a system. Charles Wilt
This e-mail, including attachments, may contain information that is confidential and/or proprietary, and may only be used by the person to whom this email is addressed. If the recipient of this e-mail is not the intended recipient or an authorized agent, the reader is hereby notified that any dissemination, distribution, or copying of this e-mail is prohibited. If this e-mail has been delivered to you in error, please notify the sender by replying to this message and deleting this e-mail immediately.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.