Paul Gilmartin wrote:
On Wed, 29 Jul 2009 16:59:11 +0000, Ted MacNEIL wrote:
Couldn't someone write some sort of automated analyzer to examine the code and
determine whether it's in an infinite loop or will
ultimately terminate?
DEXAN (OmegaMon) used to be able to do that.
I've not seen that add-on for years, so I don't know if it still exists.
-
And there I thought I was joking:
http://en.wikipedia.org/wiki/Halting_problem
I'm glad to see someone stepped up and showed Alan Turing wrong.
-- gil
Turing was right. The automatic determination of whether an arbitrary
program will halt given an arbitrary input has been proven
"undecidable". It may be decidable for some specific cases but not in
general. So it must also be the case that in the general case it is
impossible to automatically determine if a program is in a
non-productive loop.
But that of course doesn't apply directly in the real business world
where computing resources are finite and cost real money. It the real
world, every program will halt, either on its own or when it starts to
consume more resources than is acceptable and is cancelled by human
intervention.
In the real world there are a number of heuristic techniques that can be
applied based on historical information available to an installation:
(1) a program which has worked before on different input, is possibly in
a non productive loop if when given comparable sized input it suddenly
sees a drastic increase in CPU and/or real time requirements, and that
possibility becomes a near certainty if measurements show that it is no
longer advancing to the next input transaction.
(2) a program that is advancing through input transactions but consuming
resources out of proportion with the business value of the results or
grossly in excess of other programs believed to be doing comparable work
will be flagged for poor performance and analysis will be required to
either redesign the algorithm used or tune the application to get
acceptable performance. In some cases it may be possible to predict
based on progress through files that the program may complete but at an
unacceptable cost, in which case it is cancelled rather than allowed to
complete. We have seen cases with obvious performance tuning issues
where the program can be cancelled, the problem corrected, and the
restart completes sooner than letting the original run continue to
completion.
(3)historical records are kept on the maximum CPU used by all past
production programs. If a test program or a new production program,
based on projected execution progress, can be estimated to exceed that
known maximum by a significant factor, then there is an obvious serious
design issue or performance tuning issue that needs to be addressed
before running the application to avoid potential negative impact on all
other users (regardless of how much value some place on the results).
We have yet to find a case were there wasn't a cheaper way to get the
desired results, which in the end benefits the corporate bottom line.
As a modified approach to the issue of CPU time enforcement, our system
exit that enforces CPU time limit only automatically cancels jobs in
test job classes. Production job classes give the operator the option
of granting a CPU time extension rather than cancelling the job. They
are generally the ones in the best position to know what behaviour is
"normal" for an application and typically will check with the
responsible programmer before cancelling a job if it doesn't complete
after a few extensions.
--
Joel C. Ewing, Fort Smith, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
