Where's Shai Hess in our time of need?

Tony's iPhone (with toy keyboard) is responsible for this Email. Please do not 
snicker.....

On Aug 25, 2013, at 8:25 PM, "Joel C. Ewing" <[email protected]> wrote:

> 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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to