Oppolzer - Informatik / Blog

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

PL1-L - Ausgabe von Lademodulen bzw. Programmobjekten nur noch auf PDSE?


PDS/E, Shared Dasd - PL/1 too?


Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>


PL1 (language) discussions <PL1-L@LISTSERV.DARTMOUTH.EDU>


2013.09.20 15:34:52

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

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


-------- 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>
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.

kind regards


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

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie