Shmuel Metz (Seymour J.) wrote:
In <[EMAIL PROTECTED]>, on
08/29/2005
at 01:08 PM, Bill Klein <[EMAIL PROTECTED]> said:
I guess (but am not even certain of this) that *IF* you have the
resources to do a "mass recompile", that it doesn't HURT. However,
if doing so (and more importantly making certain that everything that
NEEDS testing GETS tested)
I wasn't recommending recompiling in order to put new object code into
production. Neither of the two reasons that I gave for the recompile
requires testing the object code. In fact, "so that you can schedule
eventual remediation." wouldn't make much sense if you were doing the
remediation immediately.
rather than making every application program be recompiled and
retested
Again, I never suggested retesting as part of the compiler migration.
I suggested *scheduling* remediation of those programs that wouldn't
compile.
You have an implicit assumption here that the only significant changes
from release to release are syntactical in nature. The problem is that
some of the more troublesome changes over the last 25 years, sometimes
even within the same version level of the same COBOL compiler product,
have been semantic in nature. Some of these semantic (interpretation)
changes appear to have been driven by changes in the COBOL standard,
some by re-interpretations of the standard, others just changes in areas
that the standard allows to be implementation dependent.
Compilers are pretty good at detecting and flagging syntactic errors as
compile-time failures; but in order to reliably detect semantic errors
the compiler would have to be able to surmise "intent" of the program,
which is beyond the scope of what can been determined from just the
COBOL source. Conceivably a compiler could warn about every statement
construct and compile time parameter combination that has been
associated with different semantic interpretations over the years, but
such a list of warnings would likely be too verbose to be very useful
for flagging just those programs with real migration exposures.
I would fear that a migration approach that focuses on COBOL programs
that fail compilation may give you a false sense of security. The kinds
of errors that the compiler can reliably flag also tend to be the kind
that are relatively easy to fix. It's the programs that still compile
cleanly but produce subtly different results that can drive you batty.
It would seem to me that you first need to compile and test a subset of
your COBOL code base sufficient to see if there is any obvious pattern
of potential problems with either compiler errors or execution, and then
use that as the basis to decide what is appropriate: mass remediation
with testing, mass compilation, or neither.
I might also add, that even if you have the hardware resources to do a
mass compile of all programs, you may still have to budget "real money"
for software licensing increases if you are on sub-capacity licensing --
if you saturate the system with enough compiles to raise your peak
four-hour MSU average for the month, software fees go up accordingly.
Idle CPU time is no longer always "free".
--
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
