My read from previous remarks in this thread is that IBM's long-term
direction is toward program objects and PDSEs for all compilers, because
that sounds like the only easy way to provide new features and also
provide a common run-time environment and debugging capability across
multiple source languages. Even if it were a while before PL/I forces
the issue like COBOL V5, you might hit some future installation need to
inter-operate with C or COBOL code that might force the issue earlier
than the PL/I compiler; so I would be giving thought to what it would
take to adapt.
We also had home-grown tools, built with compiled REXX, to control
compile job generation, source, compile listings, DBRM, and binary
management; but it either used ISPF functions or standard IBM utilities
for transport between libraries, so adapting it to support a PDSE in
specific cases required some adjustment but was not a major code
re-write. If your physical transport of members between libraries is
currently handled by installation code, you have a more difficult
re-write, since my understanding is you pretty much have to invoke the
Binder to create a program object in a PDSE.
While I agree with Timothy that the concept and usage of separate
"zones" is no doubt common and familiar to most installations, that
still doesn't mean that a purturbation to existing design would be
trivial to implement. We had around 15 distinct application development
areas, each supporting maintenance of existing code plus code
development for new functionality; each with test, production, and
backup "zones"; and in-house tools that enforce the proper usage of
those zone libraries and member naming standards for the application
areas. An approach that requires adding a program library for each zone
may seem reasonable when only two or three zones are involved, but looks
much less reasonable when 45 zones are involved. Our TechSys
application area is one case that might require some significant
redesign: it has a load module PDS library currently containing mostly
non-COBOL but some COBOL code. Occasionally some of those modules are
manually moved to PDS LPA libraries or to 3rd-party-vendor PDS
libraries, which sounds like a problem if the application load module
library were forced to become a PDSE. I'm sure there are ways to deal
with that, but the best approach in the context of our existing tools is
not obvious without further study.
Joel C Ewing
On 09/20/2013 04:23 AM, Bernd Oppolzer wrote:
> I followed this thread quietly for a long time, but now I'd like to ask
> some questions
> related to our site, if I'm allowed to do so:
>
> - we are PL/1, not COBOL, but I believe that we will have this issue in
> the not so
> far future too, is this true?
>
> - we have a home grown tool which does the transports of the binaries
> into the
> different zones mentioned below. In the moment this tool assumes that the
> target libraries in all those zones are PDSes, and, more important, that
> they
> are all of the same type. So for us there is some investment, if they
> have to
> be converted to PDSEs and if they are different for the different zones
> (during
> migration time). So this is a project for us, and not a small one.
> That's why
> I am concerned about knowing early about such plans regarding PL/1.
>
> Thanks,
> kind regards
>
> Bernd
>
>
>
> Am 20.09.2013 05:37, schrieb Timothy Sipples:
>> 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.
>>
>
--
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
