PDS vs PDSE

[John R. Ehrman (408-463-3543 T/543-)]

I posted the original question on behalf of a colleague who was
curious about customer views; I've been forwarding comments to him.
John Ehrman
(-- Referenced Note Follows )
Date:Mon, 22 Feb 2010 07:21:05 -0600
From:Barbara Nitz 
Subject: Abysmal PDSE performance

<...>
So, now that John Ehrman has managed to get the PDSE discussion started,
he is conspiciously absent from the discussion

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Shmuel Metz (Seymour J.)]

In , on 02/18/2010
   at 09:23 PM, "Robert A. Rosenberg"  said:

>There is print server support where individual machines on the  network
>send their program's output to a Print Server which stores  the printout
>and then sends it to printers.

The problem is that there's more than one flavor. Which one is *the* SPOOL
support?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Vernooij, CP - SPLXM]

"Barbara Nitz"  wrote in message
news:...
> >Well, I can add another problem to the list: since 2 days we have a
> >ghost connection to a PDSE directory. We can't delete the PDSE
because
> >"someone" has a connection to the directory, but we have no idea who
and
> >there is no Enq for the PDSE, which is the way to find the holder of
the
> >connection according to the DFP Diagnoses guide.
> >
> >Time for a new PMR.
> 
> Sounds familiar. In our case it was an HFS latch that was the ghost, 
> preventing any new HFS access. Cause was a silently corrupted HFS, 
> corrupted probably 6 months before. IBM response 'We don't care, there
are 
> two ptfs you're missing, and the data set was corrupted way back
when.'
> 
> SMSPDSE or SMSPDSE1? Did you try to restart SMSPDSE1?
> 
> You may want to take a dump and try the (now documented) PDSE verbx's.

> One of those gave us the TCB address holding that latch, and with the
callrtm 
> program I was able to terminate *that* tcb, thus freeing the ghost. We
IPL'd 
> during the night. Might be better all around than waiting for IBM.
> 
> Best regards, Barbara Nitz
> 

It is SMSPDSE1 and I did not restart it. In problem is not urgent, the
PDSE is not used anymore and is not causing problems in this situation.
I am waiting for IBM to see what information they need and I don't want
to wipe it out by trying things. An IPL is scheduled in 2 weeks, so that
should be enough for them to gather all the information they need.

This morning I discovered another PDSE with the same problem. There
might be a relation between the two in the way they were manipulated in
the past weeks. Very interesting.

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Barbara Nitz]

>Well, I can add another problem to the list: since 2 days we have a
>ghost connection to a PDSE directory. We can't delete the PDSE because
>"someone" has a connection to the directory, but we have no idea who and
>there is no Enq for the PDSE, which is the way to find the holder of the
>connection according to the DFP Diagnoses guide.
>
>Time for a new PMR.

Sounds familiar. In our case it was an HFS latch that was the ghost, 
preventing any new HFS access. Cause was a silently corrupted HFS, 
corrupted probably 6 months before. IBM response 'We don't care, there are 
two ptfs you're missing, and the data set was corrupted way back when.'

SMSPDSE or SMSPDSE1? Did you try to restart SMSPDSE1?

You may want to take a dump and try the (now documented) PDSE verbx's. 
One of those gave us the TCB address holding that latch, and with the callrtm 
program I was able to terminate *that* tcb, thus freeing the ghost. We IPL'd 
during the night. Might be better all around than waiting for IBM.

Best regards, Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Vernooij, CP - SPLXM]

"John R. Ehrman  , 408-463-3543 T/543-"  wrote in
message news:...
> PDSEs have been available for a long time, and provide many
> advantages over PDSs. Why are people reluctant to use PDSEs?
> John Ehrman
> 

Well, I can add another problem to the list: since 2 days we have a
ghost connection to a PDSE directory. We can't delete the PDSE because
"someone" has a connection to the directory, but we have no idea who and
there is no Enq for the PDSE, which is the way to find the holder of the
connection according to the DFP Diagnoses guide.

Time for a new PMR.

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Robert A. Rosenberg]

At 16:31 -0500 on 02/17/2010, Shmuel Metz (Seymour J.) wrote about 
Re: PDS vs. PDSE:



I don't see that. The printer support in windoze and *ix is quite ad hoc.
In the case of *ix it's hard to say what the SPOOL support is? I'm tempted
to say cups, but that's questionable.


There is print server support where individual machines on the 
network send their program's output to a Print Server which stores 
the printout and then sends it to printers. That seems to me to be 
the same thing as SPOOL support (multiple programs offloading their 
printout for a centralized program to actually sent to the printer).


CUPS DOES qualify (check out the Wikipedia entry) and in addition has 
to do with decoupling the print format from the output format needed 
for the printer (also covered in the article).


In Mailframe terms, the latter function has to do with the difference 
between printing to a Line Printer and a Laser Printer (same input 
file with content, different format of data sent to the respective 
printers).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Shmuel Metz (Seymour J.)]

In , on 02/17/2010
   at 01:54 PM, Clark Morris  said:

>Since executables can exist in zFS, would the smarter long term strategy
>be to migrate PDSE to zFS and dead end PDSE?

How about stealing some ideas from TSS?

>pecialized SPOOL and PDS were
>good ideas on the 360 and met real needs.  The Linux/Unix/Windows
>environments seem to have constructs that are more flexible and meet the
>needs well.

I don't see that. The printer support in windoze and *ix is quite ad hoc.
In the case of *ix it's hard to say what the SPOOL support is? I'm tempted
to say cups, but that's questionable.


 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[R.S.]

W dniu 2010-02-18 15:35, Bill Fairchild pisze:

A PDS can have many small members occupying a single track, but not a single 
block, unless the many members are all aliases that resolve into the same 
member.


Yes, I know that, thank you for the correction. This third or fourth 
correction to single mistake.
I also would like to thank in advance to anyone who voluntary would like 
to tell me that I was wrong in that area. ;-)))


BTW: It seems I misunderstood redbook called PDSE. I read it many years 
ago and understood it in wrong way. Or it was some vagueness in the 
book? I'm going to check it again.



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Bill Fairchild]

A PDS can have many small members occupying a single track, but not a single 
block, unless the many members are all aliases that resolve into the same 
member.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
R.S.
Sent: Friday, February 12, 2010 1:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

In PDS you can have many small member occupying 
single block.

-- 
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Rick Fochtman]

--


The system structures designed into S/360 that turned into bottlenecks sooner than most others 
did were built around the cKd architecture, in which the K is uppercased because it means KEY 
(where  "KEY rhymes with "bad, bad, bad").  Real key areas were written onto 
DASD tracks for system catalogs, PDS directories, VTOC records (DSCBs), PASSWORD data set (I 
think), all ISAM files, and users also had the capability of creating keyed records with 
physical keys in BDAM, BPAM, and SAM files if they wanted to.  System catalogs were eventually 
replaced with VSAM structures, PDS directories were supposed to have been ameliorated with 
PDSEs, and VTOC keyed record searches were ameliorated with Indexed VTOCs.  ISAM support was 
eventually dropped by IBM.  All those keys seemed to make good sense in 1965, but not any 
more.  No CKD DASDs have been manufactured, that I know of, for 15 or 20 years.  Everything is 
FBA and RAID now.  Hardware microcode emulates physical keys.  Lots of opera!

ting system software supports keys, which are still used sometimes as a lock 
controlling access to the record's data area.  Some sophisticated users 
invented other clever uses for keys.
 


-
You forgot SYS1.BRODCAST  :-))

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Bill Fairchild]

The system structures designed into S/360 that turned into bottlenecks sooner 
than most others did were built around the cKd architecture, in which the K is 
uppercased because it means KEY (where  "KEY rhymes with "bad, bad, bad").  
Real key areas were written onto DASD tracks for system catalogs, PDS 
directories, VTOC records (DSCBs), PASSWORD data set (I think), all ISAM files, 
and users also had the capability of creating keyed records with physical keys 
in BDAM, BPAM, and SAM files if they wanted to.  System catalogs were 
eventually replaced with VSAM structures, PDS directories were supposed to have 
been ameliorated with PDSEs, and VTOC keyed record searches were ameliorated 
with Indexed VTOCs.  ISAM support was eventually dropped by IBM.  All those 
keys seemed to make good sense in 1965, but not any more.  No CKD DASDs have 
been manufactured, that I know of, for 15 or 20 years.  Everything is FBA and 
RAID now.  Hardware microcode emulates physical keys.  Lots of operat!
 ing system software supports keys, which are still used sometimes as a lock 
controlling access to the record's data area.  Some sophisticated users 
invented other clever uses for keys.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
McKown, John
Sent: Thursday, February 11, 2010 7:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

Does anything other than S/360 derived systems even use CKD type DASD? PDS 
directories are built around CKD. And, in their day, moving the search logic 
out to the peripheral was probably a good idea.

--
John McKown 
Systems Engineer IV
IT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Paul Gilmartin]

On Wed, 17 Feb 2010 13:54:43 -0400, Clark Morris wrote:
>>>
>Since executables can exist in zFS, would the smarter long term
>strategy be to migrate PDSE to zFS and dead end PDSE?  The PDSE

As soon as they allow Unix directories in my STEPLIB concatenation.
(And LINKLIST.)

But no aliases for program objects in Unix directories.  Rather,
such programs must inspect argv[ 0 ] and branch to the proper
label.

>construct suffers from a number of problems including 8 character
>member names and having to emulate the PDS.  This also could be the

As soon as EXEC PGM=, LOAD, LINK, and ATTACH allow longer names.

>migration path for SPOOL data sets.  Specialized SPOOL and PDS were

Amen.

>good ideas on the 360 and met real needs.  The Linux/Unix/Windows

Sicut erat in principio ...

>environments seem to have constructs that are more flexible and meet
>the needs well.  The major area of work might be handling of DCB type
>attributes if that is needed to be done.
>
FILEDATA=RECORD is a step in the direction of that compatibility.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Clark Morris]

On 17 Feb 2010 05:39:17 -0800, in bit.listserv.ibm-main you wrote:

>Bruce Hewson of the IBM Mainframe Discussion List 
>wrote on 02/17/2010 04:09:59 AM:
>
>> Hello John,
>>
>> there have been many responses.some positive some negative...this is
>> another negative I am sorry!
>>
>> 1.  Our developers still regularly break PDSEand we are still getting
>new
>> APARs assigned as a result.
>>
>> 2.  With CICS regions always UP! and connected, the PDSE's do not do
>auto-
>> compress and release.
>>
>> 3.  And we still break PDSE!
>>
>> so the rule here still is "No PDSE for production applications
>> unless absolutely
>> required".
>>
Since executables can exist in zFS, would the smarter long term
strategy be to migrate PDSE to zFS and dead end PDSE?  The PDSE
construct suffers from a number of problems including 8 character
member names and having to emulate the PDS.  This also could be the
migration path for SPOOL data sets.  Specialized SPOOL and PDS were
good ideas on the 360 and met real needs.  The Linux/Unix/Windows
environments seem to have constructs that are more flexible and meet
the needs well.  The major area of work might be handling of DCB type
attributes if that is needed to be done.

>> On Wed, 10 Feb 2010 11:46:57 -0800, John R. Ehrman (408-463-3543 T/543-
>> )  wrote:
>>
>>>PDSEs have been available for a long time, and provide many
>>>advantages over PDSs. Why are people reluctant to use PDSEs?
>>>John Ehrman
>
>PDSE is not BPAM and it never will be.  If IBM would open up the doc on the
>clandestine Media Manager, then maybe the ISV's could develop some tools (a
>la catalog recovery).  PDSE is a file system that needs real-time
>transaction backout and recovery.  SYSCTLG and SYS1.SYSJOBQE had similar
>problems back in the day.
>
>Regards,
>John K
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[John P Kalinich]

Bruce Hewson of the IBM Mainframe Discussion List 
wrote on 02/17/2010 04:09:59 AM:

> Hello John,
>
> there have been many responses.some positive some negative...this is
> another negative I am sorry!
>
> 1.  Our developers still regularly break PDSEand we are still getting
new
> APARs assigned as a result.
>
> 2.  With CICS regions always UP! and connected, the PDSE's do not do
auto-
> compress and release.
>
> 3.  And we still break PDSE!
>
> so the rule here still is "No PDSE for production applications
> unless absolutely
> required".
>
> On Wed, 10 Feb 2010 11:46:57 -0800, John R. Ehrman (408-463-3543 T/543-
> )  wrote:
>
>>PDSEs have been available for a long time, and provide many
>>advantages over PDSs. Why are people reluctant to use PDSEs?
>>John Ehrman

PDSE is not BPAM and it never will be.  If IBM would open up the doc on the
clandestine Media Manager, then maybe the ISV's could develop some tools (a
la catalog recovery).  PDSE is a file system that needs real-time
transaction backout and recovery.  SYSCTLG and SYS1.SYSJOBQE had similar
problems back in the day.

Regards,
John K

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Bruce Hewson]

Hello John, 

there have been many responses.some positive some negative...this is 
another negative I am sorry!

1.  Our developers still regularly break PDSEand we are still getting new 
APARs assigned as a result.

2.  With CICS regions always UP! and connected, the PDSE's do not do auto-
compress and release.

3.  And we still break PDSE!

so the rule here still is "No PDSE for production applications unless 
absolutely 
required".

On Wed, 10 Feb 2010 11:46:57 -0800, John R. Ehrman (408-463-3543 T/543-
)  wrote:

>PDSEs have been available for a long time, and provide many
>advantages over PDSs. Why are people reluctant to use PDSEs?
>John Ehrman
>



Regards
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Shmuel Metz (Seymour J.)]

In <4b750586.5040...@bremultibank.com.pl>, on 02/12/2010
   at 08:38 AM, "R.S."  said:

>In PDS you can have many small member occupying 
>single block.

No way, Jos‚. The only ways that two members share a block are with an
alias or with a corrupted PDS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE - z/OS 1.11 SMPPTS in Serverpac

[Paul Gilmartin]

On Sat, 13 Feb 2010 15:48:56 -0600, Mark Zelden wrote:
>
>What IBM really really needs (hint!) is a tag for GIMUNZIP to control
>the SYSUT1 dynamic allocation on a data set by data set basis if needed.  I
>could have then pointed SYSUT1 to a spare volume just for the SMPPTS
>unzip instead of having the storage admins initialize a spare volume
>for SMS and add it to the temp pool... all just to run 1 job. 
>
What IBM really needs is to:

1) Enhance IEBCOPY to accept Unix files and pipes as its PS files
   (not its PDS files, a much bigger effort, and for which pax
   already exists).

2) Restructure the GIMZIP archive so the relfiles are simply
   compressed IEBCOPY-unloaded PDSes, not pax archives.

Consider the index of a modest GIMZIPped relfile:

503 $ gunzip http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE - z/OS 1.11 SMPPTS in Serverpac

[Mark Zelden]

On Sat, 13 Feb 2010 13:48:34 -0600, Mark Zelden 
wrote:

>Speaking of PDSE... why does the z/OS 1.11 Serverpac require the SMPPTS
>to be PDSE?  The CH TYPE command doesn't let one change it to PDS.
>
>Is there something new with z/OS 1.11 that requires the SMPPTS associated
>with the z/OS zones to be PDSE that I missed hearing about?
>

Answering my own post:

Perhaps because it can potentially be over 65K tracks?   I am running
the ServerPac RESTORE job now (while "baby sitting" at a DR exercise) and
I had a heck of a time with the SMPPTS restore.   My driving system LPAR
has 3 virtually empty 3390-3 volumes for the temp sms pool but the
!...@#&^% GIMUNZIP program dynamically allocates SYSUT1 for each
file it unzips and all of the allocation parms are hard coded. You can't
override it in JCL.

See APARs IO10377 & IO07810 for more info.

After having a mod-27 added to the pool temporarily, I can see the
work file it allocated to SYSUT1 ended up being 64949 tracks, which
of course was bigger than any of the 3390-3 volumes in the temp
pool.

What IBM really really needs (hint!) is a tag for GIMUNZIP to control
the SYSUT1 dynamic allocation on a data set by data set basis if needed.  I 
could have then pointed SYSUT1 to a spare volume just for the SMPPTS
unzip instead of having the storage admins initialize a spare volume
for SMS and add it to the temp pool... all just to run 1 job. 

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

PDS vs. PDSE - z/OS 1.11 SMPPTS in Serverpac

[Mark Zelden]

Speaking of PDSE... why does the z/OS 1.11 Serverpac require the SMPPTS
to be PDSE?  The CH TYPE command doesn't let one change it to PDS.

Is there something new with z/OS 1.11 that requires the SMPPTS associated
with the z/OS zones to be PDSE that I missed hearing about?  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Paul Gilmartin]

On Thu, 11 Feb 2010 06:54:21 -0600, Elardus Engelbrecht wrote:
>
>"PDSE processing is planned to be changed to reduce delays that can occur
>when two systems are accessing a PDSE concurrently while it is being
>updated. PDSE will be designed to improve its cross-system sharing
>capabilities, including member-level sharing, within a GRS complex but outside
>a Parallel Sysplex. These changes are intended to make PDSEs more usable
>outside single-system and Parallel Sysplex environments."
>
Valuable as such sharing will be to me, I'm restraining my jubilation.

o Is this likely to seed a deluge of APARs, similar to the liberation
  of PDSE from SMS?

o Downward compatibility.  If a GRS complex contains systems at
  1.12, and others at lower levels, will the facility be available,
  even among the 1.12 systems, before all systems are at 1.12?

o Upward compatibility.  Will a conversion operation be necessary?

>"New PDSE functions are planned. A new utility will be designed to verify that
>the structure of a PDSE is valid, and programming services will be designed to
>perform similar checking to help programs verify the state of a PDSE before
>and after critical operations. These new functions are intended to help you
>detect errors in PDSE structures that might otherwise go undetected."
>
Wow!  They've invented fsck!

--gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Paul Gilmartin]

On Sat, 13 Feb 2010 10:24:22 -0600, Joel C. Ewing wrote:
>
>Using a PDS the physical size of the library stabilized at under 5
>cylinders.  We were surprised to find that as a PDSE the table grew to
>many extents and over 100 cylinders before it stabilized!  It appears
>that ISPF leaves table library member references hanging after use in
>such a way that the PDSE was in many cases unable to reuse the deleted
>space until the TSO/ISPF session ended.  Near the end of a working day
>we would see the in-use space on the ISPF table PDSE approach 100+
>cylinders, and then once all users had logged off it would drop back
>down to around 1 cylinder in use, and repeat the pattern the next day.
>
There's a sore need for PDSE to provide an interface for releasing
such hanging references.  And for applications developers to learm
to use such an interface if it happens.

But isn't ISPF using the wrong tool?  Wouldn't tables be better
saved in a facility designed for the purpose, such as VSAM,
rather than by abuse of PDS/PDSE?  (I believe SMP/E made exactly
such a conversion, long ago.)

Could ISPF tables be stored in Unix files with fewer problems?
(I doubt I could just allocate ISPPROF to a Unix directory and
have it work; it would require a redesign of ISPF.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Joel C. Ewing]

On 02/12/2010 11:25 AM, Guy Gardoit wrote:
>>  Does "wasted space" in PDSE's really matter all that much?  I'll bet no
>> one has al their PDS data set compressed 100% of the time - that's called
>> "wasted space" not to mention the constant battle with directory blocks.
>> PDSE's are not perfect but this stuff about "wasted-space" is just hot air
>> AFAIC
>>

As with all such questions, "it depends".

Some large PDSs may have low update activity, so that tuning directory
space and over allocating for deleted "gas" are not issues and space
usage by the PDS is very efficient.

Some PDSs are large enough that consistently finding enough free space
on a single 3390-9 to allocate a new copy may be problematic (and going
to larger devices may not yet be practical).  The additional space to
convert this to a PDSE can then be a major issue, as even without a need
to compress or resize the library, upon occasion one will need to
allocate a new copy to RESTORE backups or RECALL migrated versions.

If in addition the large PDS contains many very short members, the size
increase for the PDSE can be very substantial, perhaps exceeding the
capacity of a single drive, making allocation impossible.

That said, we still have cases where a PDSE is clearly the best choice,
mostly in cases where having to take down applications to resize or
compress a library would be a major issue.

We even had one bizarre application in which we chose to use a PDSE even
though the required file size went from 5 cylinders to over a 100,
because the PDSE was more reliable.  This was an ISPF Table library and
at the time we had an ISPF application which updated a fairly large
table 100's of times in the course of a day (and also many smaller
tables with a similar update rate).  Because of the way ISPF allows for
table padding, on a PDS many of these updates were "in place".  Every
couple of months, at a time when the system was maxed out and TSO slowed
down, someone would think their TSO session was hung and cancel it in
the middle of a large table update and totally trash the table.  With a
PDSE, there is no update-in-place, so while a cancellation might lose an
update, the table itself would not be corrupted.

Using a PDS the physical size of the library stabilized at under 5
cylinders.  We were surprised to find that as a PDSE the table grew to
many extents and over 100 cylinders before it stabilized!  It appears
that ISPF leaves table library member references hanging after use in
such a way that the PDSE was in many cases unable to reuse the deleted
space until the TSO/ISPF session ended.  Near the end of a working day
we would see the in-use space on the ISPF table PDSE approach 100+
cylinders, and then once all users had logged off it would drop back
down to around 1 cylinder in use, and repeat the pattern the next day.

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

"Charlie Gibbs"  writes:
> On the other hand, if you wrote 200-byte physical records on a
> CKD device, the overhead (inter-record gaps, count fields, etc.)
> would exceed 50%.

re:
http://www.garlic.com/~lynn/2010d.html#0 PDS vs. PDSE
http://www.garlic.com/~lynn/2010d.html#9 PDS vs. PDSE

DASD capacity forumulae ... from my conversion of gcard ios3720
http://www.garlic.com/~lynn/gcard.html#26.3

DASD Capacity Formulae

Device  Cyls   Tracks   Track   Bytes per record
type/pack   /cyl   capacitywithout keywith key
2305-1 48 8  14568  432+D  634+K+D
2305-2 96 8  14858  198+D  289+K+D
2314  20020   7294  101+(D)534/512 146+(K+D)534/512
   D (last on track)  45+K+D (last on track)
3330-140419  13165  135+D  191+K+D
3330-11   80819  13165  135+D  191+K+D
3340-35   34812   8535  167+D  242+K+D
3340-70   69612   8535  167+D  242+K+D
3350  55530  19254  185+D  267+K+D
3375  95912  36000  224+#(D+191)   224+#(K+191)+#(D+191)
Device  Cyls   Tracks   Track   Bytes per record

... snip ...

3375 is a physical 3370 FBA (512byte blocks) with CKD emulated on top.
All current CKD devices are actually physically fixed-block with CKD
emulated on top (and things are quite a bit more complex)

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Frank Swarbrick]

>>> On 2/11/2010 at 5:54 AM, in message
, Elardus Engelbrecht
 wrote:
> No-one said anything about corrupt PDSE during IPL... (or I have missed it.)
> 
> In z/OS v1.12 Preview this snippet:
> 
> "PDSE processing is planned to be changed to reduce delays that can occur 
> when two systems are accessing a PDSE concurrently while it is being 
> updated. PDSE will be designed to improve its cross-system sharing 
> capabilities, including member-level sharing, within a GRS complex but 
> outside 
> a Parallel Sysplex. These changes are intended to make PDSEs more usable 
> outside single-system and Parallel Sysplex environments."

This one looks like the answer to our prayer.
So when is 1.12 due?  :-)  Late 2010 I am assuming...

Frank




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Guy Gardoit]

>
>  Does "wasted space" in PDSE's really matter all that much?  I'll bet no
> one has al their PDS data set compressed 100% of the time - that's called
> "wasted space" not to mention the constant battle with directory blocks.
> PDSE's are not perfect but this stuff about "wasted-space" is just hot air
> AFAIC
>



-- 
Guy Gardoit
z/OS Systems Programming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


peter.far...@broadridge.com (Farley, Peter x23353) writes:
> PMFJI here, but the facts that Media Manager underlies these "new" (FSVO
> "new") file technologies and that Media Manager is page-oriented in its
> use of disk storage *could* be taken as a sign (however faint and
> clouded) that IBM is (ver-r-ry slowly) moving towards direct support of
> FBA in z/OS, perhaps only for those file types supported by MM, perhaps
> eventually for all file types.
>
> Maybe one day a z/OS successor will IPL from the /boot file system?
>
> Wild and rampant speculation with just two chances of being right (slim
> and none, and slim is out to lunch), but interesting thoughts
> nonetheless.

re:
http://www.garlic.com/~lynn/2010d.html#0 PDS vs. PDSE

note that industry fixed-block has been 512 byte records ... & CKD
emulation on top of underlying fixed-block has its own space
inefficiencies (in addition to processing inefficiencies and
significantly increased complexity ... with all the associated costs
that complexity brings). 

however, the industry is started moving to larger fixed block size ...
(because of the per block physical overhead becoming increasing factor)

HDD Manufacturers Moving To 4096-Byte Sectors
http://hardware.slashdot.org/story/09/12/28/1422253/HDD-Manufacturers-Moving-To-4096-Byte-Sectors

Western Digital's Advanced Format: The 4K Sector Transition Begins
http://anandtech.com/storage/showdoc.aspx?i=3691
Western Digital brings Advanced Format to Caviar Green
http://techreport.com/discussions.x/18115

misc. past posts mentioning CKD, multi-track searches, etc
http://www.garlic.com/~lynn/submain.html#dasd

for some historical perspective ... original CMS filesystem was 800byte
physical blocks (logical fixed block) mapped on CKD dasd. One of the
features was that it provided for "small" record allocation ... i.e.
four independent 200byte records within 800byte physical record.  This
resulted in inefficiency since anytime a 200byte record was involved
... the whole 800byte record had to be read/written (cases where a
200byte physical record could just be written ... would involve first
having to read in the 800 byte physical record, update a 200 byte
portion and then write out the record).

Of course analogous stuff is seen today in real hardware when there is
updates in RAID5 environment.

In any case, direct support of 512byte fixed-block ... could still mean
certain inefficiencies for smaller records ... either optimize for space
(say allowing mapping of four 128byte blocks in single physical block)
or transfer (& "waste" the ondisk space).

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Mark Zelden]

On Fri, 12 Feb 2010 00:52:02 -0800, Ron Hawkins
 wrote:

>Barbara,
>
>
>> Puh, how do I go about finding this out? If any of this is specified in
>the
>> IGDSMS member, then we take whatever default IBM set. And these things
>> apparently don't *have* storage class, management class or dataclass. I
>just
>> tested, and they end up on hte volumes they do because I manually put them
>> there way back when. :-(
>> Should I try to get anything changed here?
>>
>
>That's what I was wondering about. The default for
>PDSE_HSP_SIZE|HSP_SIZE(nnn) is 0, and according to the Manual 0 disables
>PDSE Member Caching.
>
>   "You can use the HSP_SIZE parameter to request up to 2047
>megabytes for the PDSE hiperspace. You can indicate that the hiperspace is
>not to be created by setting HSP_SIZE to 0. If the hiperspace is not
>created, the system will not cache PDSE members.
>
>   On systems that are running in z/Architecture mode, by
>default the PDSE hiperspace is not created and PDSE member caching is
>disabled."
>
>You need to specify something to get PDSE member caching. I'm just wondering
>if this is tied to directory caching and buffer beyond close also.
>
>I think the default of 2GB should be enough for Directory cache, but it
>would be nice to know how your statistics support this.
>

Since OA11068 PDSE_HSP_SIZE has defaulted to 0 and you may want
to leave it that way since it can cause "high cpu" usage.  Also
PDSE_BUFFER_BEYOND_CLOSE(NO) can be left as the default since
the LNKLST is never closed.  This is assuming you are running SMSPDSE1.

This is what I have:

PDSE_RESTARTABLE_AS(YES)  
PDSE1_BUFFER_BEYOND_CLOSE(YES)
PDSE1_HSP_SIZE(256)   

All our Endevor controlled application libraries (product/qa/test) - loadlibs
and proclibs - are PDSE since around 2003 and we have never had any
problems.  At least none that weren't self inflicted.  :-)

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Farley, Peter x23353]

PMFJI here, but the facts that Media Manager underlies these "new" (FSVO
"new") file technologies and that Media Manager is page-oriented in its
use of disk storage *could* be taken as a sign (however faint and
clouded) that IBM is (ver-r-ry slowly) moving towards direct support of
FBA in z/OS, perhaps only for those file types supported by MM, perhaps
eventually for all file types.

Maybe one day a z/OS successor will IPL from the /boot file system?

Wild and rampant speculation with just two chances of being right (slim
and none, and slim is out to lunch), but interesting thoughts
nonetheless.

Peter

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Clark Morris
> Sent: Friday, February 12, 2010 8:35 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PDS vs. PDSE
 
> And all of the above is more painfully true because space is wasted by
> emulating CKD on FBA underneath the covers.  IBM "saved" 26 million by
> not implementing FBA in MVS when the other IBM operating systems could
> handle it.  IBM consistently made FBA data sets (VSAM, HFS, zFS, PDSE,
> Linear, Page) wasters of space in a CKD environment.  The "savings"
> has long since been overshadowed by the complexity of maintaining CKD
> in an environment where it is irrelevant instead of moving on.  The
> lack of strategic thinking strikes again.

This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Clark Morris]

On 11 Feb 2010 20:44:37 -0800, in bit.listserv.ibm-main you wrote:

>No one seems to have pointed out that even for large members requiring
>more than 4 KiB there is more wasted space for PDSE than for a PDS:
>Since all space allocation is in 4KiB blocks, one should expect on
>average 50% of the last block or 2 KiB per member to be wasted for all
>members, not just the short ones; although there could be pathological
>cases where this wastage approaches 4 KiB per member.  For a PDS the
>last block of a member uses a short physical block if there are not
>enough records to fill it, and the unused space can potentially be used
>for the following member.
>
>And, for those that have taken the trouble to optimize PDS blocksize
>with half-track blocking to maximize DASD track utilization, converting
>to PDSE and reverting back to a sub-optimal 4 KiB block size throws away
>close to 10% of the optimal track capacity on a 3390.
>
>With these factors to consider, the only way a PDSE can end up occupying
>less space than a PDS with the same data is when there is appreciable
>update activity to existing members and the PDS must be oversized to not
>run out of space between compresses, while the PDSE can eventually reuse
>deleted space.

And all of the above is more painfully true because space is wasted by
emulating CKD on FBA underneath the covers.  IBM "saved" 26 million by
not implementing FBA in MVS when the other IBM operating systems could
handle it.  IBM consistently made FBA data sets (VSAM, HFS, zFS, PDSE,
Linear, Page) wasters of space in a CKD environment.  The "savings"
has long since been overshadowed by the complexity of maintaining CKD
in an environment where it is irrelevant instead of moving on.  The
lack of strategic thinking strikes again.
>  JC Ewing
>
>On 02/11/2010 10:16 AM, R.S. wrote:
>> Eric Bielefeld pisze:
>>> I just discovered something about PDS/Es that I don't remember being
>>> discussed.  This discussion inspired me to copy my JCL PDS to a PDS/E
>>> on one of my accounts.  Notice that the % full went from 62 to 95%.  I
>>> used the same blksize.  I figured that since the PDS was 62% full, I'd
>>> make the PDS/E 2 cylinders less.  Here are the results:
>>>
>>>  Tracks  % XT Device  Dsorg Recfm Lrecl Blksz
>>> 
>>>$IQLG.JCL.CNTL  120  62 1
>>> 3390 PO   FB   80  7520
>>> 
>>>$IQLG.JCLN.CNTL 120  95 2
>>> 3390 PO-E FB   80  7520
>>>
>>> That's almost a third more space used.  Any comments?  I'm sure there
>>> are a few who know why that is out there.  This PDS has just over a
>>> thousand members.
>> 
>> IMHO thet answer is obvious: PDSE allocates space to members in 4kB
>> blocks. So 1 record member takes whole 4kB block. For large members it's
>> not a problem, but for small ones it is.
>> 
>> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ron Hawkins]

Barbara,

Yes it is a confusing subject. The MSR value was there at day one with PDSE.
It had to set to 3ms whereas must cache was 6ms for 3390-3 or smaller as I
recall. There was a bug that disabled this, but then it was returned.

We'll wait and see if some of those presentations match what is observed in
the SMF records. You've sleeper program has already verified that you are
getting directory caching when another address has the file open. That
conflicts with the statement below.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Barbara Nitz
> Sent: Friday, February 12, 2010 3:23 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] PDS vs. PDSE
> 
> >PDSEs without a storage class are not cached in hiperspace:
> >http://www.redbooks.ibm.com/abstracts/TIPS0567.html?Open
> >
> >("Ensure that SMS-managed PDSEs are associated with storage classes that
> >have appropriate MSR settings. (Note that PDSE data sets shipped as part
of
> >the operating system are generally not SMS-managed, so they have no
> storage
> >class and therefore cannot be cached).")
> 
> Well, that explains why the parm doesn't get us anything. It may also
explain
> why the directory cache is completely ineffective, especially as *that* is
> also
> set to the IBM default value, which is 2GB.
> 
> What really galls me is that init&tuna reference doesn't even mention
that!
> And nonSMS managed PDSEs have been around a long time, too! So we are
> supposed to just *know* when it's specified in IGDSMSxx, it doesn't apply
to
> PDSEs, only to *sms-managed* PDSEs.
> 
> Good thing it's Friday.
> Barbara
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ron Hawkins]

Barbara,

Your email address bounced. I'd be happy to look at this offline with you.
It would be interesting to check the before and after stats.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Barbara Nitz
> Sent: Friday, February 12, 2010 1:21 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] PDS vs. PDSE
> 
> >That's what I was wondering about. The default for
> >PDSE_HSP_SIZE|HSP_SIZE(nnn) is 0, and according to the Manual 0 disables
> >PDSE Member Caching.
> 
> I'll try to get this set for tomorrow's IPL on the second of the two
systems
> that are affected. I'll start with 500M. On the other, I will start my
little
> sleeper program. I'll let you know what happens.
> 
> Actually, I have copied the biggest one (it is now 120.000 tracks). It
went
> down 25.000 pages in usage. No bad. I think the last copy action was a
while
> ago.
> 
> Thanks again, best regards, Barbara
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Barbara Nitz]

>PDSEs without a storage class are not cached in hiperspace:
>http://www.redbooks.ibm.com/abstracts/TIPS0567.html?Open
>
>("Ensure that SMS-managed PDSEs are associated with storage classes that
>have appropriate MSR settings. (Note that PDSE data sets shipped as part of
>the operating system are generally not SMS-managed, so they have no 
storage
>class and therefore cannot be cached).")

Well, that explains why the parm doesn't get us anything. It may also explain 
why the directory cache is completely ineffective, especially as *that* is also 
set to the IBM default value, which is 2GB.

What really galls me is that init&tuna reference doesn't even mention that! 
And nonSMS managed PDSEs have been around a long time, too! So we are 
supposed to just *know* when it's specified in IGDSMSxx, it doesn't apply to 
PDSEs, only to *sms-managed* PDSEs. 

Good thing it's Friday.
Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[J R]

> In PDS you can have many small member occupying single block. 

 

Not true!  Each member has its own TTR.  

 

 
> Date: Fri, 12 Feb 2010 08:38:46 +0100
> From: r.skoru...@bremultibank.com.pl
> Subject: Re: PDS vs. PDSE
> To: IBM-MAIN@bama.ua.edu
> 
> Eric Bielefeld pisze:
> > I just tried allocating the ds as 4080 for the blocksize, and used the same 
> > 95%, so apparently the blocksize doesn't matter. As a few have pointed out, 
> > the smaller members that take less than a full 4K page waste a lot of 
> > space. 
> > 
> > So, does PDS/E write out 4K blocks regardless of what you specify? 
> 
> 1. Yes, PDSE always use 4kB internally (see used pages in PDF). It does 
> not depend on BLKSIZE from JCL DD.
> 
> 2. In fact blocksize DOESN'T MATTER. What matters is the block cannot be 
> share between members. In PDS you can have many small member occupying 
> single block. In PDSE any member takes *at least* one block.
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
  
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Norbert Friemel]

