IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR
IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic Quick References
View previous topic :: View next topic  
Author Message
sushanth bobby

Senior Member


Joined: 29 Jul 2008
Posts: 1020
Location: India
PostPosted: Mon Jun 07, 2010 9:50 pm
 Reply with quote
Hi,

One of the step in our copy jobs gave JCL error, due to the following dataset parameters,
Code:
//CPYA0026  DD UNIT=SYSDA,SPACE=(4096,(790191,158038),RLSE),         
//        DSN=DBAWAR.WARDDATP.WARSEDSR.IC.W(+1),DISP=(,CATLG)         

error is
Code:
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. 

Previous week, the following worked,
Code:
//CPYA0026  DD UNIT=SYSDA,SPACE=(4096,(782210,156442),RLSE),         
//        DSN=DBAWAR.WARDDATP.WARSEDSR.IC.W(+1),DISP=(,CATLG)         

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.

And for just testing purposes, i ran the below
Code:
//TESTFIL  EXEC PGM=BZALLOC 
//TEST     DD  DSN=HXSULL.T.T,                           
//             DISP=(NEW,CATLG,DELETE),                 
//             UNIT=TEST,                               
//             SPACE=(TRK,(78000,40)),                   
//             DCB=(RECFM=FB,LRECL=100,BLKSIZE=0,BUFNO=2)


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 ?

Thank You,
Sushanth
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
PostPosted: Mon Jun 07, 2010 11:13 pm
 Reply with quote
The system allocates DASD space in whole tracks. The number of tracks required depends on how the records are blocked. The system uses one of the following as the block length to compute the number of tracks to allocate, in the order indicated:
The block size from the DCB parameter, if specified.
The system determined block size, if available.
A default value of 4096.
If the allocation is based upon the provided blocksize, a track will hold much less than 56664 bytes of data.
1 block per track is 56664.
2 blocks per track is 55800 (27900*2).
? blocks per track is ????? (4096*?).
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
PostPosted: Mon Jun 07, 2010 11:36 pm
 Reply with quote
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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
PostPosted: Mon Jun 07, 2010 11:50 pm
 Reply with quote
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.
Back to top
View user's profile Send private message
sushanth bobby

Senior Member


Joined: 29 Jul 2008
Posts: 1020
Location: India
PostPosted: Tue Jun 08, 2010 2:20 am
 Reply with quote
Hi Robert & William,

Following is the information on the failed dataset,
Code:
Data Set Name . . . . : DBAWAR.WARDDATP.WARSEDSR.IC.W.G0005V00           
                                                                         
General Data                           Current Allocation                 
 Management class . . : MCML2IMD        Allocated blocks  . : 131,712     
 Storage class  . . . : SCDB2           Allocated extents . : 2           
  Volume serial . . . : SC7IJ0 +                                         
  Device type . . . . : 3390                                             
 Data class . . . . . : **None**       Current Utilization               
  Organization  . . . : PS              Used blocks . . . . : 131,712     
  Record format . . . : FB              Used extents  . . . : 2           
  Record length . . . : 4096                                             
  Block size  . . . . : 24576                                           
  1st extent blocks . : 131070                                         
  Secondary blocks  . : 156442                                         
  Data set name type  :                 SMS Compressible  :   NO         
                                                                       
  Creation date . . . : 2010/06/06      Referenced date . . : 2010/06/07 
  Expiration date . . : ***None***                                       

And this DB2 Table contains about 5,530,810 rows
Record Length specified above is 4096

