DASD Space Allocation
William F Besnier
2.988 million records, and allocate the file size at (cyl,(2500,100)) with a
unit parameter of sysda,10; the file is received across 2 volumes in 20
extents totaling 4,331 cylinders. I am not concerned about the extents, what
I don't understand is the space allocation.
TIA
----------------------------------------------------------------------
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
Tom Marchant
>Situation came up on a client site where they received a very large file,
>2.988 million records, and allocate the file size at (cyl,(2500,100)) with a
>unit parameter of sysda,10; the file is received across 2 volumes in 20
>extents totaling 4,331 cylinders. I am not concerned about the extents, what
>I don't understand is the space allocation.
If SMS is configured with a default volume specified as 3380 and the space
allocation is satisfied on a 3390, the amount allocated will be adjusted to
account for the larger cylinders on a 3390.
--
Tom Marchant
Schwarz, Barry A
That averages to ~46 records per track. Is there some reason you think
this is unreasonable?
What is the percentage used of the 4,331 cylinders? What is the device
type the dataset is on?
If the initial allocation provided all 2500 cylinders in one extent, the
remaining 1831 cylinders does require 19 extents so it at least that
looks consistent.
-----Original Message-----
From: William F Besnier [mailto:bbes...@GMAIL.COM]
Sent: Thursday, August 14, 2008 2:23 PM
To: IBM-...@BAMA.UA.EDU
Subject: DASD Space Allocation
Situation came up on a client site where they received a very large
file,
2.988 million records, and allocate the file size at (cyl,(2500,100))
with a unit parameter of sysda,10; the file is received across 2 volumes
in 20 extents totaling 4,331 cylinders. I am not concerned about the
extents, what I don't understand is the space allocation.
----------------------------------------------------------------------
William F Besnier
the allocation is satisfied on a 3390, a larger volume, how would the space
allocation be increased for the larger 3390.
William F Besnier
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On Behalf
Of Schwarz, Barry A
Sent: Thursday, August 14, 2008 6:44 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: DASD Space Allocation
What is the LRECL, RECFM, and BLKSIZE? 4331 cylinders is 64,965 tracks.
That averages to ~46 records per track. Is there some reason you think
this is unreasonable?
Don't think it's unreasonable, don't know what it has to do what is
specified in JCL and what was allocated.
What is the percentage used of the 4,331 cylinders? What is the device
type the dataset is on?
The dataset was allocated across 2 3390-9 volumes; 4 extents on the first
volume with 100% utilization.
If the initial allocation provided all 2500 cylinders in one extent, the
remaining 1831 cylinders does require 19 extents so it at least that
looks consistent.
The initial allocation was in 4 extents. I thought for a PS file, the F1
DSCB gave 3 extent descriptors and the F3 DSCB gave another 13 extent
descriptor for a total of 16 extents per volume. Please explain how 1831
cylinders requires 19 extents and that is consistent.
Ted MacNEIL
Maybe there is fragmentation on the secondaries?
When your allocation goes to secondary volumes, only the secondary extent is used.
The primary is NOT remembered.
The primary could be broken up depending on the fragmentation of the volume.
16 extents is on a per volume basis.
So, in theory, your dataset could be in 16 extents times 59 DASD volumes.
I don't see the problem.
-
Too busy driving to stop for gas!
Kenneth J. Kripke
>2.988 million records, and allocate the file size at (cyl,(2500,100)) with a
>unit parameter of sysda,10; the file is received across 2 volumes in 20
>extents totaling 4,331 cylinders. I am not concerned about the extents, what
>I don't understand is the space allocation.
Explanation:
Reference: 1R9.0 Using Data Sets:
1.3.4.2 Multivolume Non-VSAM Data Sets
When a multivolume non-VSAM, non-extended-format data set extends to the next volume,
the initial space allocated on that volume is the secondary amount.
In your instance, it looks like you got the first 16 extents on the first volume, and,
the remainder of extents were allocated in 100 cylinder extent increments.
Ken Kripke
kkr...@mindspring.com
William F Besnier
extents used; it is the space allocated, the JCL space parameter is asking
for 2500,100 cylinders of space for a total 4000 cylinders. What seems to
have happened is the first volume was allocated the primary + 3 extents for
2800 cylinders; the second volume was allocated 16 extents of 100 cylinders
for 1600 cylinders - rlse, the total being 4331 cylinders being allocated
when only 4000 was requested. The file/volume are non-SMS and my question is
WHY ISN'T THE JCL REQUEST BEING HONOURED?
bILL
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On Behalf
Of Ron Hawkins
Sent: Friday, August 15, 2008 12:50 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: DASD Space Allocation
William,
Assuming you do not have any software with Primary or Secondary extent
reduction, or secondary extent increase rules. I'm talking pure dataset
allocation without any allocation recovery.
So, if the Primary was allocated in four extents, that means you can have an
additional 12 extents on the 1st volume. That's 2500 CYLs + 1200 CYLs for a
total 3700 CYLs. That means the second volume would have 7 secondary
extents. That is 6 of 100 CYLS and one of 31 CYLS (which is what happens
with RLSE in the JCL or MGMTCLAS).
That's one extreme. You could have 3 secondary extents on the 1st volume
(2800 CYLS) and 16 secondary extents on the 2nd volume (1531 CYLS), or some
combination in between.
I guess I'm not following what the problem is.
Ron
>
> The initial allocation was in 4 extents. I thought for a PS file, the
> F1
> DSCB gave 3 extent descriptors and the F3 DSCB gave another 13 extent
> descriptor for a total of 16 extents per volume. Please explain how
> 1831
> cylinders requires 19 extents and that is consistent.
>
----------------------------------------------------------------------
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of William F Besnier
>
> I'm not explaining my concerns correctly. My concern is not
> the number of extents used; it is the space allocated, the
> JCL space parameter is asking for 2500,100 cylinders of space
> for a total 4000 cylinders. What seems to have happened is
> the first volume was allocated the primary + 3 extents for
> 2800 cylinders; the second volume was allocated 16 extents of
> 100 cylinders for 1600 cylinders - rlse, the total being 4331
> cylinders being allocated when only 4000 was requested. The
> file/volume are non-SMS and my question is WHY ISN'T THE JCL
> REQUEST BEING HONOURED?
It is. Your JCL (apparently) specified to use (at least one) additional
volume(s), so when space was no longer available on the first volume for
a secondary extent, you then got "allowed to allocate" another 16
extents of 100 cyls each on the second volume, for a total of 1600 cyls
ON THAT VOLUME. Thus, given your observation that you got one primary
and three secondary extents on the first volume, for a total of 2800
cyls, and the dataset then extended to a second volume, you got
"entitled" to an additional 1600 cyls on the second volume. Had you
specified the maximum of 59 volumes, you would have been "entitled" to
allocate a maximum of 1600*58 + whatever space you got on the first
volume (2800, based on your posted observation)
If you wanted to limit the available space to exactly 4000 cyls, you
should have specified a primary of 4000 cyls with no secondary, on a
volume that had 4000 cyls available.
-jc-
Walt Farrell
wrote:
>I'm not explaining my concerns correctly. My concern is not the number of
>extents used; it is the space allocated, the JCL space parameter is asking
>for 2500,100 cylinders of space for a total 4000 cylinders. What seems to
>have happened is the first volume was allocated the primary + 3 extents for
>2800 cylinders; the second volume was allocated 16 extents of 100 cylinders
>for 1600 cylinders - rlse, the total being 4331 cylinders being allocated
>when only 4000 was requested. The file/volume are non-SMS and my question is
>WHY ISN'T THE JCL REQUEST BEING HONOURED?
Perhaps I don't understand something here, but you seem to be making an
erroneous assumption that SPACE= (CYL,(2500,100)) requests a " total of 4000
cylinders".
It requests a primary space allocation of 2500 cylinders, and secondary
allocations of 100 cylinders. True, if you consider only a single volume,
and only 16 extents, that gives you a max of 4000 cylinders.
But you don't have a single-volume case, if I've read this thread correctly.
You have a multi-volume case, and there each volume can have up to 16
extents, where each volume after the first uses an allocation unit of 100
cylinders per extent. So, in theory, you could have 4000 cylinders on the
first volume, 1600 cylinders on a second volume, 1600 cylinders on a third
volume, etc. for as many volumes as you've allowed the data set to expand onto.
--
Walt
David Logan
how do you know only 4000 was requested?
Neal Scheffler
That would be a max of 4000 cyls on the primary volume and a max of 1600
cyls on the secondary volumes.
Neal
William F Besnier
One of the good thinks about this field is you learn every day and when you
stop learning, it's time to get out.
Again thanks,
Bill
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On Behalf
Of Chase, John
Sent: Friday, August 15, 2008 9:25 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: DASD Space Allocation
David Logan
extents, giving him 4400 cylinders instead of 4000 cylinders.
I'm reading this as:
Expected:
2500 primary+3(x100) secondary=2800, then 12(x100) secondary=4000
Actual:
2500 primary+3(x100) secondary=2800, then 16(x100) secondary=4400
At least that's the way I read it (so far.) That's why I'm wondering why the
OP seems to think that it was supposed to stop at 4000.
Am I misunderstanding the question perhaps?
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On Behalf
Of Walt Farrell
Sent: Friday, August 15, 2008 07:32
To: IBM-...@BAMA.UA.EDU
Subject: Re: DASD Space Allocation
Ted MacNEIL
for 2500,100 cylinders of space for a total 4000 cylinders.
>What seems to have happened is the first volume was allocated the primary + 3 extents for
2800 cylinders; the second volume was allocated 16 extents of 100 cylinders for 1600 cylinders - rlse, the total being 4331 cylinders being allocated
when only 4000 was requested.
>The file/volume are non-SMS and my question is
>WHY ISN'T THE JCL REQUEST BEING HONOURED?
Once you've asked for more than one volume, all bets are off.
Since it couldn't find the 4000 on volume1, it went looking elsewhere using the secondary allocation.
What would you have preferred?
The job abend at 4000 cyls?
You can only get that if you specify a primary with a single volume, that has 4000 cyls available.
Me, I'd rather the job complete successfully.
-
Too busy driving to stop for gas!
----------------------------------------------------------------------
Schwarz, Barry A
and consumed 2500 cylinders. The remaining 3 extents on the first
volume are secondary extents and consume 100 cylinders each.
After the initial allocation was used up, the dataset continued to grow,
by a total of 1831 cylinders. It did not obtain all this space at once.
It grew by one secondary extent at a time, 100 cylinders apiece. The
first 18 secondary extents provided 1800 cylinders. The last 31
cylinders were in the 19th extent and the excess space (69 cylinders)
was apparently released. (How many 100 Euro notes does it take to pay
for an airplane ticket costing 1832 Euros?) One initial extent of 2500
+ 18 secondary extents of 100 + 1 secondary extent of 31 (19 secondary
extents total) yields 4331 cylinders in 20 extents.
----------------------------------------------------------------------
Schwarz, Barry A
cylinders on the first volume and up to 1600 cylinders on each of up to
9 additional volumes.
-----Original Message-----
From: William F Besnier [mailto:snip]
Sent: Friday, August 15, 2008 6:08 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: DASD Space Allocation
I'm not explaining my concerns correctly. My concern is not the number
of extents used; it is the space allocated, the JCL space parameter is
asking for 2500,100 cylinders of space for a total 4000 cylinders. What
seems to have happened is the first volume was allocated the primary + 3
extents for 2800 cylinders; the second volume was allocated 16 extents
of 100 cylinders for 1600 cylinders - rlse, the total being 4331
cylinders being allocated when only 4000 was requested. The file/volume
are non-SMS and my question is WHY ISN'T THE JCL REQUEST BEING HONOURED?
----------------------------------------------------------------------
Patrick O'Keefe
<barry.a...@BOEING.COM> wrote:
>You specified (SYSDA,10) in your allocation. This means up to 4000
>cylinders on the first volume and up to 1600 cylinders on each of up to
>9 additional volumes.
>...
Well, William shouldn't feel alone in this. I've been mucking
around with MVS since about 1980 (where "mucking around"
means doing various systems programming work) and never
knew that the 16 extent limit was per volume. Admittedly, I've
never had to specify a multi-volume allocation for a dataset
(although SMS has probably done it for me); system programming
(especially communication software related system programming )
doesn't usually require massively large datasets.
Maybe everybody is supposed to know how DASD allocation works,
but some of us don't.
Pat O'Keefe
Thompson, Steve
Sent: Friday, August 15, 2008 3:09 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: DASD Space Allocation
<SNIP>
Well, William shouldn't feel alone in this. I've been mucking around
with MVS since about 1980 (where "mucking around"
means doing various systems programming work) and never knew that the 16
extent limit was per volume.
<SNIP>
I have been looking at Using Data Sets (a DFP document) from various
releases going back to OS/390 2.10 and I can't find something.
Didn't the allocation scheme allow 3/5 (whatever the DSCB1 allows)
extents to meet the *PRIMARY* and then go to secondaries (up to the 16
extent limit) *PER VOLUME* for NON-VSAM?
Reading this thread and looking at the aforementioned manual for z/OS
1.7, I was surprised to read that on second and subsequent volumes,
allocation is based on SECONDARY amounts.
And like Patrick was saying, I've also been doing some of this stuff
since the mid-'70s (pre MVS/SE). It is too bad that I discarded almost
all my old MVS manuals (I really need 'em these days working with Herc
and MVS 3.8J).
Regards,
Steve Thompson
-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --
Ted MacNEIL
Not only that, but if you do a DISP=MOD on an existing dataset, it uses the SECONDARY.
The PRIMARY is not remembered anywhere; the SECONDARY is always.
I mean no disrespect, but I've known this since 1981, and I'm ssurprised by how many don't!
-
Too busy driving to stop for gas!
----------------------------------------------------------------------
Ralph Kaden
3380 and
>> the allocation is satisfied on a 3390, a larger volume, how would the
space
>> allocation be increased for the larger 3390.
Found the following info in DFSMSdfp Storage Administration Reference
(SC26-4920-01) in Chapter 3 (Creating the Base Configuration), Topic 3.2
(Defining the Base Configuration), subtopic 3.2.3 (Specifying the
Default Device Geometry):
When allocating space for a new data set on DASD, SMS converts
all space requests in tracks (TRK) or cylinders (CYL) into
requests for space in KB or MB. If a generic device type such
as the 3380 is specified, SMS uses the device geometry for
that generic device to convert tracks or cylinders into KB or
MB. If an esoteric device type such as SYSDA or no UNIT is
specified, SMS uses the default device geometry to convert
tracks and cylinders into KB or MB. If the users in your
installations specify space in tracks or cylinder units, and
they specify an esoteric UNIT or no UNIT you must specify a
default device geometry prior to converting these allocations
to system-managed data sets.
.
After SMS converts space requests to KB or MB, the space
values are passed to the ACS routines. The values are later
used to determine the number of tracks or cylinders to
allocate for the data set. The default device geometry does
not apply to objects or data sets allocated on tape.
.
There is only one Default Device Geometry for the entire SMS
complex. Default Device Geometry is an installations'
definition of how much space is represented by a TRK or a CYL
when an esoteric unit or no unit is specified.
.
The device geometry for a 3380 is 47476 bytes/track, 15
tracks/cylinder.
The device geometry for a 3390 is 56664 bytes/track, 15
tracks/cylinder.
.
It is up to each installation to decide what values to use.
From MVS Storage Management Library: Managing Data Sets (SC26-4408):
Using Default Device Geometry:
In an SMS environment, you use default device geometry to convert
track and cylinder allocation requests to bytes. This can be used for
both SMS- and non-SMS-managed data sets. Using default device geometry
isolates users from actual physical devices; the amount of allocated
space will be consistent, regardless of which device is used.
If you specify a default device geometry, it will be used for a new
data set allocation as follows:
- When the data set is SMS-managed and a generic UNIT has not
been explicitly specified.
- When an esoteric UNIT name is specified for a non-SMS-managed
data set.
- When no UNIT name is specified for a non-SMS-managed data set,
and the default unit is esoteric. If the default unit is
generic (e.g., 3390), then the device geometry of this unit is
used for space calculations.
Ralph Kaden
z/OS (MVS) Level 2 Support - Allocation and Scheduler
(Converter/Interpreter, Initiator/Terminator, ENF, SJF, SMF, SSI, SWA Mgr)
T/ L: 8/295-4096 External: 845-435-4096
VM: S390VM.v$i01029 MVS: PLPSC.v$i316
External email: vi0...@us.ibm.com
Internal email: Ralph Kaden/Poughkeepsie/Contr/IBM@IBMUS
William F Besnier <bbes...@GMAIL.COM>
Sent by: IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU>
08/14/2008 10:07 PM
Please respond to
IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU>
L D Owen
is based on SECONDARY amounts.
Just to confuse everything, VSAM rules are just the opposite. For VSAM
datasets, the Primary is used on each subsequent volume for the initial extent
(s) on that volume, and then Secondary for the remaining extents.
So:
Non-VSAM: Volume 1 (Primary, then Secondary), Volumes 2-n (Secondary)
16 Extents per volume, Max 59 volumes
VSAM: Volume 1 (Primary, then Seconary), Volumes 2-n (Primary, then
Secondary)
Watch me be wrong about this one (123 Extents Maximum), no limit
per volume
If I'm wrong about the VSAM extents, please correct me.
...L
Ted MacNEIL
>Watch me be wrong about this one (123 Extents Maximum), no limit per volume
Pre z/OS 1.7 it was 123 extents on the first volume; 255 in total.
In 1.7, the maximum extents were changed.
I do not recall what the new maximum is.
-
Too busy driving to stop for gas!
----------------------------------------------------------------------
Traylor, Terry
the max vols limit. Total max extents vary depending on whether SMS
stripping and/or extended addressability which would put the max at 4080
extents. If Extent Constraint relief is used, then the max is 7257.
Terry Traylor
charlesSCHWAB
TIS Mainframe Storage Management
Remedy Queue: tis-hs-mstg
(602) 977-5154
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On
Behalf Of L D Owen
Sent: Monday, August 18, 2008 4:33 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: DASD Space Allocation
Ted MacNEIL
Only as of z/OS 1.7.
Prior to that the max was 255.
-
Too busy driving to stop for gas!
----------------------------------------------------------------------
, IBM Mainframe Discussion List
In a message dated 8/18/2008 7:24:37 P.M. Central Daylight Time,
>Total max extents vary depending on whether SMS
stripping and/or extended addressability which would put the max at 4080
Then there is the relatively new feature called Extent Consolidation. If a
new extent is needed, the system finds an available extent according to all
the previously discussed limits (per volume, max number of voumes, etc.). If
this new extent begins exactly at the next track after the end of an already
allocated extent, then the new extent is consolidated with the one already
allocated. This does not mean you end up with more than 4080 (or 7257) total
extents, but it does mean that you may take a trip through data set extend
many more times than you end up with distinct extents to show for the trips.
Bill Fairchild
Rocket Software
**************It's only a deal if it's where you want to go. Find your travel
deal here.
(http://information.travel.aol.com/deals?ncid=aoltrv00050000000047)
Ralph Kaden
allocates the Primary request on each volume.
Ralph Kaden
z/OS (MVS) Level 2 Support - Allocation and Scheduler
(Converter/Interpreter, Initiator/Terminator, ENF, SJF, SMF, SSI, SWA Mgr)
T/ L: 8/295-4096 External: 845-435-4096
VM: S390VM.v$i01029 MVS: PLPSC.v$i316
External email: vi0...@us.ibm.com
Internal email: Ralph Kaden/Poughkeepsie/Contr/IBM@IBMUS
L D Owen <ldowe...@YAHOO.COM>
Sent by: IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU>
08/18/2008 07:32 PM
Please respond to
IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU>
Subject
Re: DASD Space Allocation