On Fri, 12 Feb 2010 03:20:34 -0600, Barbara Nitz wrote:

>>That's what I was wondering about. The default for
>>PDSE_HSP_SIZE|HSP_SIZE(nnn) is 0, and according to the Manual 0 disables
>>PDSE Member Caching.
>
>I'll try to get this set for tomorrow's IPL on the second of the two systems
>that are affected. I'll start with 500M. On the other, I will start my little
>sleeper program. I'll let you know what happens.
>

PDSEs without a storage class are not cached in hiperspace:
http://www.redbooks.ibm.com/abstracts/TIPS0567.html?Open

("Ensure that SMS-managed PDSEs are associated with storage classes that
have appropriate MSR settings. (Note that PDSE data sets shipped as part of
the operating system are generally not SMS-managed, so they have no storage
class and therefore cannot be cached).")

Norbert Friemel

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ron Hawkins]

And one (emulated) block gap.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Andy Wood
> Sent: Friday, February 12, 2010 12:57 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] PDS vs. PDSE
> 
> . . .
> >In a PDS
> any member also
> >takes at least one block, but there can be short blocks (less than
BLKSIZE).
> >
> 
> Well, to be precise, any non-empty member of a PDS takes at least one
block
> (and an EOF "block"). An empty member has only the EOF "block" (count
field
> with zero data length).
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Barbara Nitz]

>That's what I was wondering about. The default for
>PDSE_HSP_SIZE|HSP_SIZE(nnn) is 0, and according to the Manual 0 disables
>PDSE Member Caching.

I'll try to get this set for tomorrow's IPL on the second of the two systems 
that are affected. I'll start with 500M. On the other, I will start my little 
sleeper program. I'll let you know what happens.

Actually, I have copied the biggest one (it is now 120.000 tracks). It went 
down 25.000 pages in usage. No bad. I think the last copy action was a while 
ago.

Thanks again, best regards, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Andy Wood]

. . .
>In a PDS
any member also
>takes at least one block, but there can be short blocks (less than BLKSIZE).
>

Well, to be precise, any non-empty member of a PDS takes at least one block
(and an EOF "block"). An empty member has only the EOF "block" (count field
with zero data length).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ted MacNEIL]

>> And, HFS is a form of PDSE.

>What does it mean exactly?

The internal structure is almost exactly the same as a PDSE.
The differences are subtle, such as supporting UNIX-style names.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ron Hawkins]

Barbara,


> Puh, how do I go about finding this out? If any of this is specified in
the
> IGDSMS member, then we take whatever default IBM set. And these things
> apparently don't *have* storage class, management class or dataclass. I
just
> tested, and they end up on hte volumes they do because I manually put them
> there way back when. :-(
> Should I try to get anything changed here?
> 

That's what I was wondering about. The default for
PDSE_HSP_SIZE|HSP_SIZE(nnn) is 0, and according to the Manual 0 disables
PDSE Member Caching.

"You can use the HSP_SIZE parameter to request up to 2047
megabytes for the PDSE hiperspace. You can indicate that the hiperspace is
not to be created by setting HSP_SIZE to 0. If the hiperspace is not
created, the system will not cache PDSE members. 

On systems that are running in z/Architecture mode, by
default the PDSE hiperspace is not created and PDSE member caching is
disabled." 

You need to specify something to get PDSE member caching. I'm just wondering
if this is tied to directory caching and buffer beyond close also.

I think the default of 2GB should be enough for Directory cache, but it
would be nice to know how your statistics support this.

Ron


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Andy Wood]

. . .

>2. In fact blocksize DOESN'T MATTER. What matters is the block cannot be
>share between members. In PDS you can have many small member occupying
>single block. In PDSE any member takes *at least* one block.

No block in a PDS can contain more than one member. In a PDS any member also
takes at least one block, but there can be short blocks (less than BLKSIZE).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[R.S.]

Ted MacNEIL pisze:
[...]

When they first came out, I was told that PDSE are linear VSAM.
And, HFS is a form of PDSE.


What does it mean exactly?
I can say that PS is a form of dataset, or PDSE is a form of PDS - but 
this is not very informative. No irony intended, just curious.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[R.S.]

Eric Bielefeld pisze:
I just tried allocating the ds as 4080 for the blocksize, and used the same 95%, so apparently the blocksize doesn't matter.  As a few have pointed out, the smaller members that take less than a full 4K page waste a lot of space.  

So, does PDS/E write out 4K blocks regardless of what you specify?  


1. Yes, PDSE always use 4kB internally (see used pages in PDF). It does 
not depend on BLKSIZE from JCL DD.


2. In fact blocksize DOESN'T MATTER. What matters is the block cannot be 
share between members. In PDS you can have many small member occupying 
single block. In PDSE any member takes *at least* one block.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Barbara Nitz]

>The BLKSIZE shown is not the physical block size. It is the __emulated__
>blocksize which your normal BPAM program would use. I am fairly sure that 
>the actual PDSE is physically blocked at 4K pages on the device itself. Like 
>zFS, HFS, and some other things, PDSE seems to have been influenced by 
>LINEAR VSAM in its choice to do physical DASD in 4K pages.

Actually, PDSE (and HFS, for that matter) is using Media Manager for doing the 
actual IO. And MM works on 4K pages. 

Regards, Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Barbara Nitz]

>I'm not trying to teach you how to suck eggs. I know you've had this problem
>for a few years now.
I didn't think you were. :-) But since I am kinda in awe of anyone who 
understands hardware (which I don't), I just wanted to make sure were talking 
about the same thing.

>> PDSE1_BUFFER_BEYOND_CLOSE(YES)
>That is what I am talking about. The beyond close values are 15 minutes. If
>the member is not opened after that it is discarded from PDSDE cache. Your
>finding that it does not work.
It doesn't work in the first 15 minutes, as in PF3 out of the directory view in 
ISPF, then back in. Wait again for more than a minute. 

>I get it. There's no JCL or facility to add buffering.
Yes, but given this discussion, I'll probably contact the head developer for FA 
(in Australia) and let him know about this. I believe that they are changing 
the 
design of how they want do things (for several reasons), so they might as well 
keep this in mind, too. FA is on the receiving end of the PDSE inadequacies.

>I'm interested to know what do you have specified for the two HiperSpace
>sizes, Directory Storage, and what is the MSR value for the STORCLAS of this
>PDSE?
Puh, how do I go about finding this out? If any of this is specified in the 
IGDSMS member, then we take whatever default IBM set. And these things 
apparently don't *have* storage class, management class or dataclass. I just 
tested, and they end up on hte volumes they do because I manually put them 
there way back when. :-( 
Should I try to get anything changed here?

>Earlier you mentioned storage cache. Have you looked at the SMF Type 42_6
>records for the PDS-E to see where the IO is spending it's time? It sounds
>to me like a fragmented directory in this PDS-E could be causing some
>cache-defeating skip IO. The SMF record could give some guidance on 
>whether
>you can benefit from loading the PDS-E into cache with HDS Cache Residency
>Manager(CRM) or EMC Permacache. I don't recall what storage you have, but 
>if it is HDS then CRM and the Host software are included with the basic
>product.
EMC. And no, I haven't done any checking into this yet. But thanks for the 
pointers on where to get started. (After all, since I am the SAS wizard around 
here, it shouldn't be too hard to get reports out of SMF. How to actually 
*interpret* them is a different matter!)

>The Type 14/15 records also have actual PDSE buffer usage statistics. This
>would at least tell you if PDSE buffering is doing anything.
May I contact you off-list to pick your brain about whatever I find out from 
SMF?

Best regards, Barbara 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Joel C. Ewing]

No one seems to have pointed out that even for large members requiring
more than 4 KiB there is more wasted space for PDSE than for a PDS:
Since all space allocation is in 4KiB blocks, one should expect on
average 50% of the last block or 2 KiB per member to be wasted for all
members, not just the short ones; although there could be pathological
cases where this wastage approaches 4 KiB per member.  For a PDS the
last block of a member uses a short physical block if there are not
enough records to fill it, and the unused space can potentially be used
for the following member.

And, for those that have taken the trouble to optimize PDS blocksize
with half-track blocking to maximize DASD track utilization, converting
to PDSE and reverting back to a sub-optimal 4 KiB block size throws away
close to 10% of the optimal track capacity on a 3390.

With these factors to consider, the only way a PDSE can end up occupying
less space than a PDS with the same data is when there is appreciable
update activity to existing members and the PDS must be oversized to not
run out of space between compresses, while the PDSE can eventually reuse
deleted space.
  JC Ewing

On 02/11/2010 10:16 AM, R.S. wrote:
> Eric Bielefeld pisze:
>> I just discovered something about PDS/Es that I don't remember being
>> discussed.  This discussion inspired me to copy my JCL PDS to a PDS/E
>> on one of my accounts.  Notice that the % full went from 62 to 95%.  I
>> used the same blksize.  I figured that since the PDS was 62% full, I'd
>> make the PDS/E 2 cylinders less.  Here are the results:
>>
>>  Tracks  % XT Device  Dsorg Recfm Lrecl Blksz
>> 
>>$IQLG.JCL.CNTL  120  62 1
>> 3390 PO   FB   80  7520
>> 
>>$IQLG.JCLN.CNTL 120  95 2
>> 3390 PO-E FB   80  7520
>>
>> That's almost a third more space used.  Any comments?  I'm sure there
>> are a few who know why that is out there.  This PDS has just over a
>> thousand members.
> 
> IMHO thet answer is obvious: PDSE allocates space to members in 4kB
> blocks. So 1 record member takes whole 4kB block. For large members it's
> not a problem, but for small ones it is.
> 
> 


-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ted MacNEIL]

>Like zFS, HFS, and some other things, PDSE seems to have been influenced by 
>LINEAR VSAM in its choice to do physical DASD in 4K pages.

When they first came out, I was told that PDSE are linear VSAM.
And, HFS is a form of PDSE.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[McKown, John]

The BLKSIZE shown is not the physical block size. It is the __emulated__ 
blocksize which your normal BPAM program would use. I am fairly sure that the 
actual PDSE is physically blocked at 4K pages on the device itself. Like zFS, 
HFS, and some other things, PDSE seems to have been influenced by LINEAR VSAM 
in its choice to do physical DASD in 4K pages.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Eric Bielefeld
> Sent: Thursday, February 11, 2010 11:21 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PDS vs. PDSE
> 
> I was just thinking - I wonder if the blocksize I used is bad 
> for PDS/E, givin the 4096 page six.  Will it write blocks at 
> 7520, or just write 4K blocks?  Should I make the blocksize 
> something with a closer multiple of 4096?
> 
> Eric
> 
> --
> Eric Bielefeld
> Systems Programmer
> IBM MVS Technical Services
> Dubuque, Iowa
> 563-845-4363
> 
>  Wayne Driscoll  wrote: 
> > Eric,
> > This is probably due to the fact that PDS/E's require a 
> minimum of 1 page 
> > per member (Point 14 in Radalsow's summary).  Since these 
> are JCL members, 
> > I would imagine that  a fair number of them are 15-20 line 
> members, with 
> > the 4K minimum member size,for an FB-80 dataset that works 
> out to just 
> > over 51 records, so any JCL that is under 51 lines will 
> still take up 4K 
> > each, while in a PDS an 80 byte member takes 80 bytes in 
> the PDS itself 
> > (after the directory of course).
> > 
> > ===
> > Wayne Driscoll
> > OMEGAMON DB2 L3 Support/Development
> > wdrisco(AT)us.ibm.com
> > ===
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ted MacNEIL]

>So, does PDS/E write out 4K blocks regardless of what you specify?  

Yes.
Think of it as a string of bytes per member, written out in multiple 4K chunks 
(minimum size).
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ted MacNEIL]

>I was just thinking - I wonder if the blocksize I used is bad for PDS/E, givin 
>the 4096 page six.

The 'logical' blocksize really doesn't matter.
All data is stored in 'physical' blocks of 4096, regardless of the blocksize 
specified.


>Will it write blocks at 7520, or just write 4K blocks?  >Should I make the 
>blocksize something with a closer multiple of 4096?