And as per the below table,
Code:
    ___________________ _________ __________________ __________________
   | Data Length Range | Percent | Maximum Track    | Maximum Cylinder |
   |                   | Space   | Capacity *       | Capacity *       |
   |  Min        Max   | Used *  | Records    Bytes | Records    Bytes |
   |___________________|_________|__________________|__________________|
   | 27 999    56 664  |  100.0  |     1     56 664 |     15   849 960 |
   | 18 453    27 998  |   98.8  |     2     55 996 |     30   839 940 |
   | 13 683    18 452  |   97.7  |     3     55 356 |     45   830 340 |
   | 10 797    13 682  |   96.6  |     4     54 728 |     60   820 920 |
   |  8 907    10 796  |   95.3  |     5     53 980 |     75   809 700 |
   |  7 549     8 906  |   94.3  |     6     53 436 |     90   801 540 |
   |  6 519     7 548  |   93.2  |     7     52 836 |    105   792 540 |
   |  5 727     6 518  |   92.0  |     8     52 144 |    120   782 160 |
   |  5 065     5 726  |   90.9  |     9     51 534 |    135   773 010 |
   |  4 567     5 064  |   89.4  |    10     50 640 |    150   759 600 |
   |  4 137     4 566  |   88.6  |    11     50 226 |    165   753 390 |
   |  3 769     4 136  |   87.6  |    12     49 632 |    180   744 480 |
   |  3 441     3 768  |   86.4  |    13     48 984 |    195   734 760 |
   |  3 175     3 440  |   85.0  |    14     48 160 |    210   722 400 |
   |  2 943     3 174  |   84.0  |    15     47 610 |    225   714 150 |
   |  2 711     2 942  |   83.1  |    16     47 072 |    240   706 080 |
   |  2 547     2 710  |   81.3  |    17     46 070 |    255   691 050 |
   |  2 377     2 546  |   80.9  |    18     45 828 |    270   687 420 |
   |  2 213     2 376  |   79.7  |    19     45 144 |    285   677 160 |
   |  2 083     2 212  |   78.1  |    20     44 240 |    300   663 600 |
   |  1 947     2 082  |   77.2  |    21     43 722 |    315   655 830 |
   |  1 851     1 946  |   75.6  |    22     42 812 |    330   642 180 |
   |  1 749     1 850  |   75.1  |    23     42 550 |    345   638 250 |
   |  1 647     1 748  |   74.0  |    24     41 952 |    360   629 280 |
   |  1 551     1 646  |   72.6  |    25     41 150 |    375   617 250 |
   |  1 483     1 550  |   71.1  |    26     40 300 |    390   604 500 |
   |  1 387     1 482  |   70.6  |    27     40 014 |    405   600 210 |
   |  1 319     1 386  |   68.5  |    28     38 808 |    420   582 120 |
   |  1 251     1 318  |   67.5  |    29     38 222 |    435   573 330 |
   |  1 183     1 250  |   66.2  |    30     37 500 |    450   562 500 |
   |  1 155     1 182  |   64.7  |    31     36 642 |    465   549 630 |
   |  1 087     1 154  |   65.2  |    32     36 928 |    480   553 920 |
   |  1 019     1 086  |   63.2  |    33     35 838 |    495   537 570 |
   |    985     1 018  |   61.1  |    34     34 612 |    510   519 180 |
   |    951       984  |   60.8  |    35     34 440 |    525   516 600 |
   |    889       950  |   60.4  |    36     34 200 |    540   513 000 |
   |    855       888  |   58.0  |    37     32 856 |    555   492 840 |
   |    821       854  |   57.3  |    38     32 452 |    570   486 780 |
   |    787       820  |   56.4  |    39     31 980 |    585   479 700 |
   |    753       786  |   55.5  |    40     31 440 |    600   471 600 |
   |    719       752  |   54.4  |    41     30 832 |    615   462 480 |
   |    691       718  |   53.2  |    42     30 156 |    630   452 340 |
   |    657       690  |   52.4  |    43     29 670 |    645   445 050 |
   |    623       656  |   50.9  |    44     28 864 |    660   432 960 |
   |    589       622  |   49.4  |    45     27 990 |    675   419 850 |
   |    555       588  |   47.7  |    46     27 048 |    690   405 720 |
   |    521       554  |   46.9  |    48     26 592 |    720   398 880 |
   |    487       520  |   45.0  |    49     25 480 |    735   382 200 |
   |    459       486  |   42.9  |    50     24 300 |    750   364 500 |
   |    425       458  |   42.0  |    52     23 816 |    780   357 240 |
   |    391       424  |   40.4  |    54     22 896 |    810   343 440 |
   |    357       390  |   37.9  |    55     21 450 |    825   321 750 |
   |    323       356  |   35.8  |    57     20 292 |    855   304 380 |
   |    289       322  |   33.5  |    59     18 998 |    885   284 970 |
   |    255       288  |   31.0  |    61     17 568 |    915   263 520 |
   |    227       254  |   28.7  |    64     16 256 |    960   243 840 |
   |    193       226  |   26.3  |    66     14 916 |    990   223 740 |
   |    159       192  |   23.4  |    69     13 248 |   1035   198 720 |
   |    125       158  |   20.1  |    72     11 376 |   1080   170 640 |
   |     91       124  |   16.4  |    75      9 300 |   1125   139 500 |
   |     57        90  |   12.4  |    78      7 020 |   1170   105 300 |
   |     23        56  |    8.1  |    82      4 592 |   1230    68 880 |
   |      1        22  |    3.3  |    86      1 892 |   1290    28 380 |
   |___________________|_________|__________________|__________________|

