On Aug 27, 2005, at 3:14 PM, Bill Klein wrote:
Ed,
I am *not* maintaining a production COBOL (or any COBOL) environment
these
days (I'm on long-term disability). However, I did want to make my own
personal suggestions:
I was not aiming the question at you, it was a general question. I was
hoping to get a discussion started on the best way to implement a new
version of cobol.
1) Unless you are upgrading from a VERY old compiler, there is
absolutely NO
need to "recompile" every program. If you are using ANY release of
LE, then
(in most cases) you can continue to run old object code with no change.
We have seen on here that there some people on VERY old releases. I
thought the discussion might help some of them out.
Again the list was not meant to be all inclusive and some possibilities
were suggested.
2) Obviously, if you are still using OS/VS COBOL *or* VS COBOL II, then
there are some pretty good reasons (both technical and "feature-wise)
for
trying to get as many of your applications as possible on a more
current
compiler. (The CICS TS V3.1 drop of OS/VS COBOL support - even with
LE - is
just an example).
Of course there are some people that still run really *OLD* CICS's (pre
mvs even).
3) Staying current on LE releases (and NOT allowing "ongoing" steplib
access
to earlier run-times) is TO ME the most important thing that any shop
can
do. Similarly, getting to RES (assuming you are on a pre-LE compiler
that
supports NORES) is pretty important.
I left LE out of my simple questions (it is important we both agree).
One or two people on here seem to think that any email that I write has
a negative opinion of LE. I did not wnat to bring that up as a red
herring. So anyone put you knives away this is strictly a cobol
discussion.
4) With VERY few exceptions, I have always (and still do) recommend
- introduce your "new compiler" into the test system to see if
there are
any problems
- use it for all new development (after a period in the test
environment,
your time will vary)
- use it for all maintenance of older programs
- do NOT "require" superfluous re-compiles and re-tests of older
applications
I think it tends to be the environment (politics) that lays the ground
work for these types of issues.
5) Education is (and will always be) important. AT LEAST make certain
that
your programmers know what is "available" (and changed by default)
with the
new compiler. If you are making a "big jump" (e.g. VS COBOL II to
Enterprise COBOL) then get in-house training.
Ahhhh but where do you get it? IBM doesn't seem to want to offer it. I
could be wrong but I have yet to see *ANYTHING* from IBM on education
and new releases of cobol. (don't get me going on LE). There
might be some independent options, if there is they sure don't seem to
get the word out. Steve Comstock (on here) is probably the only one I
have heard of. Plus there is also the ever issue on who will pay for
it. The application managers say its the systems area responsibility
and "we" say its there problem. Just try and put education in the
systems budget for the rest of the company and you will see it taken
out so fast your head will spin.
6) Always, ALWAYS (both for LE and COBOL) make certain that your 3rd
party
products are at a release lever to support the new release BEFORE you
introduce it - even into your test system.
Therein lies the "rub" the third party vendors refuse to support new
versions of LE and cobol. There is no way you can force that issue end
of discussion.
7) Never IF AT ALL POSSIBLE, upgrade LE and COBOL at the same time.
Upgrade
the run-time (LE) *first*; make certain that it has no problems
(including
no performance hits and that all your 3rd party products work with the
new
release) and THEN upgrade the compiler. If you absolutely MUST
upgrade
both together, make certain that you allow MORE time for problem
resolution.
* * *
Ahhh now we are getting back into IBM land issues. Since TCP (and
OMVS) are tied to LE its almost impossible not to.
P.S. RACF "warn" mode is your FRIEND.
Make certain that any "old" version of the compiler or run-time
is
(at least) in WARN mode so you (and your application people) can KNOW
who is
using older releases (and find out why).
Well yes and no... I agree in a perfect environment that it is your
friend. In the real world as they say no way Jose. People make copies
of the various libraries and stick them all over the place. I have see
them in production libraries. Try and find out who did it and get rid
of them? hahahaha politics trumps all.
Ed
----------------------------------------------------------------------
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