Don't bother.
The problem is akin to cluster sizes on PC's.
There is a minimum of 4K per member, regardless of the other attributes.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Eric Bielefeld]

I just tried allocating the ds as 4080 for the blocksize, and used the same 
95%, so apparently the blocksize doesn't matter.  As a few have pointed out, 
the smaller members that take less than a full 4K page waste a lot of space.  

So, does PDS/E write out 4K blocks regardless of what you specify?  

Eric

--
Eric Bielefeld
Systems Programmer
IBM MVS Technical Services
Dubuque, Iowa
563-845-4363

 Eric Bielefeld  wrote: 
> I was just thinking - I wonder if the blocksize I used is bad for PDS/E, 
> givin the 4096 page six.  Will it write blocks at 7520, or just write 4K 
> blocks?  Should I make the blocksize something with a closer multiple of 4096?
> 
> Eric

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Blaicher, Chris]

My understanding is that it makes no difference.  PDSE is basically a stream.  
It fills 4K blocks and writes them.  When you read it back, you can change the 
BLKSIZE.  I.e. write as 80/800 and read it back as 80/3280.  

Chris Blaicher
Phone: 512-340-6154
Mobile: 512-627-3803
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Eric Bielefeld
Sent: Thursday, February 11, 2010 11:21 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

I was just thinking - I wonder if the blocksize I used is bad for PDS/E, givin 
the 4096 page six.  Will it write blocks at 7520, or just write 4K blocks?  
Should I make the blocksize something with a closer multiple of 4096?

Eric

--
Eric Bielefeld
Systems Programmer
IBM MVS Technical Services
Dubuque, Iowa
563-845-4363

 Wayne Driscoll  wrote: 
> Eric,
> This is probably due to the fact that PDS/E's require a minimum of 1 page 
> per member (Point 14 in Radalsow's summary).  Since these are JCL members, 
> I would imagine that  a fair number of them are 15-20 line members, with 
> the 4K minimum member size,for an FB-80 dataset that works out to just 
> over 51 records, so any JCL that is under 51 lines will still take up 4K 
> each, while in a PDS an 80 byte member takes 80 bytes in the PDS itself 
> (after the directory of course).
> 
> ===
> Wayne Driscoll
> OMEGAMON DB2 L3 Support/Development
> wdrisco(AT)us.ibm.com
> ===

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Eric Bielefeld]

I was just thinking - I wonder if the blocksize I used is bad for PDS/E, givin 
the 4096 page six.  Will it write blocks at 7520, or just write 4K blocks?  
Should I make the blocksize something with a closer multiple of 4096?

Eric

--
Eric Bielefeld
Systems Programmer
IBM MVS Technical Services
Dubuque, Iowa
563-845-4363

 Wayne Driscoll  wrote: 
> Eric,
> This is probably due to the fact that PDS/E's require a minimum of 1 page 
> per member (Point 14 in Radalsow's summary).  Since these are JCL members, 
> I would imagine that  a fair number of them are 15-20 line members, with 
> the 4K minimum member size,for an FB-80 dataset that works out to just 
> over 51 records, so any JCL that is under 51 lines will still take up 4K 
> each, while in a PDS an 80 byte member takes 80 bytes in the PDS itself 
> (after the directory of course).
> 
> ===
> Wayne Driscoll
> OMEGAMON DB2 L3 Support/Development
> wdrisco(AT)us.ibm.com
> ===

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

RES: PDS vs. PDSE

[Adauto]

We had many problems with PDSE on the installation where I worked until last
month. 

When the PDSE has a massive update process (inserting and deleting members -
the installation has a system that uses PDSE as base to archive he last
three days of production jobs JES sysouts) something happens that after some
time it is impossible update the file. We turn around this problem when
monthly a job create a new PDSE, copy the contents of the old to the new,
delete the old and rename the new one to the old name. At least once we
couldn't read the file after this problem. We don't know if this problem was
solved or not because we kept the turn around process.

The last problem that we faced with PDSE was on the delete members process,
because the file was full and was allocated with no secondary allocation
space parameter. This began with zOS 1.10 - until zOS 1.8 never was
happened. The program sometimes ends with D37. The IBM Lab sad that it's
because of the directory process update demands some space. We turn around
specifying secondary allocation space parameters only in this process.

Until now the people there feel unsecure to use PDSE for production load
modules or other production library.

Adauto


-Mensagem original-
De: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] Em nome de
Chase, John
Enviada em: quinta-feira, 11 de fevereiro de 2010 10:53
Para: IBM-MAIN@bama.ua.edu
Assunto: Re: PDS vs. PDSE

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of R.S.
> 
> I dared to get all the objections together combined with some mines:
> 
> Disadvantages:
> 1. New feature - people still think that way 
> 2. Former requirement for SMS-management
> 3. "New" keyword to create PDSE (DSNTYPE)
> 4. Cross-sysplex sharing
> 5. Cannot hold both data and programs (and no visible clue what's the
kind
> 6. LPALST, LNKLST restrictions
> 7. Quite recent changes (address spaces) - look like "work in
progress"
> 8. PTFs
> 9. With fe exceptions (listed below) no visible advantage. Long names
> are not usable in JCL or ISPF (where they are usable?). Load module
size
> is limit rarely a problem. New program format is not an advantage
itself.
> 10. As above: 64k TRKs limit relieved, but ther's still single vol
> restriction.
> 11. Still many datasets cannot be PDSEs.
> 12. Performance can be worse than PDS.
> 13. Secret documentation. BTW: It is horrible that basic function as
> "get_dataset_size" is kept secret for regular users!
> 14. 4k block boundary for members can consume more space than regular
PDS
> 
> Advantages:
> 1. No need to compress
> 2. 123 extents
> 3. No 64k TRKs limit
> 4. Cannot be destroyed when open for output as PS (common mistake).

5.  Counts as one extent in LNKLST regardless the actual number of
extents.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[R.S.]

Eric Bielefeld pisze:

I just discovered something about PDS/Es that I don't remember being discussed. 
 This discussion inspired me to copy my JCL PDS to a PDS/E on one of my 
accounts.  Notice that the % full went from 62 to 95%.  I used the same 
blksize.  I figured that since the PDS was 62% full, I'd make the PDS/E 2 
cylinders less.  Here are the results:

 Tracks  % XT Device  Dsorg Recfm Lrecl Blksz

   $IQLG.JCL.CNTL   
   120  62 1 3390 PO   FB   80  7520


   $IQLG.JCLN.CNTL  
   120  95 2 3390 PO-E FB   80  7520


That's almost a third more space used.  Any comments?  I'm sure there are a few 
who know why that is out there.  This PDS has just over a thousand members.


IMHO thet answer is obvious: PDSE allocates space to members in 4kB 
blocks. So 1 record member takes whole 4kB block. For large members it's 
not a problem, but for small ones it is.



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Wayne Driscoll]

Eric,
This is probably due to the fact that PDS/E's require a minimum of 1 page 
per member (Point 14 in Radalsow's summary).  Since these are JCL members, 
I would imagine that  a fair number of them are 15-20 line members, with 
the 4K minimum member size,for an FB-80 dataset that works out to just 
over 51 records, so any JCL that is under 51 lines will still take up 4K 
each, while in a PDS an 80 byte member takes 80 bytes in the PDS itself 
(after the directory of course).

===
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(AT)us.ibm.com
===



From:
Eric Bielefeld 
To:
IBM-MAIN@bama.ua.edu
Date:
02/11/2010 09:40 AM
Subject:
Re: PDS vs. PDSE
Sent by:
IBM Mainframe Discussion List 



I just discovered something about PDS/Es that I don't remember being 
discussed.  This discussion inspired me to copy my JCL PDS to a PDS/E on 
one of my accounts.  Notice that the % full went from 62 to 95%.  I used 
the same blksize.  I figured that since the PDS was 62% full, I'd make the 
PDS/E 2 cylinders less.  Here are the results:

 Tracks  % XT Device  Dsorg Recfm Lrecl Blksz

   $IQLG.JCL.CNTL 
   120  62 1 3390 PO   FB   80  7520

   $IQLG.JCLN.CNTL 
   120  95 2 3390 PO-E FB   80  7520

That's almost a third more space used.  Any comments?  I'm sure there are 
a few who know why that is out there.  This PDS has just over a thousand 
members.

Eric 

--
Eric Bielefeld
Systems Programmer
IBM MVS Technical Services
Dubuque, Iowa
563-845-4363

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SV: PDS vs. PDSE

[Thomas Berg]

Because a PDS/E member occupies at minimum 4096 bytes ?


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 



> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Eric
> Bielefeld
> Skickat: den 11 februari 2010 16:39
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: PDS vs. PDSE
> 
> I just discovered something about PDS/Es that I don't remember being
> discussed.  This discussion inspired me to copy my JCL PDS to a PDS/E on
> one of my accounts.  Notice that the % full went from 62 to 95%.  I used
> the same blksize.  I figured that since the PDS was 62% full, I'd make the
> PDS/E 2 cylinders less.  Here are the results:
> 
>  Tracks  % XT Device  Dsorg Recfm Lrecl Blksz
> 
>$IQLG.JCL.CNTL
>120  62 1 3390 PO   FB   80  7520
> 
>$IQLG.JCLN.CNTL
>120  95 2 3390 PO-E FB   80  7520
> 
> That's almost a third more space used.  Any comments?  I'm sure there are
> a few who know why that is out there.  This PDS has just over a thousand
> members.
> 
> Eric
> 
> --
> Eric Bielefeld
> Systems Programmer
> IBM MVS Technical Services
> Dubuque, Iowa
> 563-845-4363
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Eric Bielefeld]

I just discovered something about PDS/Es that I don't remember being discussed. 
 This discussion inspired me to copy my JCL PDS to a PDS/E on one of my 
accounts.  Notice that the % full went from 62 to 95%.  I used the same 
blksize.  I figured that since the PDS was 62% full, I'd make the PDS/E 2 
cylinders less.  Here are the results:

 Tracks  % XT Device  Dsorg Recfm Lrecl Blksz

   $IQLG.JCL.CNTL   
   120  62 1 3390 PO   FB   80  7520

   $IQLG.JCLN.CNTL  
   120  95 2 3390 PO-E FB   80  7520

That's almost a third more space used.  Any comments?  I'm sure there are a few 
who know why that is out there.  This PDS has just over a thousand members.

Eric 

--
Eric Bielefeld
Systems Programmer
IBM MVS Technical Services
Dubuque, Iowa
563-845-4363

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[R.S.]

McKown, John pisze:

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Brazee

Sent: Wednesday, February 10, 2010 7:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

On 10 Feb 2010 12:09:58 -0800, hmerr...@jackhenry.com (Hal Merritt)
wrote:

PDSE's are very useful, as are PDS's. If you don't need the 
PDSE features then why bother? You don't see many compelling 
business/technical cases to convert PDS's to PDSE's. 

My $0.02

Other computers didn't need the advantages of PDS's.   Nor the
disadvantages.   


Does anything other than S/360 derived systems even use CKD type DASD? PDS 
directories are built around CKD. And, in their day, moving the search logic 
out to the peripheral was probably a good idea.


I don't know about TPF, VSE and VM, but in z/OS there are only two 
structures using Key from CKD: PDS and (regular) VTOC. So with two 
exceptions we use C-D disk. However lack of key does not make CKD disks 
more compatible to FBA.



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Howard Brazee]

On 11 Feb 2010 05:37:17 -0800, john.mck...@healthmarkets.com (McKown,
John) wrote:

>> Other computers didn't need the advantages of PDS's.   Nor the
>> disadvantages.   
>
>Does anything other than S/360 derived systems even use CKD type DASD? PDS 
>directories are built around CKD. 
>And, in their day, moving the search logic out to the peripheral was probably 
>a good idea.

We used to care about whether our disk was CKD.   (And whether we
called it DASD).   

And with different types of disks, we spent time figuring out sort
work sizes, converting tracks and blocks etc.But these were all
working around hardware design to a degree that other systems handled
themselves.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


john.mck...@healthmarkets.com (McKown, John) writes:
> Does anything other than S/360 derived systems even use CKD type DASD?
> PDS directories are built around CKD. And, in their day, moving the
> search logic out to the peripheral was probably a good idea.

