Yes, physical I/O internally within the DASD subsystem would likely be
at least full track I/O or even multi-track. However, physical I/O over
the channel will still be based on the z/OS perception that the devices
behind the controller are CKD DASD, with device-specific track and
cylinder structure, and channel I/O would still be at the single z/OS
logical-block, C-K-D-record level if from an application that considers
that the appropriate granularity of access.
As long as z/OS perceives these as CKD devices with tracks and
cylinders, one cannot presume that those emulated track and cylinder
boundaries have no significance. z/OS still has to make decisions on
how to map data to the device and how to structure channel programs for
the device based on those perceived boundaries. Those decisions can
still impact the amount of useful data stored per track and the overhead
involved with transferring useful data over the physical channel.
That said, sizing a PDS directory to end or not end at a track boundary
is probably irrelevant to performance; unless one encounters a
boundary-condition bug in an application that is somehow sensitive to
perceived track boundaries.
Joel C. Ewing
On 08/25/2013 03:55 PM, Mike Schwab wrote:
> On emulated DASD, I/O is almost always an entire track at a time.
>
> On Sun, Aug 25, 2013 at 3:25 PM, John Gilmore <[email protected]> wrote:
>> Gerhard,
>>
>> Your arguments would be/are persuasive for a real, spinning DASD. On
>> an emulated one they are not. What, for example, does 'track
>> oriented' mean when the underlying architecture is FBA? When the
>> underlying architecture is random-access storage?
>>
>> John Gilmore, Ashland, MA 01721 - USA
>>
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
