For more than ten years or so COBOL and COBOL with LE has tended to be a
very stable and consistent product for us across releases. Ever since a
long-ago "fiasco" back with COBOL II, when some subtle inter-release
behavioral changes were made that didn't quite make it into the
migration docs, we have had very few issues with source code
compatibility, and I can only remember one or two cases in 20 years
where an application actually hit on a compiler bug that got past the
HIPERs and install buckets.
Compilation tends to be CPU intensive. It makes no difference whether
you have some automated tools to help, recompiling all programs in a
large COBOL shop is a very expensive proposition in terms of CPU time
and real time. Unless the migration documentation indicates this is
required (very unlikely), this is a waste of resources. As others have
pointed out, successful compilation without testing doesn't really tell
you much. Trying to compile and test in a short period all COBOL
programs that took decades to construct and debug is a massive
undertaking requiring many person-months (remember Y2K) and very
disruptive to normal program development. And, I wouldn't recommend
recompiling and installing 1000's of programs without testing, just to
prove your source is current. If you survived Y2K, you should have
procedures in place to insure that already.
Assuming that like us you have on-going program development activities,
we have found the best approach to be to test out basic functionally of
the compiler and runtime with a few cases in a test environment, then at
some point phase in the new version and let normal program development
and testing exercise the new environment and locate any subtle problems
(the only kind you are likely to find) and resolve/document those as
encountered -- and just in case, keep the old compiler and runtime
libraries around for a time with documentation on how they may be
invoked for an emergency fix. This approach has had the least impact on
program development.
Depending on the amount of change in the new release, we have sometimes
phased the LE and compiler upgrade into production prior to an OS
change, and in some cases phased in the LE upgrade prior to the compiler
upgrade. At other times it has seemed low risk to just do it all at the
same time as part of the new OS install (with ways of running on the old
libraries, just in case).
In the rare cases (like COBOL/VS migration) where total recompile and/or
source code changes are required, you can't avoid impacting program
development and must also allow a considerable time for usage overlap of
the compilers.
Ed Gould wrote:
Bill,
Thanks for reminding me of this issue.
How do companies handle the installation and turning new cobol
compilers over to the end users?
1. Do you just install it and let the programmers compile cobol
programs as they normally do?
2. recompile all known cobol programs
3. let them play with it for X amount of time in a sandbox machine
before going towards a full installation.
4. Let you change management program loose and let it do all the work.
6 . Role it out as part of a new OS
7. Other
Thanks,
Ed
--
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