basically traded-off lack of real storage (for indexes) for i/o
resources (channel, controller, device) ... by the mid-70s, that
trade-off had started to invert ... and multi-track searches for VTOC
and PDS directories were the wrong thing. set-sector introduced in early
70s with 3330s, attempted to offset the channel/controller overhead for
simple CKD searches ... but didn't help with the multi-track searches.

it was also somewhat seen in the discord between IMS group and system/r
(original relational/sql) in the late 70s ... IMS pointing out that the
implicit relational indexes consumed a lot more hardware resources
... and system/r pointing out that it eliminated a lot of IMS
administrative care&management. The increasing amounts of real storage
really started to tip the balance by the mid-80s ... allowing the
relational indexes to be cached.

misc. past posts mentioning system/r
http://www.garlic.com/~lynn/submain.html#systemr

misc. past posts discussing the ckd/multi-track search trade-off
changing by the mid-70s
http://www.garlic.com/~lynn/submain.html#dasd

in the early 80s, the MVS group gave me a cost estimate of $26m to
migrate off of CKD ... even if I gave them fully tested & integrated
code (i.e. just cost for documentation and training). I could only use
incremental sales for ROI business case ... and the claim was that
customers would just buy the same amount of non-CKD as they were buying
CKD (I couldn't use long-term corporate & customer life-cycle costs of
continuing with CKD, I had to show $100m-$200m incremental sales).

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ron Hawkins]

Barbara,

I'm not trying to teach you how to suck eggs. I know you've had this problem
for a few years now.

> 
> >I would not expect caching to help unless the member was already opened,
or
> >it had been used less than 15 minutes ago.
> When I talk about 'caching', I don't mean hardware chaching (you remember
> that I don't *do* hardware :-) ). I talk about LLA/VLF caching and the
> SMSPDSE/1 address space(s), which are supposed to keep the directory
> information around, even after closing.
> PDSE_BUFFER_BEYOND_CLOSE(YES)
> PDSE1_BUFFER_BEYOND_CLOSE(YES)
> Which are turned on everywhere here. Which doesn't help *at all*.

That is what I am talking about. The beyond close values are 15 minutes. If
the member is not opened after that it is discarded from PDSDE cache. Your
finding that it does not work.

Peter Relson mentioned last September on this forum that LLA Freeze does not
operate for PDSE that are non-loadlibs, so LLA and VLF will not be providing
any benefit for PDSE. If the PDS version are in LLA/VLF then that is an
advantage over PDSE.

> 
> 
> Fault Analyzer gets invoked via RTM and LE exits in every address space in
the
> system. So while running in any address space, FA opens its parmlib and
> checks where to look for the 'side files' - these PDSEs. *Then* Fault
Analyzer
> does the open and the directory reads, searching for the source code
> information that has the matching timestamp to the abending (LE) program.
I
> have no influence whatsoever on *how* this is opened and/or searched.


I get it. There's no JCL or facility to add buffering.

> 
> Even under ISPF 3.4, it takes a minute or longer just to present the first
> screen of directory information, of *one* of those big PDSEs. FA has a
timeout
> limit for real-time analysis of 10 minutes, and we hit that limit
repeatedly,
> especially when the lpar is cpu constrained.
> 
> In the past, I had written a program that got started at IPL and only went
and
> issued a simple open macro against these PDSEs, then went into a
> neverending wait, never closing the data sets. *That* had speeded up
finding
> the directory entries. (3.4 took 2 seconds or less.) And
> BUFFER_BEYOND_CLOSE was *supposed* to keep the 'connection' (or
> something) around for any PDSE opened, the connection being kept in the
> smspdse/1 address space. It obviously doesn't work. The PDSE design as I
> understand it still throws away all awareness of that dataset having been
> opened before, the microsecond the close is issued against it, desoute how
> the parm is set. It doesn't even keep it around for 15 minutes (or less).

I understood that buffer beyond close related to caching of members, and not
the directory. However the manual does say Directory and Member. Your
sleeper program confirms there is some directory caching occurring while the
file is open.

I'm interested to know what do you have specified for the two HiperSpace
sizes, Directory Storage, and what is the MSR value for the STORCLAS of this
PDSE?

> 
> Unless we're missing some parm that will fix this, I think I'll better
revert
> to my
> little 'open program'. So my rant at least has shown me to use my
homegrown
> solution again.
 
That sounds like a good idea. 

Earlier you mentioned storage cache. Have you looked at the SMF Type 42_6
records for the PDS-E to see where the IO is spending it's time? It sounds
to me like a fragmented directory in this PDS-E could be causing some
cache-defeating skip IO. The SMF record could give some guidance on whether
you can benefit from loading the PDS-E into cache with HDS Cache Residency
Manager(CRM) or EMC Permacache. I don't recall what storage you have, but if
it is HDS then CRM and the Host software are included with the basic
product.

The Type 14/15 records also have actual PDSE buffer usage statistics. This
would at least tell you if PDSE buffering is doing anything.

Ron

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Paul Gilmartin]

On Thu, 11 Feb 2010 06:34:50 -0600, John P Kalinich wrote:
>
>I think that BUFNO and NCP are ignored for PDSE's.  Let me check the doc
>for sure.
>
But you might improve performance by overriding to a larger (or
smaller) BLKSIZE in JCL, something no effective for PDS.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Brazee
> Sent: Wednesday, February 10, 2010 7:29 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PDS vs. PDSE
> 
> On 10 Feb 2010 12:09:58 -0800, hmerr...@jackhenry.com (Hal Merritt)
> wrote:
> 
> >
> >PDSE's are very useful, as are PDS's. If you don't need the 
> PDSE features then why bother? You don't see many compelling 
> business/technical cases to convert PDS's to PDSE's. 
> >
> >My $0.02
> 
> Other computers didn't need the advantages of PDS's.   Nor the
> disadvantages.   

Does anything other than S/360 derived systems even use CKD type DASD? PDS 
directories are built around CKD. And, in their day, moving the search logic 
out to the peripheral was probably a good idea.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Elardus Engelbrecht]

No-one said anything about corrupt PDSE during IPL... (or I have missed it.)

In z/OS v1.12 Preview this snippet:

"When a corrupt PDSE is detected in the link list during IPL, the system enters 
a wait state. In z/OS V1.12, the system will be designed to issue a message 
identifying the corrupt PDSE prior to entering the wait state. This allows the 
user to attempt to restore the corrupt PDSE and re-IPL the system and avoid 
taking a standalone dump to debug the problem."

another snippet:

"PDSE processing is planned to be changed to reduce delays that can occur 
when two systems are accessing a PDSE concurrently while it is being 
updated. PDSE will be designed to improve its cross-system sharing 
capabilities, including member-level sharing, within a GRS complex but outside 
a Parallel Sysplex. These changes are intended to make PDSEs more usable 
outside single-system and Parallel Sysplex environments."

last one:

"New PDSE functions are planned. A new utility will be designed to verify that 
the structure of a PDSE is valid, and programming services will be designed to 
perform similar checking to help programs verify the state of a PDSE before 
and after critical operations. These new functions are intended to help you 
detect errors in PDSE structures that might otherwise go undetected."

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of R.S.
> 
> I dared to get all the objections together combined with some mines:
> 
> Disadvantages:
> 1. New feature - people still think that way 
> 2. Former requirement for SMS-management
> 3. "New" keyword to create PDSE (DSNTYPE)
> 4. Cross-sysplex sharing
> 5. Cannot hold both data and programs (and no visible clue what's the
kind
> 6. LPALST, LNKLST restrictions
> 7. Quite recent changes (address spaces) - look like "work in
progress"
> 8. PTFs
> 9. With fe exceptions (listed below) no visible advantage. Long names
> are not usable in JCL or ISPF (where they are usable?). Load module
size
> is limit rarely a problem. New program format is not an advantage
itself.
> 10. As above: 64k TRKs limit relieved, but ther's still single vol
> restriction.
> 11. Still many datasets cannot be PDSEs.
> 12. Performance can be worse than PDS.
> 13. Secret documentation. BTW: It is horrible that basic function as
> "get_dataset_size" is kept secret for regular users!
> 14. 4k block boundary for members can consume more space than regular
PDS
> 
> Advantages:
> 1. No need to compress
> 2. 123 extents
> 3. No 64k TRKs limit
> 4. Cannot be destroyed when open for output as PS (common mistake).

5.  Counts as one extent in LNKLST regardless the actual number of
extents.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[John P Kalinich]

Ron Hawkins of the IBM Mainframe Discussion List  
wrote on 02/11/2010 04:28:45 AM:

> Barbara,
> 
> The JCL Reference Manual still shows BUFNO and NCP as valid parameters 
for
> BPAM.
> 
> Ron
> 
> > 
> > You have me wondering if the block chaining strategy for PDSE is 
different
> to
> > PDS, and that perhaps adding buffers to the Fault Analyzer's 
allocation
> will
> > speed things up for you.
> > 

I think that BUFNO and NCP are ignored for PDSE's.  Let me check the doc 
for sure.

Regards,
John K 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Barbara Nitz]

Ron,

>The JCL Reference Manual still shows BUFNO and NCP as valid parameters for
>BPAM.
Which doesn't help me. Let me elaborate:

>I would not expect caching to help unless the member was already opened, or
>it had been used less than 15 minutes ago.
When I talk about 'caching', I don't mean hardware chaching (you remember 
that I don't *do* hardware :-) ). I talk about LLA/VLF caching and the 
SMSPDSE/1 address space(s), which are supposed to keep the directory 
information around, even after closing. 
PDSE_BUFFER_BEYOND_CLOSE(YES)  
PDSE1_BUFFER_BEYOND_CLOSE(YES)
Which are turned on everywhere here. Which doesn't help *at all*. 

>They were all small blksizes (like 3120 or 6144), and adding BUFNO=25 and
>NCP=25 reduced the load time significantly (we're talking 30-60 minutes of
>3380 without cache).

Fault Analyzer gets invoked via RTM and LE exits in every address space in the 
system. So while running in any address space, FA opens its parmlib and 
checks where to look for the 'side files' - these PDSEs. *Then* Fault Analyzer 
does the open and the directory reads, searching for the source code 
information that has the matching timestamp to the abending (LE) program. I 
have no influence whatsoever on *how* this is opened and/or searched.

Even under ISPF 3.4, it takes a minute or longer just to present the first 
screen of directory information, of *one* of those big PDSEs. FA has a timeout 
limit for real-time analysis of 10 minutes, and we hit that limit repeatedly, 
especially when the lpar is cpu constrained.

In the past, I had written a program that got started at IPL and only went and 
issued a simple open macro against these PDSEs, then went into a 
neverending wait, never closing the data sets. *That* had speeded up finding 
the directory entries. (3.4 took 2 seconds or less.) And 
BUFFER_BEYOND_CLOSE was *supposed* to keep the 'connection' (or 
something) around for any PDSE opened, the connection being kept in the 
smspdse/1 address space. It obviously doesn't work. The PDSE design as I 
understand it still throws away all awareness of that dataset having been 
opened before, the microsecond the close is issued against it, desoute how 
the parm is set. It doesn't even keep it around for 15 minutes (or less).

Unless we're missing some parm that will fix this, I think I'll better revert 
to my 
little 'open program'. So my rant at least has shown me to use my homegrown 
solution again. 

Regards, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ron Hawkins]

Barbara,

The JCL Reference Manual still shows BUFNO and NCP as valid parameters for
BPAM.

Ron

> 
> You have me wondering if the block chaining strategy for PDSE is different
to
> PDS, and that perhaps adding buffers to the Fault Analyzer's allocation
will
> speed things up for you.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ron Hawkins]

Barbara.