the record length 4096 comes between 3 769 & 4 136

And the block size is 24576, so 12 rows can fit in a track.

So, 5,530,810 / 12 = 460901 Tracks required.

Is this calculation valid.

And robert, Can you tell me from which manual this limit 16777215 was referred.


Thank You,
Sushanth
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
PostPosted: Tue Jun 08, 2010 2:39 am
 Reply with quote
z/OS V1R11.0 MVS JCL Reference wrote:
Code:
   SPACE= ({TRK,}(primary-qty[,second-qty][,directory])[,RLSE][,CONTIG][,ROUND])
          ({CYL,}            [,          ]             [,    ][,MXIG  ]         
          ({blklgth,}                                         [,ALX   ]         
          ({reclgth,}                                         [,      ]         

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?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
PostPosted: Tue Jun 08, 2010 4:10 am
 Reply with quote
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).
Back to top
View user's profile Send private message
sushanth bobby

Senior Member


Joined: 29 Jul 2008
Posts: 1020
Location: India
PostPosted: Tue Jun 08, 2010 7:06 pm
 Reply with quote
Hi William Thompson & Robert,

I checked the attributes of other IC's they too have the same block size and record length,
Code:
Record length . . . : 4096   
Block size  . . . . : 24576 

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.

Thank You,
Sushanth
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
PostPosted: Tue Jun 08, 2010 7:27 pm
 Reply with quote
sushanth bobby wrote:
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.

On System Assignment of Space, the z/OS V1R11.0 MVS JCL Reference wrote:
Syntax allows for values of 0-16777215. Actual allowances will vary depending on physical and other environmental variables.
One of the "environmental variables" would be how many tracks in a cylinder, since the track count is a limit not (normally) exceeded.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
PostPosted: Tue Jun 08, 2010 7:41 pm
 Reply with quote
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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
PostPosted: Tue Jun 08, 2010 7:55 pm
 Reply with quote
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.
Back to top
View user's profile Send private message
sushanth bobby

Senior Member


Joined: 29 Jul 2008
Posts: 1020
Location: India
PostPosted: Tue Jun 08, 2010 7:59 pm
 Reply with quote
Hi Expat,

Can you please elaborate, your statement
Quote:
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.

Sushanth
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
PostPosted: Tue Jun 08, 2010 8:06 pm
 Reply with quote
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.
Back to top
View user's profile Send private message
sushanth bobby

Senior Member


Joined: 29 Jul 2008
Posts: 1020
Location: India
PostPosted: Tue Jun 08, 2010 8:16 pm
 Reply with quote
Hi Robert,

Quote:

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


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 ?

Sushanth
Back to top
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 599
Location: London
PostPosted: Wed Jun 09, 2010 1:34 pm
 Reply with quote
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.
Back to top
View user's profile Send private message
sushanth bobby

Senior Member


Joined: 29 Jul 2008
Posts: 1020
Location: India
PostPosted: Wed Jun 09, 2010 8:16 pm
 Reply with quote
Thank You for that Pete.


Sushanth
Back to top
View user's profile Send private message
View previous topic : : View next topic  
Post new topic   Reply to topic All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 

Similar Topics
Topic Forum Replies
No new posts Methodic way to address cryptic alloc... ABENDS & Debugging 2
No new posts CICS UCTRAN=NO not working, need syst... CICS 3
No new posts U0016 error in JCL JCL & VSAM 4
No new posts Any way to prevent dynamic allocation? DFSORT/ICETOOL 6
No new posts Alternate key data extracttion COBOL Programming 13
Search our Forums:


Back to Top
IBMMainframes.com is not an official and/or affiliated with IBM® in anyway
Board Rules | FAQ | Downloads | Wiki | SiteMap | Contact Us