PDSE supported for product dataset z/OS version

[Nathan Astle]

Hello,

Are there any information starting from which version of z/OS, the Product
load modules datasets can be created as PDSE ?

Nathan

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

[R.S.]

W dniu 2016-09-22 o 13:43, Nathan Astle pisze:

> Hello,
>
> Are there any information starting from which version of z/OS, the Product
> load modules datasets can be created as PDSE ?

1.1
PDSEs were available long before z/OS brandname was born.

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kon...@mBank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.

[Tom Marchant]

On Thu, 22 Sep 2016 13:48:42 +0200, R.S. <R.Sko...@BREMULTIBANK.COM.PL> wrote:

>PDSEs were available long before z/OS brandname was born.

Executable code could be stored in PDSE starting with MVS 4.3 in 1992.
From the General Information manual:

<quote>
Additional MVS/ESA SP 4.3 support with DFSMS/MVS allows users to store and
load executable code in a partitioned data set extended (PDSE). Users can
create and manage loaded modules and load libraries in PDSEs with the same
data management techniques as other PDSEs.
</qoute>

--
Tom Marchant

[Joel C. Ewing]

On 09/22/2016 07:30 AM, Tom Marchant wrote:
> On Thu, 22 Sep 2016 13:48:42 +0200, R.S. <R.Sko...@BREMULTIBANK.COM.PL> wrote:
>
>> PDSEs were available long before z/OS brandname was born.
> Executable code could be stored in PDSE starting with MVS 4.3 in 1992.
> From the General Information manual:
>
> <quote>
> Additional MVS/ESA SP 4.3 support with DFSMS/MVS allows users to store and
> load executable code in a partitioned data set extended (PDSE). Users can
> create and manage loaded modules and load libraries in PDSEs with the same
> data management techniques as other PDSEs.
> </qoute>
>

Perhaps a better question would be when did IBM and the MVS user
community actually have enough confidence in PDSE reliability to start
distributing products with PDSE program libraries, especially ones that
needed to go in the LNKLST concatenation.

My recollection is that PDSEs did have a significant number of issues
for a number of years including data-loss and availability APARs. You
had to have a strong need for some of the unique PDSE features to take
the risk in the early years. About the only way to corrupt a PDS was
to open one improperly, and with the most common error (attributes
change) most of the damage was easily repairable. We had a number of
cases (more than 1, less than 10, at least 2 night calls) in the early
PDSE years where access rules were not violated and an entire PDSE
became corrupted and unreadable and also at least one case where a PDSE
became hung and inaccessible until next IPL! That would have been a
much more serious issue for us had those incidents involved a product
program library instead of just an application data library..
Joel C. Ewing

--
Joel C. Ewing, Bentonville, AR jce...@acm.org

[R.S.]

W dniu 2016-09-22 o 15:36, Joel C. Ewing pisze:

> On 09/22/2016 07:30 AM, Tom Marchant wrote:

It was 25 years ago. Things changed. Nowadays the most popular way to
destroy PDSE is to share it across sysplexes.
In my shop we use PDSE from day 0 (~18 years) with no issue except very
few cases of improper sharing.
People who are reluctant to use PDSE have ... no choice. Many system
libraries are PDSE with no option to switch to PDS (the opposite way
covers 99% of system libraries). Now, COBOL v5 and v6 do require PDSE
for linked binaries.

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kon...@mBank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.

[Elardus Engelbrecht]

Radoslaw Skorupka wrote:

>It was 25 years ago. Things changed.

Indeed.

>Nowadays the most popular way to destroy PDSE is to share it across sysplexes.

Or using undocumented or wrong system services to use them... If you do those stunts across sysplexes, I'm running away.

>People who are reluctant to use PDSE have ... no choice.

Too bad... Too sad. Consider using PDSESHARING(EXTENDED)

Some of my ICETOOL jobs crashed (OPEN abend) because of too many PDS members opened to write/overwrite.

Solved that by moving over to PDSE instead having to use lots of PDS datasets with fewer members. [1]

>Now, COBOL v5 and v6 do require PDSE for linked binaries.

We're not there (at 4.2.0), but trust me, our programmers will faint when they find out about that requirement. ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - I have considered using temp PS datasets as output instead of permanent PDS/PDSE members, but I want to see the contents long after the ICETOOL jobs were purged.

[Jesse 1 Robinson]

Just keep in mind that AFAIK opening a PDSE still requires SMS to be active. That means that certain libraries opened very early in IPL must still be standard PO.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robi...@sce.com

[John Eells]

Jesse 1 Robinson wrote:
> Just keep in mind that AFAIK opening a PDSE still requires SMS to be active. That means that certain libraries opened very early in IPL must still be standard PO.

<snip>

I don't recall whether SMS must be active to open a PDSE (managed or
not), but the reason why you can't use PDSEs early in IPL processing
(think "parmlib concatenation or LPA list") is more prosaic. Much of
the code needed to process PDSEs lives in LPA. Until CLPA is done, they
cannot be opened.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

[Clark Morris]

[Default] On 22 Sep 2016 09:59:39 -0700, in bit.listserv.ibm-main

ee...@US.IBM.COM (John Eells) wrote:

