[email protected] (Fred van der Windt) wrote:
I want to retrieve the primary allocation of a dataset. Sofar I've used OBTAIN
to retrieve the DCSBs for the dataset. The DSCB1 contains information about the
secondary allocation size for the dataset but does not contain any information
about the primary allocation. If the dataset had a primary allocation in tracks
or cylinders I can retrieve the necessary information from the extent
information in the DSCB1: the first extent can be converted back to tracks or
cylinders and that should be the primary allocation.
But how can one recreate the primary allocation if some other form was used,
for instance an amount in blocks, records or KB or something like that? Is this
documented anywhere?
As I think you found, the primary allocation is represented in the F1 or
F8 DSCB by DS1EXT1 and following fields, and perhaps by "extension
DSCBs" that contain additional extent descriptions, which if present
should be pointed to by DS1PTRDS.
So far as allocation units go, what is in DSCBs is cylinder and head
(track) information. Eventually, it all boils down to the physical
allocation units* the system supports for data sets, which are tracks,
though you can choose to begin allocation on a cylinder boundary (which
is indicated by DS1CYL) and allocate in numbers of cylinders, or use
other units the system supports for the specification of disk space. At
allocation time, the system converts anything other than tracks to
tracks, basically. The type of specification is saved, but not used.
I never actually checked, but I "assume" that ISPF and other things that
show used space in allocation request units other than tracks or
cylinders use the DS1DSPAC fields and track length to calculate space in
those original request units. These are necessarily fuzzy numbers for
some kinds of data sets in comparison to the actual numbers of blocks
contained or the actual number of KB or MB actually written. I think
they're about as useful as they can be when allocating a new data set
using the same number the tool displays yields the same size data set as
the original (smile), and I believe this to be the case for ISPF a very
high percentage of the time (if not 100% of the time).
How much of this is documented? No idea...
* Not truly physical any more, post-3390, but rather emulated on modern
disk; however, the logical architecture remains the same even though the
physical layer varies underneath it.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
