On 09/18/2013 10:52 PM, Timothy Sipples wrote:
> 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: [email protected]
> ----------------------------------------------------------------------
Firstly, let me say as far as I know my former, predominantly COBOL,
shop could tolerate requiring PDS/E program libraries wherever COBOL
code is involved. But making this decision for an existing COBOL shop
versus for a new programming language environment does complicate things
in that there are established procedures and tools for program
maintenance and installation, and probably many 1000's of production job
steps that execute COBOL-generated code and reference the existing
program libraries.
If you set up new PDS/E program libraries for only V5 program code, then
any time maintenance on a COBOL program is done the maintainer must be
aware whether this is the first time this program has compiled with V5
and if so, be sure any related production JCL gets changed to reference
the new library in sync with the program installation and be sure the
obsolete load module in some PDS gets purged at the same time to prevent
possible execution of obsolete code. Finding affected job steps may be
non-trivial, especially if the compiled code is a subroutine and not
directly referenced in JCL. Assuming that all these cross checks would
be done reliably during a 0200 emergency fix that also happens to be the
first V5 recompile is probably unrealistic.
If these changes in library conventions are enforced manually, there are
going to be errors during the transition. If you have installation
tools that control the compilation and installation process (we do), you
are in a better position to enforce new conventions and prevent
transition errors, but those tools will have to be re-configured or
perhaps partially re-written, either of which may be a non-trivial exercise.
I think that in our case, it would be much more realistic to simply
convert existing load module PDS libraries into a PDS/E program library
of the same name rather than try to maintain dual libraries for pre- and
post-V5. That way you immediately eliminate the overhead and potential
errors of a massive amount of production JCL changes and minimize the
changes in existing production install procedures.
One unknown which could be a potential problem is how much more space
must be allocated to the libraries when they become a PDS/E. Not only
does the PDS/E 4KiB block size tend to be sub-optimal for track usage,
but it sounds like V5 COBOL programs will by default include much
non-code information for debugging usage which will gradually require
additional library space as more code is recompiled under V5. If this
pushes a library size beyond the capacity of existing installation
volumes, the lack of multi-volume PDS/E support may require some massive
restructuring of existing application library families.
So while it may be true that V5 does not require that you convert
existing load libraries to PDS/E, if you don't convert and instead
introduce a new library, you will likely expend much more effort in the
long run on production JCL changes and put production jobs at more
additional risk than you save by not converting the libraries to PDS/E
program libraries in the first place. (I'm assuming here there is not
some subtle reason I'm overlooking that would prevent just converting
the PDS to PDS/E without recompiling everything.) The big problem for
some will be that they will have to take some application down time to
quiesce all usage of a library in order to rename it (for backup) and
create a new PDS/E version; but you would have to take a long-running
application down anyhow in order to add a new PDS/E library with a
different name.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
