You're an enthusiastic prosletisor of the panacea you believe in!
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
-----Original Message-----
From: Timothy Sipples <sipp...@sg.ibm.com>
Sender: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
Date: Thu, 19 Sep 2013 11:52:35
To: <IBM-MAIN@LISTSERV.UA.EDU>
Reply-To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: PDS/E, Shared Dasd, and COBOL V5
Tom Conley offers a nomination:
>Simple. With Java, we didn't have 40 years and thousands (millions?)
>of libraries to convert. That's what makes COBOL different, the
>conversion effort. Java had no code base to convert, so we could
>start new.
OK, that's an interesting hypothesis for why z/OS customers running Java on
z/OS might be different than z/OS customers running COBOL on z/OS.
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;
2. Moving every (or even any) COBOL program you already have from PDS to
PDSE;
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.)
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: sipp...@sg.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
