Another reason to hate PDSE's
Pinnacle
found somehting that blows my mind, a ridiculous limitation in PDSE's that
all by itself militates against their usage.
I'm running a utility that outputs IEBUPDTE cards to create a PDS. When
running the cards, we hit the maximum size of a PDS, 65535 tracks. Any
attempt to go beyond that gets us an E37 abend.
So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE
cards is a member with 68,994,447 records. This member causes an IEC036I
002-A8 abend, Looking that up says that the maximum number of lines that
can be held in a PDSE member is exceeded.
Let that sink in a little. That 68M line member was easily stored in the
PDS before the E37, but PDSE can't handle it. PDSE can't support members as
big as PDS. Are you #$%ing kidding me?
PDSE's are a joke. They've been around for over 20 years, and they still
don't have all the bugs out. This limitation is ridiculous, considering
that PDSE's were supposed to address all the shortcomings of PDS. GUESS
THEY MISSED THIS SHORTCOMING OF PDSE's!!!!!!!!!! WAY TO GO IBM!!!!!!!
Sheesh,
Tom Conley
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Paul Gilmartin
>
>Let that sink in a little. That 68M line member was easily stored in the
>PDS before the E37, but PDSE can't handle it. PDSE can't support members as
>big as PDS. Are you #$%ing kidding me?
>
The NOTE word for a PDSE is a relative line number and an indicator
of the member. Suppose it's 6 bits for the member and 26 for
the line (x2d(3ffffff)==67,108,863 -- will it handle 67 M?)
And if it allows 6 bits for the member, what happens if you do
BLDLs for 65 members, then POINT to each in succession.
This problem arise partly because PDSEs are logically unblocked.
The same would happen if your PDS were unblocked. So what!?
-- gil
Mark Zelden
>I'm running a utility that outputs IEBUPDTE cards to create a PDS. When
>running the cards, we hit the maximum size of a PDS, 65535 tracks. Any
>attempt to go beyond that gets us an E37 abend.
>
>So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE
>cards is a member with 68,994,447 records. This member causes an IEC036I
>002-A8 abend, Looking that up says that the maximum number of lines that
>can be held in a PDSE member is exceeded.
Yep, you went slightly over the limit of 15,728,639
Record number TTRs start at X'100001' within a PDSE member.
Record number TTRs range from X'100001' to X'FFFFFF'.
The maximum number of PDSE members is 522,236.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
Paul Gilmartin
>
>Yep, you went slightly over the limit of 15,728,639
>
> Record number TTRs start at X'100001' within a PDSE member.
> Record number TTRs range from X'100001' to X'FFFFFF'.
>
>The maximum number of PDSE members is 522,236.
>
values for flags?
And d2x(522,236) is 7f7fc. Inexplicable.
-- gil
Pinnacle
From: "Mark Zelden" <mze...@FLASH.NET>
Newsgroups: bit.listserv.ibm-main
Sent: Monday, July 26, 2010 9:52 AM
Subject: Re: Another reason to hate PDSE's
> On Sun, 25 Jul 2010 21:41:42 -0400, Pinnacle <pinn...@ROCHESTER.RR.COM>
> wrote:
>
>>I'm running a utility that outputs IEBUPDTE cards to create a PDS. When
>>running the cards, we hit the maximum size of a PDS, 65535 tracks. Any
>>attempt to go beyond that gets us an E37 abend.
>>
>>So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE
>>cards is a member with 68,994,447 records. This member causes an IEC036I
>>002-A8 abend, Looking that up says that the maximum number of lines that
>>can be held in a PDSE member is exceeded.
>
> Yep, you went slightly over the limit of 15,728,639
>
> Record number TTRs start at X'100001' within a PDSE member.
> Record number TTRs range from X'100001' to X'FFFFFF'.
>
> The maximum number of PDSE members is 522,236.
>
Z,
Is this documented anywhere? I searched Using Datasets and came up empty.
Tom
Clark Morris
>Some months ago, John Ehrman posted asking why we don't like PDSE's. I just
>found somehting that blows my mind, a ridiculous limitation in PDSE's that
>all by itself militates against their usage.
>
>I'm running a utility that outputs IEBUPDTE cards to create a PDS. When
>running the cards, we hit the maximum size of a PDS, 65535 tracks. Any
>attempt to go beyond that gets us an E37 abend.
>
>So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE
>cards is a member with 68,994,447 records. This member causes an IEC036I
>002-A8 abend, Looking that up says that the maximum number of lines that
>can be held in a PDSE member is exceeded.
>
>Let that sink in a little. That 68M line member was easily stored in the
>PDS before the E37, but PDSE can't handle it. PDSE can't support members as
>big as PDS. Are you #$%ing kidding me?
>
>PDSE's are a joke. They've been around for over 20 years, and they still
>don't have all the bugs out. This limitation is ridiculous, considering
>that PDSE's were supposed to address all the shortcomings of PDS. GUESS
>THEY MISSED THIS SHORTCOMING OF PDSE's!!!!!!!!!! WAY TO GO IBM!!!!!!!
Could Unix directories handle all of the functions of PDSE? When I
read that we would still need PDSs, I wondered what pointy haired
idiot designed the PDSE where one needed a started address space even
to read it.
Clark Morris
Mark Zelden
>On Mon, 26 Jul 2010 08:51:31 -0500, Mark Zelden wrote:
>>
>>Yep, you went slightly over the limit of 15,728,639
>>
>> Record number TTRs start at X'100001' within a PDSE member.
>> Record number TTRs range from X'100001' to X'FFFFFF'.
>>
>>The maximum number of PDSE members is 522,236.
>>
>Hmmm. d2x(15,728,639) is efffff. Do they reserve the lower
>values for flags?
>
Did you note the starting TTR? X'FFFFFF' - X'100001' + 1 is 15,728,639.
>And d2x(522,236) is 7f7fc. Inexplicable.
>
Yeah, I never figured that one out exactly. The number is fairly close to the
highest TTR for a member, which is X'07FFFF'.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------
Mark Zelden
>>
>> Yep, you went slightly over the limit of 15,728,639
>>
>> Record number TTRs start at X'100001' within a PDSE member.
>> Record number TTRs range from X'100001' to X'FFFFFF'.
>>
>> The maximum number of PDSE members is 522,236.
>>
>
>Is this documented anywhere? I searched Using Datasets and came up empty.
>
Yes, it is in DFSMS Using Data Sets. At least at z/OS 1.10 and above (I
didn't check earlier):
MAXIMUM MEMBERS IN A PDSE:
MAXIMUM RECORDS (LINES) IN A PDSE MEMBER:
Don Williams
expect that one was to store multiple data sets per track. Of course, these
would tend to be small data sets. I expect that IBM assumed that very few
customers, if any, had very large members. Therefore when they designed a
replacement, PDSE, handling large members was not likely to be a high
priority. Of course, that does not help you, but I can easily see the PDSE
designers asking, his member has how many lines?
Pinnacle
From: "Mark Zelden" <mze...@FLASH.NET>
Newsgroups: bit.listserv.ibm-main
Subject: Re: Another reason to hate PDSE's
> On Mon, 26 Jul 2010 10:13:54 -0400, Pinnacle <pinn...@ROCHESTER.RR.COM>
> wrote:
>
>>>
>>> Yep, you went slightly over the limit of 15,728,639
>>>
>>> Record number TTRs start at X'100001' within a PDSE member.
>>> Record number TTRs range from X'100001' to X'FFFFFF'.
>>>
>>> The maximum number of PDSE members is 522,236.
>>>
>>
>>Is this documented anywhere? I searched Using Datasets and came up empty.
>>
>
> Yes, it is in DFSMS Using Data Sets. At least at z/OS 1.10 and above (I
> didn't check earlier):
>
> MAXIMUM MEMBERS IN A PDSE:
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.2?SHELF=DGT2BK81&DT=20080602122917
>
>
>
> MAXIMUM RECORDS (LINES) IN A PDSE MEMBER:
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.2.4?SHELF=DGT2BK81&DT=20080602122917&CASE=
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.3?SHELF=DGT2BK81&DT=20080602122917
>
Thanks, it explains why my searches came up empty. I didn't have time to
read the whole PDSE section. What a crappy design. The maximum PDSE member
size should have been at least the number of 80-byte records that would have
filled up a 65535 track PDS. Brain dead.
Regards,
Tom Conley
Bill Fairchild
And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? But Tom Conley has an excellent point that the maximum size of a PDS member should be supported by any redesign. E.g., I have seen some large PDSes that consisted of only a directory. One example is SMP. Another was a customer file I ran across decades ago where an entire volume was a PDS with only a directory in it; i.e., all directory entries and no members.
Bill Fairchild
Rocket Software
David Andrews
> What a crappy design. [...] Brain dead.
I'm inclined to give the PDSE designers a little more credit. One of
the PDSPAIN White Paper's requirements was "not another VSAM" - at the
time we were struggling with the filesystem-within-a-filesystem mashup
that was VSAM suballocated space. Thank FSM they stopped short of that.
--
David Andrews
A. Duda and Sons, Inc.
david....@duda.com
Paul Gilmartin
>
>Could Unix directories handle all of the functions of PDSE? When I
>read that we would still need PDSs, I wondered what pointy haired
>idiot designed the PDSE where one needed a started address space even
>to read it.
>
entirely and use native Unix services.
-- gil
Paul Gilmartin
>I'm not sure what IBM's PDS design objectives were in the early '60s, but I
>expect that one was to store multiple data sets per track. Of course, these
>would tend to be small data sets. I expect that IBM assumed that very few
>customers, if any, had very large members. Therefore when they designed a
>replacement, PDSE, handling large members was not likely to be a high
>priority. Of course, that does not help you, but I can easily see the PDSE
>designers asking, his member has how many lines?
>
There are only three "nice" numbers: 0, 1, and "as many as you like".
15,000,000 is not one of those.
Paul Gilmartin
>
>And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? But Tom Conley has an excellent point that the maximum size of a PDS member should be supported by any redesign. E.g., I have seen some large PDSes that consisted of only a directory. One example is SMP. Another was a customer file I ran across decades ago where an entire volume was a PDS with only a directory in it; i.e., all directory entries and no members.
>
The design suffered a compatibility constraint: how do you divide up
a 32-bit NOTE word to support both more members and more records.
They might have done better by not allowing the soft blocking.
But then they'd need to somehow index variable size blocks.
Ted MacNEIL
No, just like standard PS, it's tracks.
Regardless of what you specify, DADSM translates to tracks, in the VTOC.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
Howard Brazee
Morris) wrote:
>Could Unix directories handle all of the functions of PDSE? When I
>read that we would still need PDSs, I wondered what pointy haired
>idiot designed the PDSE where one needed a started address space even
>to read it.
I don't even like ordinary PDS. Other operating systems don't need
them.
Ted MacNEIL
That doesn't make them wrong.
There are some implementation flaws, but they exist, so use them, and know flaws and repairs.
PS: Can you spell DLL?
Mark Zelden
>And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks?
No, it's 64K tracks. It is the same "per volume" limit as many other
data set types (non-extended). But PDSes and PDSEs are also limited
to a single volume.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------
Eric Bielefeld
--
Eric Bielefeld
Systems Programmer
---- Bill Fairchild <Bi...@MAINSTAR.COM> wrote:
> And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? But Tom Conley has an excellent point that the maximum size of a PDS member should be supported by any redesign. E.g., I have seen some large PDSes that consisted of only a directory. One example is SMP. Another was a customer file I ran across decades ago where an entire volume was a PDS with only a directory in it; i.e., all directory entries and no members.
>
> Bill Fairchild
> Rocket Software
----------------------------------------------------------------------
John P Kalinich
real member data exists. TTR pointers are zero.
Regards,
John K
From: Eric Bielefeld <eric-i...@WI.RR.COM>
To: IBM-...@bama.ua.edu
Date: 07/26/2010 01:41 PM
Subject: Re: Another reason to hate PDSE's
Barbara Nitz
>data set types (non-extended). But PDSes and PDSEs are also limited
>to a single volume.
I am surprised. I did not know about *those* limitations. And most certainly,
since they are documented, there will be no way to change things.
But: I seem to remember that PDSEs were touted as the only ones making
sense on an EAV, because of the 'extented' part of the name, and that they
could get bigger (but maybe I misunderstood). Not that I would encourage use
of such a large volume, as it is much too slow, and I still haven't opened an
ETR to address 90s (or more) until ISPF 3.4 gives you the directory view.
(Might end up on an ISPF queue, which would require me to open a complaint
due to incompetence.)
PDSEs have only one advantage: They don't need to get compressed. The
rest us a huge amount of disadvantages.
Regards, Barbara
Steve Comstock
>> No, it's 64K tracks. It is the same "per volume" limit as many other
>> data set types (non-extended). But PDSes and PDSEs are also limited
>> to a single volume.
>
> I am surprised. I did not know about *those* limitations. And most certainly,
> since they are documented, there will be no way to change things.
>
> But: I seem to remember that PDSEs were touted as the only ones making
> sense on an EAV, because of the 'extented' part of the name, and that they
> could get bigger (but maybe I misunderstood). Not that I would encourage use
> of such a large volume, as it is much too slow, and I still haven't opened an
> ETR to address 90s (or more) until ISPF 3.4 gives you the directory view.
> (Might end up on an ISPF queue, which would require me to open a complaint
> due to incompetence.)
>
> PDSEs have only one advantage: They don't need to get compressed. The
> rest us a huge amount of disadvantages.
>
> Regards, Barbara
Well, they do have at least one other advantage: they can store
program objects, which allows entry points with long, case-sensitive
names, which is sometimes handy.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
R.S.
> Barbara Nitz wrote:
[...]
>> PDSEs have only one advantage: They don't need to get compressed. The
>> rest us a huge amount of disadvantages.
>>
>> Regards, Barbara
>
> Well, they do have at least one other advantage: they can store
> program objects, which allows entry points with long, case-sensitive
> names, which is sometimes handy.
While I could provide more PDSE advantages than Barbara, I would not
mention long names.
Reason: I HAVE NEVER SEEN AN APPLICATION WHICH USES THEM. Long names are
not handy for me. Of course I know, there are some... but not in
operating system components.
--
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 0000025237
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.
Paul Gilmartin
>Steve Comstock pisze:
>> Barbara Nitz wrote:
>[...]
>>> PDSEs have only one advantage: They don't need to get compressed. The
>>> rest us a huge amount of disadvantages.
>>>
>>> Regards, Barbara
>>
And, I believe, multiple members can be written concurrently (I
believe; am I right?) How would one do this? Must one OPEN two or
more DCBs, one for each member being written? And one might yet
wish to be able to append or update in place existing members.
>> Well, they do have at least one other advantage: they can store
>> program objects, which allows entry points with long, case-sensitive
>> names, which is sometimes handy.
>
Steve, why would you call that an advantage? I thought you despise
case-sensitivity. Anyway, old fashioned PDSes allow case-sensitive
(but not long) member names; it's merely higher level interfaces that
try to conceal the case-sensitivity. Would you advocate supporting
case-insensitivity at the DFSMS layer, similar to Windows? Mac OS X
gives the programmer a choice with a granularity of volume.
>While I could provide more PDSE advantages than Barbara, I would not
>mention long names.
>
>Reason: I HAVE NEVER SEEN AN APPLICATION WHICH USES THEM. Long names are
>not handy for me. Of course I know, there are some... but not in
>operating system components.
>
Isn't this a solution seeking a problem? What interfaces support them?
Surely, one can't code // EXEC PGM=Case-sensitive-Long-name? What about
ATTACH EP=Case-sensitive-Long-name?
What's the format of the word returned by NOTE for a PDSE. It's
been discussed here that the low 24 bits contain the relative
record number within a member (biased by 0x100000). Do the top 8
bits then identify the member? What happens, then, if a programmer
performs BLDL for 257 different members? can the NOTE words
identify connections to all? If one performs 2 BLDLs for the
same member, are the two returned pointers identical?
How do Unix directories compare?
o They don't need to be compressed.
o Multiple members can be written concurrently.
o Members can be appended or updated in place (with a granularity
of byte.).
o They support long case-sensitive names.
o They allow a mixture of program objects and other member types.
Deficiencies:
o Alias entry points are not supported (AFAIK).
o The BPAM support is read-only (so far).
Questions:
o How do performance and reliablity compare with PDS[E]? I suppose
there might be four answers, separate for PDS vs. PDSE and for
HFS vs. zFS.
o What is the limit on member size?
o What is the limit on number of members?
-- gil
Chris Craddock
>
>> PDSEs have only one advantage: <snip>
>>
>
> Well, they do have at least one other advantage: they can store
> program objects, which allows entry points with long, case-sensitive
> names, which is sometimes handy.
>
No not really. Longer names may be contained within the program object, e.g.
"CALL someverylongname" and the binder will make sense of it. External
entrypoints (those that could be used by ATTACH, LINK etc.) are still only 8
bytes long.
--
This email might be from the
artist formerly known as CC
(or not) You be the judge.
Paul Gilmartin
>>I don't even like ordinary PDS. Other operating systems don't need them.
>
>That doesn't make them wrong.
>There are some implementation flaws, but they exist, so use them, and know flaws and repairs.
>
If you don't understand what's wrong with PDS, re-read Etienne Thijsse's
thread on attempting to delete a PDSE member. Or imagine my astonished
dismay the first time I allocated a member with DISP=(OLD,DELETE) and
watched the entire PDS vanish. Enough counterintuitive behaviors and "flaws"
with recondite repairs add up to "wrong".
>PS: Can you spell DLL?
>
Nobody's perfect; that's no excuse.
-- gil
Ted MacNEIL
thread on attempting to delete a PDSE member.
I didn't say I didn't understand, I said that you had to do so.
Understand their limitations, and how to fix them when they break.
They're not going away.
>Or imagine my astonished
dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish.
That is documented in so many places.
The JCL Manual/User's Guide (or whatever IBM's calling it/them now), for example, and
nowhere does it say DISP works at the member level.
The explanation of DISP is at the dataset level, everywhere I've looked.
>Enough counterintuitive behaviors
You can't blame PDS(E) for 45+ years of documented behaviour.
>and "flaws" with recondite repairs add up to "wrong".
Possibly, but there are many cases in z/OS where you are stuck with them.
I'm not a fan of PDSE, anymore, since IBM broke them circa 2003.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
----------------------------------------------------------------------
Kirk Wolf
PDSEs as with PDS when updating members?
McKown, John
> From: IBM Mainframe Discussion List
> Sent: Tuesday, July 27, 2010 1:52 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: Another reason to hate PDSE's
>
> PDSEs as with PDS when updating members?
Yes.
--
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....@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
Kirk Talman
DISP=(OLD,DELETE) and watched the entire PDS vanish.
In the early 1970s, at a bank using MVT on 370/155, soon after DOS-OS
conversion, all procs were stored in SYS1.PROCLIB. Excessively neat
programmer deleted a member using that technique. System was unbootable.
When the system came back after the sysgen (no backup res pack!), an
APPL.PROCLIB was created and all SYS1 datasets were password protected.
Ops was not given the password.
So in 40 yrs, the same design flaw has bit how many people/shops?
On the other hand, most programs I wrote in the 1960s would run today, if
there were still card readers.
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you
Rick Fochtman
> Barbara Nitz wrote:
>
>>> No, it's 64K tracks. It is the same "per volume" limit as many other
>>> data set types (non-extended). But PDSes and PDSEs are also limited
>>> to a single volume.
>>
>>
>> I am surprised. I did not know about *those* limitations. And most
>> certainly, since they are documented, there will be no way to change
>> things.
>>
>> But: I seem to remember that PDSEs were touted as the only ones
>> making sense on an EAV, because of the 'extented' part of the name,
>> and that they could get bigger (but maybe I misunderstood). Not that
>> I would encourage use of such a large volume, as it is much too slow,
>> and I still haven't opened an ETR to address 90s (or more) until ISPF
>> 3.4 gives you the directory view. (Might end up on an ISPF queue,
>> which would require me to open a complaint due to incompetence.)
>>
>> PDSEs have only one advantage: They don't need to get compressed. The
>> rest us a huge amount of disadvantages.
>>
>> Regards, Barbara
>
>
> Well, they do have at least one other advantage: they can store
> program objects, which allows entry points with long, case-sensitive
> names, which is sometimes handy.
----------------------------------------<unsnip>---------------------------------------
Steve, I'm incredibly happy you said "SOMETIMES", because I've lived
with 8-character PDS member names for 40+ years and never could think of
a really severe need for the variations you suggest. :-)
Rick
Ted MacNEIL
I don't think it's OT, but the answer is YES.
PDSEs, while different under the covers, still look like PDS's to the uninitiated (programmes, not people).
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
----------------------------------------------------------------------
Rick Fochtman
If you don't understand what's wrong with PDS, re-read Etienne Thijsse's
thread on attempting to delete a PDSE member. Or imagine my astonished
dismay the first time I allocated a member with DISP=(OLD,DELETE) and
watched the entire PDS vanish. Enough counterintuitive behaviors and "flaws"
with recondite repairs add up to "wrong".
I submit that this issue was caused by a faulty understanding of how
PDS's and JCL
work together. You can view it as a flaw if you like, and I do, but
there are provided
mechanisms to circumvent this "flaw". Not always nice and certainly not
intuitive,
but still available.
Rick
Paul Gilmartin
>> Or imagine my astonished dismay the first time I allocated a member with
>DISP=(OLD,DELETE) and watched the entire PDS vanish.
>
>In the early 1970s, at a bank using MVT on 370/155, soon after DOS-OS
>conversion, all procs were stored in SYS1.PROCLIB. Excessively neat
>programmer deleted a member using that technique. System was unbootable.
>
>When the system came back after the sysgen (no backup res pack!), an
>APPL.PROCLIB was created and all SYS1 datasets were password protected.
>Ops was not given the password.
>
>So in 40 yrs, the same design flaw has bit how many people/shops?
>
But none of those should perceive a problem, since the behavior
is documented.
-- gil
Steve Comstock
> On Tue, 27 Jul 2010 12:26:50 +0200, R.S. wrote:
>
>> Steve Comstock pisze:
>>> Barbara Nitz wrote:
>> [...]
>>>> PDSEs have only one advantage: They don't need to get compressed. The
>>>> rest us a huge amount of disadvantages.
>>>>
>>>> Regards, Barbara
> And, I believe, multiple members can be written concurrently (I
> believe; am I right?) How would one do this? Must one OPEN two or
> more DCBs, one for each member being written? And one might yet
> wish to be able to append or update in place existing members.
>
>>> Well, they do have at least one other advantage: they can store
>>> program objects, which allows entry points with long, case-sensitive
>>> names, which is sometimes handy.
> Steve, why would you call that an advantage? I thought you despise
> case-sensitivity.
I do. But in some environments (e.g., DLLs, C, C++) it is a fact of life.
If you want to port / use applications from the z/OS world it is good
to have the ability.
Anyway, old fashioned PDSes allow case-sensitive
> (but not long) member names; it's merely higher level interfaces that
> try to conceal the case-sensitivity.
Ah, good point. I'd forgotten that, since the interfaces I work
with day to day are exactly of that type.
Would you advocate supporting
> case-insensitivity at the DFSMS layer, similar to Windows? Mac OS X
> gives the programmer a choice with a granularity of volume.
Not sure on that one.
>
>> While I could provide more PDSE advantages than Barbara, I would not
>> mention long names.
>>
>> Reason: I HAVE NEVER SEEN AN APPLICATION WHICH USES THEM. Long names are
>> not handy for me. Of course I know, there are some... but not in
>> operating system components.
>>
> Isn't this a solution seeking a problem? What interfaces support them?
> Surely, one can't code // EXEC PGM=Case-sensitive-Long-name? What about
> ATTACH EP=Case-sensitive-Long-name?
Well, you can call DLL entry points from Assembler, COBOL, C, and PL/I.
But you can't invoke them from JCL, that's true. Nor can you LOAD,
XCTL, or ATTACH to long entry points. But several bpx.... services can
access a long, mixed case, entry name. I admit, it's a stretch. The
average day-to-day application programmer does not have a need / use
for this feature, at least not today, and one has to work at it to be
able to use it.
>
> What's the format of the word returned by NOTE for a PDSE. It's
> been discussed here that the low 24 bits contain the relative
> record number within a member (biased by 0x100000). Do the top 8
> bits then identify the member? What happens, then, if a programmer
> performs BLDL for 257 different members? can the NOTE words
> identify connections to all? If one performs 2 BLDLs for the
> same member, are the two returned pointers identical?
>
> How do Unix directories compare?
>
> o They don't need to be compressed.
>
> o Multiple members can be written concurrently.
>
> o Members can be appended or updated in place (with a granularity
> of byte.).
>
> o They support long case-sensitive names.
>
> o They allow a mixture of program objects and other member types.
>
> Deficiencies:
>
> o Alias entry points are not supported (AFAIK).
>
> o The BPAM support is read-only (so far).
>
> Questions:
>
> o How do performance and reliablity compare with PDS[E]? I suppose
> there might be four answers, separate for PDS vs. PDSE and for
> HFS vs. zFS.
>
> o What is the limit on member size?
>
> o What is the limit on number of members?
>
> -- gil
Well, I've been getting more and more into the z/OS UNIX world,
and I think you've raised some good questions / concerns here.
But based on a thread last year (or was it two years ago), there
seems to be precious little management interest in, or support for,
developing new applications using z/OS UNIX, and the systems folks
on ibm-main are certainly not big fans (for the most part, anyway),
eh Barbara?
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
----------------------------------------------------------------------
Clark Morris
Given the obscure program names, proc names and member names we have
due to the 8 character limitation, I for one would have liked names to
be at least 16 characters. In fact I still would and the 8 byte
limitation must seem weird and out of date to someone coming from a
UNIX or Windows environment.
Clark Morris
Clark Morris
>On Tue, 27 Jul 2010 15:42:57 -0400, Kirk Talman wrote:
>
>>> Or imagine my astonished dismay the first time I allocated a member with
>>DISP=(OLD,DELETE) and watched the entire PDS vanish.
>>
>>In the early 1970s, at a bank using MVT on 370/155, soon after DOS-OS
>>conversion, all procs were stored in SYS1.PROCLIB. Excessively neat
>>programmer deleted a member using that technique. System was unbootable.
>>
>>When the system came back after the sysgen (no backup res pack!), an
>>APPL.PROCLIB was created and all SYS1 datasets were password protected.
>>Ops was not given the password.
>>
>>So in 40 yrs, the same design flaw has bit how many people/shops?
>>
>But none of those should perceive a problem, since the behavior
>is documented.
Just because a stupid design is documented doesn't make it any less
stupid.
Clark Morris
Ted MacNEIL
True.
But, people should not be taken by surprise by something that is well known.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
----------------------------------------------------------------------
Barbara Nitz
> program objects, which allows entry points with long, case-sensitive
> names, which is sometimes handy.
>But based on a thread last year (or was it two years ago), there
>seems to be precious little management interest in, or support for,
>developing new applications using z/OS UNIX, and the systems folks
>on ibm-main are certainly not big fans (for the most part, anyway),
>eh Barbara?
okay, I'll bite:
>Long entry points.
Have you ever seen a dump of an address space running some sort of
Websphere? Almost *all* of those lmod names are 'long', usually
called 'specialname'. And I don't talk about Java here.
> How do Unix directories compare?
> o They don't need to be compressed.
> o Multiple members can be written concurrently.
> o Members can be appended or updated in place (with a granularity
> of byte.).
> o They support long case-sensitive names.
> o They allow a mixture of program objects and other member types.
You're all aware that the original HFSs are based on PDSE code, right? In fact,
they use the same lower levels like media manager to do the actual IO, and on
top of that IGW.. (i.e. PDSE) modules, and then it starts to be different. As far
as I know, all of the above is a characteristic of PDSEs, that HFSs just happen
to use. And I bet it wasn't too hard (given that media manager uses 4K blocks,
anyway) to put the HFS functionality into zFS, which are VSAM linear using 4K
blocks.
> Questions:
> o How do performance and reliablity compare with PDS[E]? I suppose
> there might be four answers, separate for PDS vs. PDSE and for
> HFS vs. zFS.
Take a look at my performance problems with (not-even-*that*-) large
PDSEs. At least one other installation has the same issue, and I bet there are
more out there. Performance of larger PDSE is abysmal, but the limits of PDSs
(they cannot be allocated larger than 64K tracks) force us to use them.
PDS outperforms PDSE for allocations lower than 64K tracks. And that can be
directly attributed to the design of PDSEs - their 'directory' is not in one place
like in PDS's, but scattered throughout the dataset. So in order to get the full
directory of the PDSE (10.000 member), in our case it takes more than 10.000
IOs (verified by looking at the SMF records) to get the directory. The long
time (more than 90seconds) to get that list can be directly attributed to the
time it takes for the IO to come back. Remedy is to have a program that keeps
the dataset open artificially, but that only helps for the first about 15 minutes
after the first real access.
I have also mentioned it before: Back when we ran Lotus Notes on z/OS, we
migrated those HFSs to zFS first chance we got (on IBMs urgent
recommendation, when the performance was bad). Fat lot of good it did. After
about 6 months we went back to HFS, and they were *faster* than zFS, due
to the fact that in those days the HFS/PDSE directory must have been stored
differently. A 'recopy' or 'reorg' in those days made directory access faster,
and then performance of the HFS was better than via zFS. That was more
than 5 years ago. (And Lotus Notes now runs on zLinux). Some design change
in PDSE took away that 'reorg' capability (that boosted performance), so
recopying it these days has no effect whatsoever. That's when I invented
my 'just-do-an-open' program.
And the funny thing is, when PDSEs came out about MVS 4.3 (or was it 4.2
and the corresponding SMS version), I really liked them. Still do for *small*
datasets.
But I also think that if they hadn't been foisted on us, then IBM would have
just as happily found a way to make long names and all the new functionality
possible these days only via PDSE for PDSs. As I understand it, back then
customers complained about the need for reorganization. And using PDSE code
for HFSs (now 'functionally stabilized') was just a marketing ploy to force the
world to use PDSEs, IMO. Just like RRSs (or CICSs) use of logger was a way to
get system looger more widely accepted. Just as 'giving away' a WAS
underneath z/OSMF ('at no cost') is a way to enforce usage of WAS on z/OS.
And new functionality will be forced to use z/OSMF, just to get customers
needing that functionality to use z/OSMF.
Barbara
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Tuesday, July 27, 2010 12:06 PM
To: IBM-...@bama.ua.edu
Subject: Re: Another reason to hate PDSE's
<SNIP>
If you don't understand what's wrong with PDS, re-read Etienne Thijsse's
thread on attempting to delete a PDSE member. Or imagine my astonished
dismay the first time I allocated a member with DISP=(OLD,DELETE) and
watched the entire PDS vanish. Enough counterintuitive behaviors and
"flaws"
with recondite repairs add up to "wrong".
<SNIPPAGE>
I suppose that if I were to work with a VSAM file with
DISP=(SHR,DELETE), that it would be JCL's fault when the VSAM file goes
to the bit bucket.
And if you were using a data base that you have to point to, and you
wanted to delete a row and coded DISP=(OLD,DELETE), that would be JCL's
fault also.
Later,
Steve Thompson
Paul Gilmartin
>
><SNIP>
>If you don't understand what's wrong with PDS, re-read Etienne Thijsse's
>thread on attempting to delete a PDSE member. Or imagine my astonished
>dismay the first time I allocated a member with DISP=(OLD,DELETE) and
>watched the entire PDS vanish. Enough counterintuitive behaviors and
>"flaws"
>with recondite repairs add up to "wrong".
>
><SNIPPAGE>
>
>I suppose that if I were to work with a VSAM file with
>DISP=(SHR,DELETE), that it would be JCL's fault when the VSAM file goes
>to the bit bucket.
>
>And if you were using a data base that you have to point to, and you
>wanted to delete a row and coded DISP=(OLD,DELETE), that would be JCL's
>fault also.
>
what you mean by a VSAM file?) I'd expect a JCL error for "(SHR,DELETE)"
since exclusive access is required for DELETE.
In the second case, if DSN= identifies a particular row (is this
syntactically possible?), I'd intuitively expect that one row to be
deleted; if DSN= identifies the entire data base, the entire data
base should be deleted.
We are burdened nowadays with Byzantine behaviors that were a
necessary accommodation to resource constraints that prevailed
45 years ago. Today, if the programmer codes DSN=DATA.SET(MEMBER),
DISP=(OLD,DELETE), it should be easy enough for deallocation to
issue a STOW to delete that specific member.
The PDS itself is an accommodation to such an antiquated constraint.
In 1965 it was elegant; nowadays it's a quaint PITA.
-- gil
Silvio Camplani
ShopZ?
Thanks,
Silvio
McKown, John
--
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....@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
Shmuel Metz , Seymour J.
at 11:47 AM, Howard Brazee <howard...@CUSYS.EDU> said:
>I don't even like ordinary PDS. Other operating systems don't need
>them.
ITYM that they call them something else.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Clark Morris
>In <ahir46pl6pf37rnd7...@4ax.com>, on 07/26/2010
> at 11:47 AM, Howard Brazee <howard...@CUSYS.EDU> said:
>
>>I don't even like ordinary PDS. Other operating systems don't need
>>them.
>
>ITYM that they call them something else.
>
I know that VSE has/had libraries and I wouldn't be surprised if the
OS400 and follow-on operating systems had similar constructs. I don't
know anything about the BUNCH operating systems and their successors.
I don't see anything comparable in either Unix/Linux or Windows.
Clark Morris
Paul Gilmartin
>In <ahir46pl6pf37rnd7...@4ax.com>, on 07/26/2010
> at 11:47 AM, Howard Brazee said:
>
>>I don't even like ordinary PDS. Other operating systems don't need
>>them.
>
>ITYM that they call them something else.
>
I see it differently. I assume the "something else" in other OSes is
a directory or a folder. Usually, these differ from PDS[E]s in
significant respects:
o When a member is deleted the space it occupied is immediately
reclaimed (not PDS), and even released to the parent filesystem.
o Directories may contain both program objects and non-program
objects (whether wisely or not).
o Directories may contain subdirectories.
o Directories may contain aliases (shortcuts, links, symlinks)
to objects in other directories.
Enough functional differences to not consider them synonymous.
-- gil
Ted MacNEIL
DLL's are comparable.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
----------------------------------------------------------------------
Thomas David Rivers
>>I don't see anything comparable in either Unix/Linux or Windows.
>>
>>
>
>DLL's are comparable.
>
>-
>
>
I'm not sure I follow this - just how are DLL's comparable to PDS's?
- Dave Rivers -
--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Ted MacNEIL
They hold more than one 'member' of executable run time modules, similar to SEERUN, for example.
Even the name 'Dynamic Link Library' could be comparable.
But, remember 'comparable' does not mean exact.
They are also more limited than z/OS libraries.
Also, multi-membered ZIP files could be (loosely) compared, as well.
Somebody stated there were no equivalents on other OS's.
At the risk of being pedantic, I came up with an example.
zMan
describe them to the PC kids I work with...
On Thu, Jul 29, 2010 at 4:24 PM, Ted MacNEIL <eama...@yahoo.ca> wrote:
> <snip>
Somebody stated there were no equivalents on other OS's.
>
> At the risk of being pedantic, I came up with an example.
>
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 09:54 AM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>I see it differently. I assume the "something else" in other OSes is
>a directory or a folder.
Or something else.
>Enough functional differences to not consider them synonymous.
Then it's a good thing that I was not referring to directories.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 11:14 AM, Clark Morris <cfmp...@NS.SYMPATICO.CA> said:
>I don't know anything about the BUNCH operating systems and their
>successors.
The had libraries, in some cases with better interfaces than PDS's.
>I don't see anything comparable in either Unix/Linux or Windows.
DLL's are vaguely comparable, but I was thinking of mainframe
operating systems.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------