Determine how a file is being allocated

zOS_Uber_Geek · Posted: Fri Apr 13, 2007 5:43 pm

Hello Everyone,

I'm trying to determine how a file is being allocated. Here is my space allocation JCL:

SCFTRPT DD DSN=TSC.TEST.SCFTB113.RPT,
DISP=(NEW,CATLG,DELETE),
UNIT=SYSDA,
SPACE=(133,(900,300),RLSE),AVGREC=U,
RECFM=FB,LRECL=133

The report has 1,020 lines. When I look at the file information from P.3.4 in TSO/ISPF, I get the following info:

Data class . . . . . : DEFDSORG
Organization . . . : PS
Record format . . . : FBA
Record length . . . : 133
Block size . . . . : 27930
1st extent bytes . : 167580
Secondary bytes . . : 39900

It seems to me that the primary allocation should be 119700 (133 X 900), but the information is showing a primary allocation of 167580. Why does this information not seem to match my allocation?

expat · Posted: Fri Apr 13, 2007 5:53 pm

The primary extent can be broken down into up to five physical extents depending on volume fragmentation.

Also, you have the RLSE parameter coded, so the release of the unused space may account account for this. The data has used less space than you had anticipated, and the unused has been released.

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

Hi; assuming that you have 3390 disks I would guess that your primary space allocation requested was for 2.xx tracks and as the system does not like allocating parts of a track it rounded the allocation up to 3 tracks. I have not done the maths I just etimated so don't shot at me if I am wong

expat · Posted: Fri Apr 13, 2007 7:58 pm

Nevilh,

You have another point there - all allocations are converted to tracks or cylinders by the OS before the actual allocation takes place.

You can tell it's a Friday by my previous response. Derrrrrrrrr, it used MORE than expected rather than less. Been a real MF day here !!!!

enrico-sorichetti · Posted: Sat Apr 14, 2007 12:27 am

Hi !

the process by which dasd space is allocated is :
( with system determined blksize )

determine according the device that will be chosen the optimum blksize ( usually best approx to half track )
- in Your case 27930

determine how many blocks will be needed to satisfy Your request
- in Your case 4.something blocks

round them to the nearest track boundary
- in Your case 6 blocks

which result in
-3 full tracks

which at the end of the story will provide enough space for as many records which will fit in
5 full blocks of 27930 an additional smaller block and an eof record

in 3 tracks You will never fit exactly a 27930 * 6 file because additional space in the track is needed for the eof record

and according these computations
27930 * 6 is what You get as first extent allocation
regards
e.s