IEF344I PDB2W02E UTIL0052 CPYA0026 - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR
IGD17051I ALLOCATION FAILED FOR DATA SET
DBAWAR.WARDDATP.WARSEDSR.IC.W.G0005V00
, PRIMARY SPACE EXCEEDS 65535 TRKS
IEF272I PDB2W02E UTIL0052 - STEP WAS NOT EXECUTED.
So to know the number of tracks it allocated, i did the following calculations assuming for 3390 devices 56664 bytes per track
For the failed one,
PRI = 790191 * 4096 = 3236622336 / 56664 = 57119.55273 tracks
I did the same for the previous week,
PRI = 782210 * 4096 = 3203932160 / 56664 = 56542.64012 tracks
Since it is not even close to 65535 tracks limit and remebering this is DB2 IC, where only 48KB is usable in a track, i recalculated and got the following numbers
For the failed one,
PRI = 790191 * 4096 = 3236622336 / 49152 = 65849.25 tracks
I did the same for the previous week,
PRI = 782210 * 4096 = 3203932160 / 56664 = 65184.16667 tracks
I want to know first, is my method of calculation valid or not.
When i checked for the information, i got the below,
Code:
Data Set Name . . . . : HXSULL.T.T
General Data Current Allocation
Management class . . : MC02 Allocated tracks . : 65,353
Storage class . . . : SC02 Allocated extents . : 2
Volume serial . . . : SMS208
Device type . . . . : 3390
Data class . . . . . : **None** Current Utilization
Organization . . . : PS Used tracks . . . . : 0
Record format . . . : FB Used extents . . . : 0
Record length . . . : 100
Block size . . . . : 27900
1st extent tracks . : 12463
Secondary tracks . : 34
Data set name type : SMS Compressible : NO
Creation date . . . : 2010/06/07 Referenced date . . : 2010/06/07
Expiration date . . : ***None***
I am confused here a little bit, like for the above space parameter i should have got an error, but the jcl worked, but it
allocated only 65,353. Can i know reason for this ?
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Quote:
So to know the number of tracks it allocated, i did the following calculations assuming for 3390 devices 56664 bytes per track
For the failed one,
PRI = 790191 * 4096 = 3236622336 / 56664 = 57119.55273 tracks
I did the same for the previous week,
PRI = 782210 * 4096 = 3203932160 / 56664 = 56542.64012 tracks
These formulas are wrong. For example, for 4096 bytes per block, only 12 blocks fit on a track (49152 bytes). The actual blocks per track can be found in the 3390 reference card GX26-4877.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Quote:
I am confused here a little bit, like for the above space parameter i should have got an error, but the jcl worked, but it allocated only 65,353. Can i know reason for this ?
If you check the manual, the allowed value for space quantity is 0 to 16777215. Since 78000 is less than 16777215 there would not be an error generated. There is an absolute limit of 65,535 tracks per volume (at least through z/OS 1.9 I believe) so I think (but haven't found confirmation in the manual) that requests for space larger than this will be reduced to the maximum. I'm not sure why 65353 instead of 65535, though.
primary-qty
Syntax allows for values of 0-16777215. Actual allowances will vary depending on physical and other environmental variables.
Specifies one of the following:
For TRK, the number of tracks to be allocated.
For CYL, the number of cylinders to be allocated.
For a block length, the number of data blocks in the data set.
For a record length, the number of records in the new data set. Use the AVGREC parameter to specify that the primary quantity represents units, thousands, or millions of records.
BTW, wouldn't it be more proper to specify AVGREC with the recsize rather than without it since (I think) the allocation assumes it to be blocksize?
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Sorry about not giving the manual reference -- I try to do that but every now and then I forget. Thanks William Thompson for getting me straight.
For the table you extracted, the relevant value is the BLKSIZE, not the LRECL. So you get two blocks per track, not twelve. Furthermore, DB2 rows do not correspond directly to the LRECL of the physical file -- so your calculation is completely off. There is a way to get the actual record length from DB2, but it has been way too long since I used DB2 to tell you how to find that information.
The plus sign after the volume serial in your posted output means more than one volume was allocated -- 131070 blocks on disk pack SC7IJ0 (65535 tracks) and the rest on the second disk pack (unknown volume serial).
And following is the information of dataset on another volume,
Code:
Command - Enter "/" to select action Message Volume
Tracks % XT Device Dsorg Recfm Lrecl Blksz Created Referred
-------------------------------------------------------------------------------
DBAWAR.WARDDATP.WARSEDSR.IC.W.G0005V00 Info - S SC7IJ0+
65856 100 2 3390 PS FB 4096 24576 2010/06/06 2010/06/07
Command - Enter "/" to select action Message Volume
Tracks % XT Device Dsorg Recfm Lrecl Blksz Created Referred
-------------------------------------------------------------------------------
DBAWAR.WARDDATP.WARSEDSR.IC.W.G0005V00 SC5IJ1
321 100 1 3390 PS FB 4096 24576 2010/06/06 2010/06/06
For DB2, i think we can calculate like this,
Code:
SELECT NACTIVE FROM SYSIBM.SYSTABLESPACE WHERE NAME = 'WARSEDSR' ;
Result will be 793208
That is multiplied with 793208 * 4096 = 3248979968 / 49152 = 66101 Tracks
But, we use a database analyzer tool to the calculation and build the jcl.
The built jcl had the value higher than the limit, so my task right now would be to put a condition like, if the blklength greater than 786420 value, use 786420 itself.
I have read in an article somewhere, i don't remember where... they have said allocating using cylinder enhances performance, since we are using blklength. I don't know whether enhances performance or degrades it, any ideas on that.
Quote:
There is an absolute limit of 65,535 tracks per volume
And, i also like to know, is there any limit for cylinders and can you point me where i can find these limits.
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
sushanth bobby wrote:
I have read in an article somewhere, i don't remember where... they have said allocating using cylinder enhances performance, since we are using blklength. I don't know whether enhances performance or degrades it, any ideas on that.
Admittedly that was true with ye olde classic DASD, but whether or not this is so true with the modern array DASD I am not so sure.
Getting back to your original problem where the track allocation exceeds the maximum, for processing huge datasets I will use an allocation of (CYL,(273,273),RLSE) which means that if all 16 extents are used and have singe extent allocation, the number of tracks per volume will always be slightly under the maximum allowable for any one volume.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Note that this clearly displays that the data set is using 65,535 tracks on one disk pack and 321 tracks on a second disk pack for a total of 66,856 tracks:
Code:
Command - Enter "/" to select action Message Volume
Tracks % XT Device Dsorg Recfm Lrecl Blksz Created Referred
-------------------------------------------------------------------------------
DBAWAR.WARDDATP.WARSEDSR.IC.W.G0005V00 Info - S SC7IJ0+
65856 100 2 3390 PS FB 4096 24576 2010/06/06 2010/06/07
Command - Enter "/" to select action Message Volume
Tracks % XT Device Dsorg Recfm Lrecl Blksz Created Referred
-------------------------------------------------------------------------------
DBAWAR.WARDDATP.WARSEDSR.IC.W.G0005V00 SC5IJ1
321 100 1 3390 PS FB 4096 24576 2010/06/06 2010/06/06
Since a 3390 has 15 tracks per cylinder, if you divide 65,535 by 15 you get 4,369 cylinders per disk pack as the maximum.
You keep basing your calculations on the LRECL. I tell you again -- hopefully for the last time -- that it is WRONG to use LRECL in disk space calculations. If you persist in doing this, sooner or later you will run into a situation where your results are completely off.
Based on my research, the proper way to calculate the record length for a DB2 table is to take the maximum length of each column of the table and sum them. Add 1 for each column that is nullable. This value has absolutely nothing to do with the LRECL used by DB2 for the table, as far as I know.
Based on the questions you're asking and the confusion you're displaying, I strongly recommend you contact your site DB2 DBA and spend some time going over these concepts and your concerns with that person.
if all 16 extents are used and have singe extent allocation, the number of tracks per volume will always be slightly under the maximum allowable for any one volume.
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
If you are only allowed 65535 tracks on any given volume, 273 * 16 * 15 = 65520 tracks.
The reason for using primary and secondary extents the same is that on multi volume allocations it is only the secondary extent that is used on subsequent volumes.
single extent allocation - as we are all aware any space allocation, primary or secondary, may be satisfied by up to 5 physical extents. A single extent allocation is where the whole allocation request was met in one physical extent. i.e. there will be 16 extents on the volume all being 273 cylinders in size.
SELECT NACTIVE FROM SYSIBM.SYSTABLESPACE WHERE NAME = 'WARSEDSR' ;
Result will be 793208
That is multiplied with 793208 * 4096 = 3248979968 / 49152 = 66101 Tracks
I got the 4096 from DB2 Developer's Guide, since its the page size
Quote:
Calculating SYSCOPY Data Set Size
To create a valid image copy, the COPY utility requires that the SYSCOPY data set be allocated. The following formula calculates the proper size for this data set:
SYSCOPY = (number of formatted pages) x 4096
If the table space being copied uses 32K pages, multiply the result of the preceding calculation by 8. The total number of pages used by a table space can be retrieved from the VSAM LISTCAT command or from the DB2 Catalog as specified in the NACTIVEF column in SYSIBM.SYSTABLESPACE. When copying a single partition, use the NACTIVE column in SYSIBM.SYSTABSTATS to estimate the backup size.
Really sorry for not telling where i got that 4096(4K) from ?
The 65k Track limit can be exceeded simply by making the dataset Extended Format (or by using DSNTYPE=LARGE I think). Extended Format is achieved by assigning a Dataclas with that attribute set.