I would not expect caching to help unless the member was already opened, or
it had been used less than 15 minutes ago. (dodgy memory on the 15 minutes,
but I think that's right).

The Source PDS I mentioned was over 1000 CYLS and typical RECFM=FB,
LRECL=80, and blksize = whatever SDB gave it at the time (32760 I think).

I recall having a problems with TPNS similar to what you describe for Fault
Analyzer a long time ago (25 years) where it was opening some fairly large
script files for 1 terminals. Loading these would take forever. With
some experimentation we stumbled on buffering as a way to speed this up.
They were all small blksizes (like 3120 or 6144), and adding BUFNO=25 and
NCP=25 reduced the load time significantly (we're talking 30-60 minutes of
3380 without cache).

You have me wondering if the block chaining strategy for PDSE is different
to PDS, and that perhaps adding buffers to the Fault Analyzer's allocation
will speed things up for you.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Barbara Nitz
> Sent: Wednesday, February 10, 2010 10:34 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] PDS vs. PDSE
> 
> >PDSEs have been available for a long time, and provide many
> >advantages over PDSs. Why are people reluctant to use PDSEs?
> 
> In our case: Extremely bad performance on large datasets, as in a little
more
> than 10.000 members in 101.000 tracks, lrecl=1562, recfm=vb,
blksize=32760.
> In ISPF 3.4, despite using the 'caching' from SMSPDSE/1, a 'browse'  still
> takes
> almost a minute before ISPF shows you the directory.
> 
> Considering that Fault Analyzer has to open them all (they contain Fault
> Analyzer side files - and we have 8 big ones and several smaller ones)
until
> it
> finds the right source data set for analysis, this is extremely bad
> performance.
> It gets slightly better after 'reorganizing', i.e. just copy the dataset,
in
> which
> case the directory isn't scattered across all 101000 tracks anymore.
> 
> And let's not talk about data integrity. We lost two of those already.
> Irrevocably, as we the 4 backups we had all had the error which PDSE code
> had put in weeks ago. It's a very good thing that these can be rebuild or
> rather, gradually filled again. If the procedures here would allow with a
> reasonable organizational effort to NOT allocate them that large so they
could
> be PDSs, we would never have used PDSEs. As it is, there is no way around
> the fact that the primary allocation is bigger than 65K tracks,
necessitating
> PDSEs.
> 
> And believe me, I had been an advocat of PDSEs in the beginning. And I
still
> use PDSEs for my own, small JCL and source data sets. Stress on small.
> 
> Regards, Barbara Nitz
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Rob Scott]

The one thing I have noticed is that if you are replacing the entire contents 
of a PDSE using IEBCOPY - then the PDSE has to be able to grow to double its 
final size as the space reuse only seems to occur right at the end of the job 
(ie not after each member is re-written). I see this when I perform SCLM 
promotes and my listing datasets get promoted up to the next level and quite 
often blow up with space problems.  


Rob Scott
Developer
Rocket Software
275 Grove Street . Newton, MA 02466-2272 . USA
Tel: +1.617.614.2305 
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
R.S.
Sent: 11 February 2010 09:44
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

I dared to get all the objections together combined with some mines:

Disadvantages:
1. New feature - people still think that way  2. Former requirement for 
SMS-management 3. "New" keyword to create PDSE (DSNTYPE) 4. Cross-sysplex 
sharing 5. Cannot hold both data and programs (and no visible clue what's the 
kind 6. LPALST, LNKLST restrictions 7. Quite recent changes (address spaces) - 
look like "work in progress"
8. PTFs
9. With fe exceptions (listed below) no visible advantage. Long names are not 
usable in JCL or ISPF (where they are usable?). Load module size is limit 
rarely a problem. New program format is not an advantage itself.
10. As above: 64k TRKs limit relieved, but ther's still single vol restriction.
11. Still many datasets cannot be PDSEs.
12. Performance can be worse than PDS.
13. Secret documentation. BTW: It is horrible that basic function as 
"get_dataset_size" is kept secret for regular users!
14. 4k block boundary for members can consume more space than regular PDS

Advantages:
1. No need to compress
2. 123 extents
3. No 64k TRKs limit
4. Cannot be destroyed when open for output as PS (common mistake).

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237
NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[R.S.]

I dared to get all the objections together combined with some mines:

Disadvantages:
1. New feature - people still think that way 
2. Former requirement for SMS-management
3. "New" keyword to create PDSE (DSNTYPE)
4. Cross-sysplex sharing
5. Cannot hold both data and programs (and no visible clue what's the kind
6. LPALST, LNKLST restrictions
7. Quite recent changes (address spaces) - look like "work in progress"
8. PTFs
9. With fe exceptions (listed below) no visible advantage. Long names 
are not usable in JCL or ISPF (where they are usable?). Load module size 
is limit rarely a problem. New program format is not an advantage itself.
10. As above: 64k TRKs limit relieved, but ther's still single vol 
restriction.

11. Still many datasets cannot be PDSEs.
12. Performance can be worse than PDS.
13. Secret documentation. BTW: It is horrible that basic function as 
"get_dataset_size" is kept secret for regular users!

14. 4k block boundary for members can consume more space than regular PDS

Advantages:
1. No need to compress
2. 123 extents
3. No 64k TRKs limit
4. Cannot be destroyed when open for output as PS (common mistake).

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Barbara Nitz]

>PDSEs have been available for a long time, and provide many
>advantages over PDSs. Why are people reluctant to use PDSEs?

In our case: Extremely bad performance on large datasets, as in a little more 
than 10.000 members in 101.000 tracks, lrecl=1562, recfm=vb, blksize=32760. 
In ISPF 3.4, despite using the 'caching' from SMSPDSE/1, a 'browse'  still 
takes 
almost a minute before ISPF shows you the directory. 

Considering that Fault Analyzer has to open them all (they contain Fault 
Analyzer side files - and we have 8 big ones and several smaller ones) until it 
finds the right source data set for analysis, this is extremely bad 
performance. 
It gets slightly better after 'reorganizing', i.e. just copy the dataset, in 
which 
case the directory isn't scattered across all 101000 tracks anymore.

And let's not talk about data integrity. We lost two of those already. 
Irrevocably, as we the 4 backups we had all had the error which PDSE code 
had put in weeks ago. It's a very good thing that these can be rebuild or 
rather, gradually filled again. If the procedures here would allow with a 
reasonable organizational effort to NOT allocate them that large so they could 
be PDSs, we would never have used PDSEs. As it is, there is no way around 
the fact that the primary allocation is bigger than 65K tracks, necessitating 
PDSEs.

And believe me, I had been an advocat of PDSEs in the beginning. And I still 
use PDSEs for my own, small JCL and source data sets. Stress on small.

Regards, Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ron Hawkins]

All,

>From a performance POV I have to say I favour PDSE over PDS. I've had two
experiences that affected the business end of the companies I was looking
at. 

One was a PDS Source Library with around 25,000 members that were
check-out/in all day by a couple of hundred programmers. It was the single
busiest dataset in the whole shop (two sites, 10 CEC, 19 LPARS, several 1000
ESCON Channels). Changing this to PDS-E, and assuring PDSE caching was
working (old style DFSMS 1.2 or 1.3 with MSR=3ms) took this dataset off the
RADAR and satisfied some series latent demand on that Development system.

Second and more recent example was a transaction-in-batch job with 45 steps
and a SLA of 10 second average. Converting the main application loadlibs to
PDS-E shaved several seconds off the average elapsed time (the customer did
not specify), and later adding PDSE caching with VLF sliced off another 2-3
seconds.

For my own datasets it is just that I hate interrupting what I'm doing with
a compress. I've gone over three years without compressing a PDS, because my
personal datasets are PDSE.

Ron 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Chris Craddock
> Sent: Wednesday, February 10, 2010 6:44 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] PDS vs. PDSE
> 
> On Wed, Feb 10, 2010 at 1:46 PM, John R. Ehrman (408-463-3543 T/543-) <
> ehr...@vnet.ibm.com> wrote:
> 
> > PDSEs have been available for a long time, and provide many
> > advantages over PDSs. Why are people reluctant to use PDSEs?
> >
> 
> 
> As others have pointed out, PDSEs have a (justifiably) bad reputation for
> poor reliability and performance. They also have a litany of limitations
> (e.g. not being able to be used in the IPL-time LPA) that make them less
> useful and/or more complex to deal with than a plain old PDS. Which is
> doubly ironic since it was the limitations of PDSs that drove the creation
> of PDSE in the first place. It is another example of a piece of half
> baked/underfunded functionality where marketing factors trumped business
> needs (e.g. the completely artificial need for PDSEs to be SMS managed)
and
> nobody took the time (i.e. there was no budget) to stitch them into the
> operating system and utilities so that they could actually be used as a
> replacement for PDSs.
> 
> With all that said, the straw man arguments in favor of cross-system
sharing
> of PDS over PDSE demonstrate a lack of understanding of the fundamental
> limitations of the former. For all their faults, PDSEs are actually a
better
> deal for sharing within a SYSPLEX and for most garden variety purposes
they
> work just fine these days. Assuming you keep up with maintenance :-)
> 
> --
> This email might be from the
> artist formerly known as CC
> (or not) You be the judge.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Chris Craddock]

On Wed, Feb 10, 2010 at 1:46 PM, John R. Ehrman (408-463-3543 T/543-) <
ehr...@vnet.ibm.com> wrote:

> PDSEs have been available for a long time, and provide many
> advantages over PDSs. Why are people reluctant to use PDSEs?
>


As others have pointed out, PDSEs have a (justifiably) bad reputation for
poor reliability and performance. They also have a litany of limitations
(e.g. not being able to be used in the IPL-time LPA) that make them less
useful and/or more complex to deal with than a plain old PDS. Which is
doubly ironic since it was the limitations of PDSs that drove the creation
of PDSE in the first place. It is another example of a piece of half
baked/underfunded functionality where marketing factors trumped business
needs (e.g. the completely artificial need for PDSEs to be SMS managed) and
nobody took the time (i.e. there was no budget) to stitch them into the
operating system and utilities so that they could actually be used as a
replacement for PDSs.

With all that said, the straw man arguments in favor of cross-system sharing
of PDS over PDSE demonstrate a lack of understanding of the fundamental
limitations of the former. For all their faults, PDSEs are actually a better
deal for sharing within a SYSPLEX and for most garden variety purposes they
work just fine these days. Assuming you keep up with maintenance :-)

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Howard Brazee]

On 10 Feb 2010 12:09:58 -0800, hmerr...@jackhenry.com (Hal Merritt)
wrote:

>
>PDSE's are very useful, as are PDS's. If you don't need the PDSE features then 
>why bother? You don't see many compelling business/technical cases to convert 
>PDS's to PDSE's. 
>
>My $0.02

Other computers didn't need the advantages of PDS's.   Nor the
disadvantages.   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Blaicher, Chris]

I know of one case where a PDS and PDSE were loaded with 108,297 members.  I'm 
not saying the building was fast in either case, but it can be done.

Personally, I prefer PDS files.  At least I know the structure I am dealing 
with.  And using some tricks, I can get a PDS to outperform a PDSE by a fair 
margin.

Chris Blaicher
Phone: 512-340-6154
Mobile: 512-627-3803
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Tony B.
Sent: Wednesday, February 10, 2010 4:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

A few years ago, inspired by a beverage wager, I allocated a large PDSE,
FB-256,  and started using it to store output listings. Every day it would
accumulate about 300 output files.

  After I accumulated about 2K members I decided to make it interesting.  I
wrote up a sort job that read a test file then wrote multiple output members
to this PDSE.  I kept adding DD cards to hasten collecting on the beverage.
At its peak my sort job wrote 10,000 members in one pass.  I kept rerunnig
this job, changing the output member name, always adding members at the
front of the file.  I kept this up for a few weeks, can't remember the final
number of members, but my colleague paid up.

We never did experience any problems and we did spot check the data from
time to time.

P.S. Belated thanks to Frank Yeager and his DF/SORT web site for the
inspiration to create a lot of records with incrementing sequence numbers.
I used this technique to generate 10,000 DD cards and a like number of
OUTFIL OUTREC statements.  When I have some (more)time to goof around I'll
try this again to see how large a number of output members I can write in 1
passm maybe 32K for grins.  There's probably some limit on DD cards that I
can't recall at the moment.

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Thompson, Steve
Sent: Wednesday, February 10, 2010 2:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of John R. Ehrman (408-463-3543 T/543-)
Sent: Wednesday, February 10, 2010 1:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: PDS vs. PDSE

PDSEs have been available for a long time, and provide many advantages over
PDSs. Why are people reluctant to use PDSEs?
John Ehrman

-

>From my experience, it is a time bomb waiting for the "directory" to get
"fragmented". 

And if you are using objects, lots of luck.

If you want to recreate the situation of which I refer, build a "listing"
PDS/E and run your HLASM Listings out to it. In my experience you will
possibly work OK with this for about 3 months (I was doing 3-20 assembles
per work day) and then things stop working. The only way out is to delete it
and rebuild it. I went back to PDSes and defrag/degas (at short intervals).

The SYSLMOD output from BINDER gets even more screwed up. And the only way
out was delete and rebuild.  

And unless you have them backed up, you just lost the contents. 

Now maybe the problem is, I set them up with a SINGLE extent (about 75
CYLINDERS).

But this is why I don't use them in development. For a relatively static
(from my perspective) file, works OK.

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Andy Wood]

. . .

>PDSEs are ill-documented (not just proprietary code, but proprietary
>data formats!)

Add to that, secret/restricted APIs (the infamous DFSMSdfp Advanced 
Customization Guide).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Tony B.]

A few years ago, inspired by a beverage wager, I allocated a large PDSE,
FB-256,  and started using it to store output listings. Every day it would
accumulate about 300 output files.

  After I accumulated about 2K members I decided to make it interesting.  I
wrote up a sort job that read a test file then wrote multiple output members
to this PDSE.  I kept adding DD cards to hasten collecting on the beverage.
At its peak my sort job wrote 10,000 members in one pass.  I kept rerunnig
this job, changing the output member name, always adding members at the
front of the file.  I kept this up for a few weeks, can't remember the final
number of members, but my colleague paid up.

We never did experience any problems and we did spot check the data from
time to time.

P.S. Belated thanks to Frank Yeager and his DF/SORT web site for the
inspiration to create a lot of records with incrementing sequence numbers.
I used this technique to generate 10,000 DD cards and a like number of
OUTFIL OUTREC statements.  When I have some (more)time to goof around I'll
try this again to see how large a number of output members I can write in 1
passm maybe 32K for grins.  There's probably some limit on DD cards that I
can't recall at the moment.

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Thompson, Steve
Sent: Wednesday, February 10, 2010 2:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of John R. Ehrman (408-463-3543 T/543-)
Sent: Wednesday, February 10, 2010 1:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: PDS vs. PDSE

PDSEs have been available for a long time, and provide many advantages over
PDSs. Why are people reluctant to use PDSEs?
John Ehrman

-

>From my experience, it is a time bomb waiting for the "directory" to get
"fragmented". 

And if you are using objects, lots of luck.

If you want to recreate the situation of which I refer, build a "listing"
PDS/E and run your HLASM Listings out to it. In my experience you will
possibly work OK with this for about 3 months (I was doing 3-20 assembles
per work day) and then things stop working. The only way out is to delete it
and rebuild it. I went back to PDSes and defrag/degas (at short intervals).

The SYSLMOD output from BINDER gets even more screwed up. And the only way
out was delete and rebuild.  

And unless you have them backed up, you just lost the contents. 

Now maybe the problem is, I set them up with a SINGLE extent (about 75
CYLINDERS).

But this is why I don't use them in development. For a relatively static
(from my perspective) file, works OK.

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Tony Harminc]

On 10 February 2010 14:46, John R. Ehrman (408-463-3543 T/543-)
 wrote:
> PDSEs have been available for a long time, and provide many
> advantages over PDSs. Why are people reluctant to use PDSEs?

It's a lot like VSAM catalogues 30-something years ago: There was a
lot of discussion at SHARE and the like before they came out, everyone
agreed there was a requirement, but what IBM came out with was quite
different from what was expected and understood. Various system
restrictions prevented their use in a number of common situations, and
performance generally lagged the previous generation (CVOLs/PDSs).
Then the level of bugs and usability issues dragged on way way too
long, and in the case of VSAM catalogues, a whole new design
eventually replaced the original, with a whole new set of rules, and a
bunch of migration issues that continue to this day.

PDSEs are ill-documented (not just proprietary code, but proprietary
data formats!), fail catastrophically rather than gradually, don't
play nice across systems, offer few advantages and new restrictions
over PDSs.

And by a remarkable coincidence, come from the same lab that invented
VSAM catalogues.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Clark Morris]

On 10 Feb 2010 11:59:39 -0800, in bit.listserv.ibm-main you wrote:

>PDSEs have been available for a long time, and provide many
>advantages over PDSs. Why are people reluctant to use PDSEs?
>John Ehrman

One of the things that I have against the PDSE is the same thing that
I had against SNA attached 3270s, it isn't available at NIP time.
Until you can have SYS1.NUCLEUS either as an extended IPL text or a
PDSE and SYS1.LPALIB as a PDSE, I consider the construct broken. While
I can't speak to the other complaints in this thread from experience,
the restriction on sharing shows lack of understanding of varied
needs.  If organizations are sharing PDSs among sysplexes for
justifiable organizational reasons, then the supposedly safer PDSE
data sets should be at least sharable to the extent there is one
writing sysplex and multiple read only sysplexes.  
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Rick Fochtman]

John Ehrman of the IBM Mainframe Discussion List 
wrote on 02/10/2010 01:46:57 PM:

 


PDSEs have been available for a long time, and provide many
advantages over PDSs. Why are people reluctant to use PDSEs?
   



I think of a few...

1. Lack of internal documentation.
2. Former requirement that they must be SMS managed.
3. No recovery of deleted/updated members.
4. Performance.

I don't see IBM using them very much.  Only nine SYS1 datasets are PO-E.
 


---
I will echo these concerns from John, plus add some more:

1. Too many fairly common applications don't work with PO-E datasets, 
either because of dataset format or content format (program objects 
especially) and lack of documentation thereof.


2. "Directory Fragmentation" in high-number-of-updates situations.

3. Poor recovery mechanisms overall.

Much more openness with documentation would go a LONG way in resolving 
most of these issues. Considering that z/OS has virtually NO competing 
Operating System with anywhere near the RAS features, a little more open 
sharing of documentation would not be painful. Or even (perish the 
thought) source code.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Terri E Shaffer]

Isnt there still a restriction PDSE of NOT being allowed to be in the LPALST? 

Thanks

Ms. Terri E. Shaffer 
terri.e.shaf...@jpmchase.com
Engineer
J.P.Morgan Chase & Co.
GTI DCT ECS Core Services zSoftware Group / Emerging Technologies 
Office: # 614-213-3467
Cell: # 412-519-2592 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
John P Kalinich
Sent: Wednesday, February 10, 2010 3:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDS vs. PDSE

John Ehrman of the IBM Mainframe Discussion List 
wrote on 02/10/2010 01:46:57 PM:

> PDSEs have been available for a long time, and provide many
> advantages over PDSs. Why are people reluctant to use PDSEs?

I think of a few...

1. Lack of internal documentation.
2. Former requirement that they must be SMS managed.
3. No recovery of deleted/updated members.
4. Performance.

I don't see IBM using them very much.  Only nine SYS1 datasets are PO-E.

Regards,
John K

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Ted MacNEIL]

>> I'll take the reliability (of PDS's) any day of the week

Where were you guys when I carped abouit PDSE's last week? (Or, the week 
before?)

>I prefer PDSs as well, but the irony is that the unreliability of PDSs lead to 
>the PDSPAIN White Paper which (in part) lead to PDSEs.

A 'fix' that is less stable than the original problem is no fix!
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Bob Shannon]

> I'll take the reliability (of PDS's) any day of the week

I prefer PDSs as well, but the irony is that the unreliability of PDSs lead to 
the PDSPAIN White Paper which (in part) lead to PDSEs.

Bob Shannon
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John R. Ehrman (408-463-3543 T/543-)
Sent: Wednesday, February 10, 2010 1:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: PDS vs. PDSE

PDSEs have been available for a long time, and provide many
advantages over PDSs. Why are people reluctant to use PDSEs?
John Ehrman

-

>From my experience, it is a time bomb waiting for the "directory" to get
"fragmented". 

And if you are using objects, lots of luck.

If you want to recreate the situation of which I refer, build a
"listing" PDS/E and run your HLASM Listings out to it. In my experience
you will possibly work OK with this for about 3 months (I was doing 3-20
assembles per work day) and then things stop working. The only way out
is to delete it and rebuild it. I went back to PDSes and defrag/degas
(at short intervals).

The SYSLMOD output from BINDER gets even more screwed up. And the only
way out was delete and rebuild.  

And unless you have them backed up, you just lost the contents. 

Now maybe the problem is, I set them up with a SINGLE extent (about 75
CYLINDERS).

But this is why I don't use them in development. For a relatively static
(from my perspective) file, works OK.

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[John P Kalinich]

John Ehrman of the IBM Mainframe Discussion List 
wrote on 02/10/2010 01:46:57 PM:

> PDSEs have been available for a long time, and provide many
> advantages over PDSs. Why are people reluctant to use PDSEs?

I think of a few...

1. Lack of internal documentation.
2. Former requirement that they must be SMS managed.
3. No recovery of deleted/updated members.
4. Performance.

I don't see IBM using them very much.  Only nine SYS1 datasets are PO-E.

Regards,
John K

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Pinnacle]

- Original Message - 
From: "John R. Ehrman , 408-463-3543 T/543-" 

Newsgroups: bit.listserv.ibm-main
Sent: Wednesday, February 10, 2010 2:59 PM
Subject: PDS vs. PDSE



PDSEs have been available for a long time, and provide many
advantages over PDSs. Why are people reluctant to use PDSEs?
John Ehrman



John,

PDSE's have a bad reputation, well-deserved.  The service stream is still 
fairly active for PDSE's, where PDS's are fairly calm.  I only use PDSE's 
where absolutely necessary (i.e. program objects or other software 
distributed in PDSE's).  The only major advantage of a PDSE is dynamic space 
reclaim, but IMNSHO, the risk of using them is not worth that benefit.  So I 
gotta compress some PDS's from time to time.  I'll take the reliability any 
day of the week.


Regards,
Tom Conley 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of John R. Ehrman 
> (408-463-3543 T/543-)
> Sent: Wednesday, February 10, 2010 1:47 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: PDS vs. PDSE
> 
> PDSEs have been available for a long time, and provide many
> advantages over PDSs. Why are people reluctant to use PDSEs?
> John Ehrman

Because many remember the pain inflicted upon them when PDSEs were first 
introduced. And, the fact that a PDSE cannot safely be shared except within a 
single sysplex. So many things are kept in a PDS so that multiple z/OS images 
in multiple sysplexes can use it (especially load libraries for various 
products).

Other than not needing to be compressed, what advantages? I've heard that they 
can have >8 character member names (for DLLs), but that appears to not be 
externalized. Nor useful in JCL. Better to put stuff in a UNIX subdirectory for 
that sort of thing.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[Hal Merritt]

I would guess that PDSE's have not been stable all that long. Many of us run 
multi LPAR shops with shared DASD, and there were sharing issues with z/os 1.7. 

Still get scary messages under z/os 1.9. 

PDSE's are very useful, as are PDS's. If you don't need the PDSE features then 
why bother? You don't see many compelling business/technical cases to convert 
PDS's to PDSE's. 

My $0.02

 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
John R. Ehrman (408-463-3543 T/543-)
Sent: Wednesday, February 10, 2010 1:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: PDS vs. PDSE

PDSEs have been available for a long time, and provide many
advantages over PDSs. Why are people reluctant to use PDSEs?
John Ehrman

 
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDS vs. PDSE

[John Laubenheimer]

On Wed, 10 Feb 2010 11:46:57 -0800, John R. Ehrman (408-463-3543 T/543-
)  wrote:

>PDSEs have been available for a long time, and provide many
>advantages over PDSs. Why are people reluctant to use PDSEs?
>John Ehrman
>
>--
Mostly, this is FUD (Fear, Uncertainty & Doubt).  PDSEs developed a bad 
reputation due to problems which have been correctly by service (which has 
been included in the base of the latest z/OS releases).  A bad reputation is 
difficult to fight off, especially when upper managements gets to have it's 
say.  There is no valid reason to avoid PDSEs today.  You still need to keep on 
top of your service, though.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

PDS vs. PDSE

[John R. Ehrman (408-463-3543 T/543-)]

PDSEs have been available for a long time, and provide many
advantages over PDSs. Why are people reluctant to use PDSEs?
John Ehrman

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html