I think that's a good summary, Joel, of some of the considerations in how
to go about adopting PDSEs. Thanks. Though I would point out that many/most
of those considerations are not necessarily *unique* to this particular
compiler upgrade. Juggling multiple libraries and changing build/test/run
processes can happen in lots of other circumstances. I also agree with your
point that change management tooling (and actually using it) is very
valuable. (That's not an advertisement: SCLM is part of base z/OS, as one
example.)
Each shop is probably going to be a little different. To elaborate on some
points you raised, most shops tend to have application/functional "zones"
of one sort or another. As examples, there are runtime zones (batch, CICS,
IMS, DB2 stored procedures, etc.), line of business zones (credit card,
core banking, inventory, ordering, customer service, etc.), LPAR
separations, development sub-teams, and so on. What I'm calling a "zone" is
some specific vector of COBOL program separations, e.g. "Zone ABC1" could
be { LPAR MVSA, batch, customer service, account inquiry applications,
Kansas development team }. Some zones are "big," and others are "small,"
but the point is there's some logical separation in practically every shop.
One way to approach implementing PDSEs, then, is a hybrid approach. We've
already established that PDSEs are only required for holding COBOL binaries
compiled with Enterprise COBOL 5.1. Let's assume, for example, that in a
particular shop every COBOL program is today in PDSes, not PDSEs. One
upgrade approach might be to pick a "zone," apply the new build/test/deploy
processes only to that zone, and stop there for a little while. Within the
zone PDSes would be converted to PDSEs, but outside the zone they wouldn't.
Presumably the first zone would be chosen by weighing a few criteria such
as whether the zone is "small," its business criticality, that it
materially contributes to peak utilization, and/or that constraint relief
would be useful soonest.
I will insert here one "advertisement." If you need some particular help
with this upgrade, ask IBM. There is a new offering called "zEnterprise
Solution Edition for Application Development" that may be relevant if, for
example, you would have new testing requirements that would require more
capacity.
I want to comment briefly on something Ted brought up. I am guilty (as
charged) of championing business-relevant innovation, including COBOL
innovations. In that particular way I agree with John Gilmore: this
community must neither fall into nor perpetuate a zero change policy. That
way lies death and despair, and I'm not a fan. The right answer is balance,
and zero is way out of balance. We all know about and regularly observe
businesses that never adapt and then perish (or at least wither). Do not
let that happen if you can possibly avoid it.
I am not thrilled that there's a PDSE prerequisite for Enterprise COBOL
5.1. I don't like any prerequisites whatsoever if they can be avoided. In
this case, it couldn't be avoided. This path was the reasonable,
responsible technical choice in order to deliver to you, our great
customers (and to new customers) wonderful COBOL innovations, both
immediately and continuing over the long term. Compilers are both hard to
do and critically important, especially as microprocessor-related physics
keep getting more challenging. This new backend puts COBOL firmly back on
the development path it deserves as one of (if not the) preeminent
enterprise programming languages. I couldn't be more thrilled about that.
Anyway, I'm going to be very focused on figuring out how to help customers
address this prerequisite and get it behind them as quickly and
cost-effectively as possible, and with minimum risk, so that they can start
enjoying Enterprise COBOL 5.1's benefits. If I can also help champion ways
to make this path even easier, I'll do that, too.
--------------------------------------------------------------------------------------------------------
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
