In du2356lef63ibf2hqc4fgng1rrd62u9...@4ax.com, on 07/29/2010
at 11:14 AM, Clark Morris cfmpub...@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
On 28 Jul 2010 21:07:47 -0700, in bit.listserv.ibm-main you wrote:
In ahir46pl6pf37rnd70alkbiutp8vv4h...@4ax.com, on 07/26/2010
at 11:47 AM, Howard Brazee howard.bra...@cusys.edu said:
I don't even like ordinary PDS. Other operating systems don't need
them.
ITYM that they call them
On Wed, 28 Jul 2010 21:49:34 -0400, Shmuel Metz (Seymour J.) wrote:
In ahir46pl6pf37rnd70alkbiutp8vv4h...@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
I don't see anything comparable in either Unix/Linux or Windows.
DLL's are comparable.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
Ted MacNEIL wrote:
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.comWork: (919) 676-0847
Get your mainframe
I'm not sure I follow this - just how are DLL's comparable to PDS's?
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
Sure. Heck, a single-level subdirectory is similar to a PDS! That's how I
describe them to the PC kids I work with...
On Thu, Jul 29, 2010 at 4:24 PM, Ted MacNEIL eamacn...@yahoo.ca wrote:
snip
Somebody stated there were no equivalents on other OS's.
At the risk of being pedantic, I came up
In listserv%201007290954519942.0...@bama.ua.edu, on 07/29/2010
at 09:54 AM, Paul Gilmartin paulgboul...@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
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Tuesday, July 27, 2010 12:06 PM
To: IBM-MAIN@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
On Wed, 28 Jul 2010 10:04:52 -0400, Thompson, Steve wrote:
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
In ahir46pl6pf37rnd70alkbiutp8vv4h...@4ax.com, on 07/26/2010
at 11:47 AM, Howard Brazee howard.bra...@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
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
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
Well, they do have at least one other advantage: they can store
program objects, which allows entry points with
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
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.
http://bama.ua.edu/archives/ibm-main.html
No not really. Longer names may be
On Mon, 26 Jul 2010 17:57:07 +, Ted MacNEIL wrote:
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
If you don't understand what's wrong with PDS, re-read Etienne Thijsse's
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
A little OT, but just wondering: does ISPF do the same ENQs for
PDSEs as with PDS when updating members?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message:
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Kirk Wolf
Sent: Tuesday, July 27, 2010 1:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Another reason to hate PDSE's
A little OT, but just wondering: does ISPF do the same ENQs
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
-snip
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
A little OT, but just wondering: does ISPF do the same ENQs for PDSEs as
with PDS when updating members?
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
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)
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
Paul Gilmartin wrote:
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
On 27 Jul 2010 13:18:29 -0700, in bit.listserv.ibm-main you wrote:
-snip
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
On 27 Jul 2010 14:17:48 -0700, in bit.listserv.ibm-main you wrote:
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
Just because a stupid design is documented doesn't make it any less stupid.
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!
--
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.
But based on a thread last year (or was it two years ago), there
seems to be precious little management interest in, or support
On Sun, 25 Jul 2010 21:41:42 -0400, Pinnacle pinnc...@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,
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'11' within a PDSE member.
Record number TTRs range from X'11' to X'FF'.
The maximum number of PDSE members is 522,236.
Hmmm.
- Original Message -
From: Mark Zelden mzel...@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 pinnc...@rochester.rr.com
wrote:
I'm running a utility that outputs
On 25 Jul 2010 18:42:52 -0700, in bit.listserv.ibm-main you wrote:
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
On Mon, 26 Jul 2010 09:10:16 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
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'11' within a PDSE member.
Record number TTRs range from X'11' to
On Mon, 26 Jul 2010 10:13:54 -0400, Pinnacle pinnc...@rochester.rr.com wrote:
Yep, you went slightly over the limit of 15,728,639
Record number TTRs start at X'11' within a PDSE member.
Record number TTRs range from X'11' to X'FF'.
The maximum number of PDSE members is
] On
Behalf Of Pinnacle
Sent: Sunday, July 25, 2010 9:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Another reason to hate PDSE's
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
- Original Message -
From: Mark Zelden mzel...@flash.net
Newsgroups: bit.listserv.ibm-main
Sent: Monday, July 26, 2010 10:44 AM
Subject: Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 10:13:54 -0400, Pinnacle pinnc...@rochester.rr.com
wrote:
Yep, you went slightly over
] On
Behalf Of Pinnacle
Sent: Sunday, July 25, 2010 9:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Another reason to hate PDSE's
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
On Mon, 2010-07-26 at 12:46 -0400, Pinnacle wrote:
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
On Mon, 26 Jul 2010 11:16:17 -0300, Clark 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.
Well, if you don't need
On Mon, 26 Jul 2010 12:32:00 -0400, Don Williams wrote:
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
On Mon, 26 Jul 2010 17:00:52 +, Bill Fairchild 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
And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks?
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!
On 26 Jul 2010 07:16:35 -0700, cfmpub...@ns.sympatico.ca (Clark
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
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.
PS: Can you spell DLL?
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
On Mon, 26 Jul 2010 17:00:52 +, Bill Fairchild bi...@mainstar.com wrote:
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
How can you have directory entries, and no members? I can see having a huge
directory and no members, but how can you have a directory entry that doesn't
point to a member?
--
Eric Bielefeld
Systems Programmer
Bill Fairchild bi...@mainstar.com wrote:
And isn't the maximum size of a PDS
Subject:Re: Another reason to hate PDSE's
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
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
On Sun, 25 Jul 2010 21:41:42 -0400, Pinnacle wrote:
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?
I can understand it. I don't know that I can forgive
, the z/VSE
library structure would be able to easily accommodate such a member.
John P. Baker
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Pinnacle
Sent: Sunday, July 25, 2010 9:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Another reason
52 matches
Mail list logo
