I'm believe that for consistency with the same (irrational) choice made
for JCL allocation, KB and MB in IDCAMS defines are interpreted to
mean KiB and MiB (i.e., 2**10 and 2**20 Bytes).
I usually allocate in RECORDS instead of KB and MB, so am not certain of
the rules for the latter, but suspect they may be similar - in which
case the allocation is based on effective available space on an initial
load of the dataset, which presumes that CI and CA free space will not
be used. I'm guessing you may be talking about a KSDS dataset with a CI
FSPC sufficiently large that your initial load would only utilize 24 KiB
per track.
The rules for calculating RECORD allocation for a KSDS used to be
something like
records-per-CI = FLOOR( ( (DATA-CISIZE)*(1 - CI-FSPC/100) -
10)/AvgRecLeng )
records-per-CA = records-per-CI * FLOOR((CIs-PER-CA)*(1 - CA-FSPC/100))
CAs-ALLOCATED = CEIL( records-requested / records-per-CA)
So, to calculate the number of tracks or cylinders required for the
requested number of records, you have to first know the CI and CA sizes
and average record length, and then de-rate that space for the CI and CA
free space that will be left unused during an initial data load.
The -10 in the records-per-CI comes from the minimum number of control
(non-data) bytes required in the CI, which occurs only if all records
happen to have identical length. If record lengths actually vary, more
than 10 control bytes will be used per CI.
There used to a Red Book that described the details of logical record
storage within VSAM KSDS data sets. It predated, KB, MB, and record
allocation; but I extrapolated what I learned there to fit the behavior
I have since observed with the later space allocation forms.
M. Castelein wrote:
Hi,
Using a 3390 DASD and specifying KILOBYTES(25 24) on a DEFINE CLUSTER
results in the following space allocation:
- primary space = 2 tracks
- secondary space = 1 track
This assumes that one 3390 track cannot hold more than 24 KB of data.
And seemingly, the DEFINE CLUSTER with the KILOBYTES parameter does NOT take
the average record length in consideration.
And I cannot find any documentation explicitly indicating whether K stands
for 1000 (10**3) or 1024 (2**10), and whether M stands for 100 (10**6)
or 1048576 (2**20).
Similarly, the documentation does not explain the algorithm used by IDCAMS
to translate a space request for a given number of RECORDS (of a given
average length).
Any idea where I could find more detailed info about the way IDCAMS
processes the KILOBYTES, MEGABYTES, and RECORDS parameters on the DEFINE
CLUSTER command?
TIA
--
Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED]
--
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
