---------SNIP----------------------------------
The problem is the hypothesis makes an assumption which is not
correct. I
thought another poster in this thread made it clear, but I'll
explain the
point again. Adopting Enterprise COBOL 5.1 does NOT require:
1. Recompiling every (or even any) COBOL program you already have;
That was clear from day one.
2. Moving every (or even any) COBOL program you already have from
PDS to
PDSE;
That is a BIG issue. And not allowing sharing across plexes is
another big issue
3. (For the vast majority of programs) changing code if/when you do
recompile.
NONE of those steps are prerequisites for adopting Enterprise COBOL
5.1.
Let's be very clear about the facts and not prone to hyperbole. You
can
keep older binaries, and you can keep them in PDSes. If your source
code
compiles in Enterprise COBOL 4.x then in the vast majority of cases
it'll
also compile unmodified in Enterprise COBOL 5.1 and behave exactly
the same
way (except more efficiently). The few exceptions will be if you
have used
a new reserve word. It has always been thus in every COBOL release
upgrade,
so by now you should be well familiar with that reserve word
phenomenon and
how to address it. (Ask if not.)
I can't WAIT for the first PMR. How about compiling into a PDSe do we
have a better idea what is going on.
I had a problem where they wanted to change the compiler (maybe a bug
in the compiler) and now all of a sudden there is a PDSe requirement
in addition to just recompiling.
Also I think either you (or IBM) is in for a big surprise as not many
companies keep their COBOL (or for that matter any language) in an
PDSe library. We never had issues with them (OEM libraries) just PDSe's.
Ed
The PDSE prerequisite is *only* for programs you compile with
Enterprise
COBOL 5.1. And this is why I'm asking the question and would like
to hear
some more constructive responses, because this is a very important
point. I
suspect that, in most COBOL shops with that "40 years and thousands
(millions?)" scenario you will be doing ONLY the following (at a high
level) to adopt Enterprise COBOL 5.1:
a. Allow running newly created and newly recompiled programs from
PDSEs (if
you haven't already);
b. Keep existing unmodified COBOL binaries in PDSes "forever";
c. Make sure your development, testing, and runtime environments
behave as
you intend across PDSes and PDSEs.
That would be the typical upgrade scenario at a high level, I would
imagine.
That is *exactly* what z/OS customers adopting Java on z/OS did
(and do).
Most of them also have large portfolios of COBOL (and/or PL/I and/or
Assembler, etc.) applications that they write, test, deploy, and
maintain.
Java (their new compiler) requires PDSEs. So they implemented PDSEs
if they
didn't have them already. New and newly recompiled (Java) code goes
into
the PDSEs, and they run, successfully. Existing code stays put
unless and
until they have a compelling reason to touch it. This path worked and
works.
It's the same darn path except even simpler, isn't it? In this case
there's
no second programming language (all is COBOL), no new runtime
environment
(s) (unless you wish), and Enterprise COBOL 5.1-compiled programs
interact
directly with previously compiled COBOL programs even more easily
-- no
JNI, for example -- and just as you would expect.
OK, let's summarize again....
I. IBM faced a *technical* decision (as Frank posted earlier -- thanks
Frank). To adopt the (fabulous and continually getting more
fabulous) Java
backend for the next generation Enterprise COBOL compiler also
required
accepting Java backend prerequisites, and that means PDSEs, a
technology
IBM first introduced in 1989. The other choice was not to use the Java
backend technology, in which case I'd/we'd be reading at least another
decade worth of complaints here about how IBM is not delivering COBOL
improvements. Yes, IBM looked really carefully at all alternatives,
even
some "crazy" ones. I think IBM really, really made the right
fundamental
technical decision here -- absolutely the right decision to promote a
vibrant and growing future for COBOL.
II. The PDSE prerequisite is *only* for COBOL programs that you
compile
specifically with Enterprise COBOL 5.1. Most of you will not and
should not
do anything with any previously compiled COBOL program in a PDS,
especially
if it is not particularly relevant to peak utilization, unless and
until a
developer needs to change the older program and recompile it. This is
innovation via evolution, not revolution.
III. IBM is not forcing you to do anything, including start your
single
version charge (SVC) period for Enterprise COBOL 5.1 until you've
had a
chance to trial it. However, the rest of the world often forces
change.
("Darn those pesky smartphones! Now get off my lawn." :-)) Again,
how much
is XX% code efficiency improvement worth? How much is constraint
relief
worth? There are many customers enjoying the benefits of Enterprise
COBOL
5.1 now, and many more will follow. Some of them might be your
competitors.
But even within your own organizations, business users are going to
seek
ways to get their jobs done, with or without you. (Cue John Gilmore
here.)
Innovate (or at least improve), or die. I know IBM understands that.
My views are my own here, as always.
----------------------------------------------------------------------
----------------------------------
Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
