mainframejcl

How to calculate space for number of records

I am trying to calculate space required by a dataset using below formula, but I am getting wrong somewhere when I cross check it with the existing dataset in the system. Please help me

1st Dataset: Record format . . . : VB
Record length . . . : 445
Block size . . . . : 32760 Number of records....: 51560

Using below formula to calculate
optimal block length (OBL) = 32760/record length = 32760/449 = 73
As there are two blocks on the track, hence (TOBL) = 2 * OBL = 73*2 = 146

Find number of physical records (PR) = Number of records/TOBL = 51560/146 = 354

Number of tracks = PR/2 = 354/2 = 177

But I can below in the dataset information

 Current Allocation            
  Allocated tracks  . : 100    
  Allocated extents . : 1      
                               
 Current Utilization           
  Used tracks . . . . : 100    
  Used extents  . . . : 1

2nd Dataset : Record format . . . : VB
Record length . . . : 445
Block size . . . . : 27998
Number of Records....: 127,252

Using below formula to calculate
optimal block length (OBL) = 27998/record length = 27998/449 = 63
As there are two blocks on the track, hence (TOBL) = 2 * OBL = 63*2 = 126

Find number of physical records (PR) = Number of records/TOBL = 127252/126 = 1010

Number of tracks = PR/2 = 1010/2 = 505

Number of Cylinders = 505/15 = 34

But I can below in the dataset information

 Current Allocation         
  Allocated cylinders : 69  
  Allocated extents . : 1   
                            
 Current Utilization        
  Used cylinders  . . : 69  
  Used extents  . . . : 1
Solution

  • A few observations on your approach.

    First, since your dealing with records that are variable length it would be helpful to know the "average" record length as that would help to formulate a more accurate prediction of storage. Your approach assumes a worst case scenario of all records being at maximum which is fine for planning purposes but in reality you'll likely see the actual allocation would be lower if the average of the record lengths is lower than the maximum.

    The approach you are taking is reasonable but consider that you can inform z/OS of the space requirements in blocks, records, DASD geometry or let DFSMS perform the calculation on your behalf. Refer to this article to get some additional information on options.

    Back to your calculations:

    You Optimum Block Length (OBL) is really a records per block (RPB) number. Block size divided maximum record length yields the number of records at full length that can be stored in the block. If your average record length is less then you can store more records per block.

    The assumption of two blocks per track may be true for your situation but it depends on the actual device type that will be used for the underlying allocation. Here is a link to some of the geometries for supported DASD devices and their geometries.

    enter image description here

    Your assumption of two blocks per track depends on the device is not correct for 3390's as you would need 64k for two blocks on a track but as you can see the 3390's max out at 56k so you would only get one block per track on the device.

    Also, it looks like you did factor in the RDW by adding 4 bytes but someone looking at the question might be confused if they are not familiar with V records on z/OS.In the case of your calculation that would be 61 records per block at 27998 (which is the "optimal block length" so two blocks can fit comfortable on a track).

    I'll use the following values:

    Example 1:

  Total Records = 51,560
  BlockSize = 32,760
  BlocksPerTrack = 1 (from device table)
  RecordsPerBlock: 32,760 / 449 = 72.96 (72)
  Total Blocks = 51,560 / 72 = 716.11 (717)
  Total Tracks = 717 * 1 = 717
  Cylinders = 717 / 15 = 47.8 (48)

Example 2:

  Total Records = 127,252
  BlockSize = 27,998
  BlocksPerTrack = 2 (from device table)
  RecordsPerBlock: 27,998 / 449 = 62.35 (62)
  Total Blocks = 127,252 / 62 = 2052.45 (2,053)
  Total Tracks = 2,053 / 2 = 1,026.5 (1,027)
  Cylinders = 1027 / 15 = 68.5 (69)

    Now, as to the actual allocation. It depends on how you allocated the space, the size of the records. Assuming it was in JCL you could use the RLSE subparameter of the SPACE= to release space when the is created and closed. This should release unused resources.

    Given that the records are Variable the estimates are worst case and you would need to know more about the average record lengths to understand the actual allocation in terms of actual space used.

    Final thought, all of the work you're doing can be overridden by your storage administrator through ACS routines. I believe that most people today would specify a BLKSIZE=0 and let DFSMS do all of the hard work because that component has more information about where a file will go, what the underlying devices are and the most efficient way of doing the allocation. The days of disk geometry and allocation are more of a campfire story unless your environment has not been administered to do these things for you.