Paul,
If you are going to use MB notation for space then you need to use the
AVGREC parameter. What you have requested in your JCL is the space to
allocate 7200 blocks of 787 bytes, not 5666400 bytes. The allocation of 185
tracks meets that requirement because the request for number of blocks makes
allowance for the block gaps.
Tracks of 56664 are the minimum allocation unit on MVS, just like some
multiple of 512 bytes is the minimum unit for File Systems and raw devices.
The characteristics of your file will define the space allocated, and the
space used, but it will always end up a multiple of the minimum allocation
unit. That may be 1KB for NTFS, or it may be 16KB for an Oracle table space.
Therefore it is no surprise that a text file on NTFS with a single byte -
the character "A" - uses 1KB of space, and the minimum space you will use on
MVS for the same file 56664 bytes.
AVGREC uses some very simple rules to decide the blksize that is used to
calculate the number of tracks:
1. The block size from the DCB parameter, if specified.
2. The system determined block size, if available.
3. A default value of 4096.
The JCL below confirms your BLKSIZE technique, and the last file uses MB
allocation in its purest form in MVS. The others provide DADSM with
additional information to calculate the number of tracks required for the
file in the same way as your example.
//ALLOC EXEC PGM=IEFBR14
//BLKSIZE DD DSNAME=&SYSUID..TEST.SIZE.BLKSIZE,
// UNIT=3390,DISP=(NEW,CATLG,CATLG),
// SPACE=(787,7200)
//AVGREC1 DD DSNAME=&SYSUID..TEST.SIZE.AVGRECU.BLK787,
// UNIT=3390,DISP=(NEW,CATLG,CATLG),
// RECFM=FB,LRECL=787,DSORG=PS,BLKSIZE=787,
// SPACE=(787,7200),AVGREC=U
//AVGREC2 DD DSNAME=&SYSUID..TEST.SIZE.AVGRECU.BLKSDB,
// UNIT=3390,DISP=(NEW,CATLG,CATLG),
// RECFM=FB,LRECL=80,DSORG=PS,
// SPACE=(787,7200),AVGREC=U
//AVGREC3 DD DSNAME=&SYSUID..TEST.SIZE.AVGRECU.BLKDFLT,
// UNIT=3390,DISP=(NEW,CATLG,CATLG),
// SPACE=(787,7200),AVGREC=U
//AVGREC4 DD DSNAME=&SYSUID..TEST.SIZE.AVGRECU.BYTES,
// UNIT=3390,DISP=(NEW,CATLG,CATLG),
// SPACE=(1,5666400),AVGREC=U
And the results are exactly what you would expect. It's actually that
simple.
Command - Enter "/" to select action Tracks %Used
XT
----------------------------------------------------------------------------
--
HAWKINS.TEST.SIZE.AVGRECU.BLKDFLT 116 ?
1
HAWKINS.TEST.SIZE.AVGRECU.BLK787 185 0
1
HAWKINS.TEST.SIZE.AVGRECU.BLKSDB 102 0
1
HAWKINS.TEST.SIZE.AVGRECU.BYTES 116 ?
1
HAWKINS.TEST.SIZE.BLKSIZE 185 ?
1
So, to tie this back to the original question, how would PARIN calculate the
size of his Dataset in MB or GB. Well the answer remains the same - 297,141
* 56664 rounded to MB or GB.
If you wanted to allocate this file in MB units you may use:
// RECFM=FB,LRECL=1526,BLKSIZE=7630,DSORG=PS,
// SPACE=(1,16058),AVGREC=M,DSNTYPE=LARGE
However, knowing there is space allocated for about 9,000,000 records you
may also use:
// RECFM=FB,LRECL=1526,DSORG=PS,BLKSIZE=7630,
// SPACE=(1526,9),AVGREC=M,DSNTYPE=LARGE
BTW, I'm sure you wanted to use another word other than "deceptive." The
56664 bytes is the formatted capacity available for you to use on an
emulated track. How efficiently it is used is really up to you - as a
Storage Vendor I don't find myself choosing your Block Size. If you really
think that the unformatted capacity of an FBA drive in any storage
supporting CKD emulation is based on 56664 bytes then you are in for a bit
of a surprise.
When a customer wants to buy enough disk for 4000x3390-3 they will be sold
the number of drives to support the formatted capacity. The same is true for
SCSI, and if you base your acquisition on the unformatted capacity of
drives. well it's your dog.
Ron
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, December 23, 2008 12:43 PM
> To: [email protected]
> Subject: Re: [IBM-MAIN] How to calculate size of a PS dataset (no, no
> yet again)
>
> It's rarely so simple (and never on MVS). I just tried:
>
> //STEP EXEC PGM=IEFBR14
> //SYSUT2 DD DISP=(NEW,CATLG),UNIT=SYSALLDA,
> // SPACE=(787,7200),DSN=&SYSUID..TEST.SIZE
>
> And got:
> Data Set Information
>
> Data Set Name . . . . : user.TEST.SIZE
>
> General Data Current Allocation
> Management class . . : **None** Allocated tracks . : 185
> Storage class . . . : **None** Allocated extents . : 1
> Volume serial . . . : TSO008
> Device type . . . . : 3390
> Data class . . . . . : **None** Current Utilization
> Organization . . . : NONE Used tracks . . . . : 0
> Record format . . . : ? Used extents . . . : 0
> Record length . . . : 0
> Block size . . . . : 0
> 1st extent tracks . : 185
> Secondary blocks . : 0
> Data set name type :
>
> Creation date . . . : 2008/12/23 Referenced date . . :
> ***None***
> Expiration date . . : ***None***
>
> Now, by my calculation, 787 x 7200 = 5,666,400. This should
> be 100 tracks, not the 185 that appears above.
>
> Your computation gives what deceptive vendors call "unformatted
> space". It's easy to conjecture (though properly we should
> ask) that the OP was interested in the size of the data, not
> the unformatted disk space occupied by the data set.
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