>Jesse 1 Robinson wrote:
>> Just keep in mind that AFAIK opening a PDSE still requires SMS to be active. That means that certain libraries opened very early in IPL must still be standard PO.
><snip>
>
>I don't recall whether SMS must be active to open a PDSE (managed or
>not), but the reason why you can't use PDSEs early in IPL processing
>(think "parmlib concatenation or LPA list") is more prosaic. Much of
>the code needed to process PDSEs lives in LPA. Until CLPA is done, they
>cannot be opened.

This baffles me. It is like not being able to use SNA 327x channel
attached devices as consoles. Code for handling both could be put in
the above the line portion of the nucleus. It probably is too late
for it to be worthwhile to add the code for local SNA devices since
there are other ways of handling consoles but the ability to at least
read PDSEs at NIP time still would have value. As someone who wants
to see a transition to FBA devices, I see the current handling of PDSE
as an obstacle.

Tangential to this I also would like to see GDG capability for VSAM
ESDSs. I would not spend money trying to make QSAM and PDS data sets
FBA capable since there are FBA alternatives. IBM could tell the
owners of JES2 and JES3 to see how VM, VSE and AIX handled the issue
of FBA spool data sets and authorize them to "steal" the code.

[Paul Gilmartin]

On Thu, 22 Sep 2016 12:59:53 -0400, John Eells wrote:
>
>..., but the reason why you can't use PDSEs early in IPL processing

>(think "parmlib concatenation or LPA list") is more prosaic. Much of
>the code needed to process PDSEs lives in LPA. Until CLPA is done, they
>cannot be opened.
>

Does this imply that program objects can never be in LPA, not merely
that such objects can't be accessed until late in the IPL processing?

Does that imply that soon COBOL programs will not be eligible for LPA?

-- gil

[John Eells]

Paul Gilmartin wrote:
> On Thu, 22 Sep 2016 12:59:53 -0400, John Eells wrote:
>>
>> ..., but the reason why you can't use PDSEs early in IPL processing
>> (think "parmlib concatenation or LPA list") is more prosaic. Much of
>> the code needed to process PDSEs lives in LPA. Until CLPA is done, they
>> cannot be opened.
>>
> Does this imply that program objects can never be in LPA, not merely
> that such objects can't be accessed until late in the IPL processing?
>
> Does that imply that soon COBOL programs will not be eligible for LPA?

They cannot be in (E)PLPA. They can be in Dynamic LPA.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

[Peter Relson]

> Does this imply that program objects can never be in LPA, not merely
> that such objects can't be accessed until late in the IPL processing?

No. At least "no" based on the meaning of LPA. But perhaps you meant PLPA.

> Does that imply that soon COBOL programs will not be eligible for LPA?

No. Similarly.

Program objects (in PDSEs) have been eligible for dynamic LPA since
dynamic LPA was introduced.
They have not been, and will likely never be, eligible for PLPA, MLPA, or
FLPA.

So it is the case that newer-version COBOL programs are not eligible for
PLPA, MLPA, or FLPA.

Prior to z/OS 1.11, the earliest you could reasonably get program objects
into (dynamic) LPA was via a statement in COMMNDxx.

As of z/OS 1.11, you can use "deferred LPA Wait" to put LPA statements in
the IPL-time PROGxx and have them processed at the tail end of IPL.
An application that needs to know if that deferred LPA processing has
completed can use the CSVDLPAW program or the CSVDYLPA REQUEST=DEFLPAWAIT
programming interface.

Jim Mulder pointed out to me that the PROGxx documentation is incorrect in
having failed to delete a relevant statement.

What is there and correct (under "using the LPA statement")
Use the LPA statement to specify:
-- Modules that are to be added to the LPA at the end of the IPL. This is
needed only for program objects within PDSEs but can be used for load
modules within PDSs.
-- etc


What is there and incorrect (under "syntax format of the LPA statements")
and will be removed:
Note: LPA ADD and LPA DELETE cannot be used during IPL. They are for use
in PROGxx members pointed to by SET PROG=xx after IPL.

Peter Relson
z/OS Core Technology Design

[Elardus Engelbrecht]

Peter Relson wrote:

>Jim Mulder pointed out to me that the PROGxx documentation is incorrect in having failed to delete a relevant statement.

>What is there and correct (under "using the LPA statement")
>Use the LPA statement to specify:
>-- Modules that are to be added to the LPA at the end of the IPL. This is needed only for program objects within PDSEs but can be used for load modules within PDSs.

In what z/OS release(s) will those statements be corrected? From v1.11 to v2.2? Or just current supported versions?

Many thanks for this note. I believe this should be of great value!

Thanks!

Groete / Greetings
Elardus Engelbrecht

[Peter Relson]

>In what z/OS release(s) will those statements be corrected?

Books from old releases, whether supported releases or unsupported
releases, are typically not updated.
It is possible the update will show up in the 2.2 release; I would think
that it is unlikely to be made in any release earlier than that.

The only difference between this support and placing commands in COMMNDxx
is that the deferred LPA approach gives an application a way to wait for
the completion (and, by the way, no one ever brought up the lack of such
an approach as a problem; it just seemed like a potential problem to me).

Having such "waiting" happen automatically is something that we would not
impose on a customer, as it could delay the completion of IPL (many
applications would not need to wait). Whether that is a noticeable delay
or not depends on how much is to be done. But having it be an option is
fair game. Feel free to submit a req for such an option.

Peter Relson
z/OS Core Technology Design