Oppolzer - Informatik / Blog

Triggered by an offline answer, I had the idea that it could be a good idea to
post this on the PL/1 list, too.

Today at one of our sites (the "old" one), we build normal load modules which
reside in conventional PDS libraries. This is due to the fact that the modules
are compiled using NORENT and we don't need newer options like DLL and LONGNAME
etc.

Now I heard about COBOL V5 supporting only program objects and thus having the
need for PDSEs as output libraries.

Are there plans for PL/1, too? I heard that in the future all compilers will
share the same code generation backend.

If so, we have some work to do, because our home grown change management system
only deals with PDS target libraries at the moment - I'm not sure how expensive
it will be to change that. The CCM system copies load modules at installation
time to the target nodes, at the moment ...

Kind regards

Bernd



-------- Original-Nachricht --------
Betreff: Re: PDS/E, Shared Dasd, and COBOL V5
Datum: Fri, 20 Sep 2013 11:23:37 +0200
Von: Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>
Antwort an: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
An: IBM-MAIN@LISTSERV.UA.EDU
Newsgruppen: bit.listserv.ibm-main

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 T.S.:
> 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.
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN