On 05/14/2014 07:03 PM, Ed Gould wrote:
> On May 14, 2014, at 5:31 PM, Joel C. Ewing wrote:
>
>> Prior to 3480's with IDRC the physical block size on tape corresponded
>> to the block size sent across the channel by MVS and the maximum tape
>> data transfer rate was invariably bounded by the physical tape drive
>> speed and the relation
>> mean-data-rate B/sec = percent-of-tape-used-for-data x
>> drive-transport-speed in/sec x density B/in,
>> and the shorter the physical blocks, the greater the number of
>> Inter-Record-Gaps IRGs) resulting in lower effective tape utilization
>> and lower effective transfer rate.  Prior to 6250 bpi recording
>> technology, tape media and drive reading reliability generally dictated
>> physical block sizes considerably less than 32KiB.  My recollection is
>> that the 6250bpi drives were the first to be consistently reliable
>> enough to make using a block size of ~32KiB reasonable from a tape
>> performance viewpoint (other resources could still be constraining
>> factors).  At that block size, effective tape media utilization at
>> 6250bpi was still only about 94%, but MVS block size limits prevented
>> going larger.
>>
>> The greater 38KiB density and greater reliability of 3480's increased
>> the significance of tape lost to IRGs again, but the introduction of
>> hardware compression on 3480's and its successors took the physical tape
>> utilization issue out of the hands of MVS and programmers by forcing
>> data into 256KiB physical super-blocks on the tape hardware level
>> regardless of MVS's concept of block size.  Use of larger block sizes
>> today on MVS reduces the system and application overhead by managing
>> fewer I/O buffers and initiating fewer channel programs to transfer the
>> same amount of data, but it does not affect physical tape utilization
>> andI would not expect the effect to be as dramatic as in the old days
>> when a really bad MVS physical block size could easily elongate program
>> run time and physical tape usage  by a factor of 10 or more when over
>> 90% of the physical tape was consumed by IRGs (and this fact was
>> periodically rediscovered by some application programmer).
>>
>> The DFDSS manuals may not emphasize the default 256KiB MVS tape block
>> size because that support is over a decade old and the only thing that
>> should be reading a DFDSS tape is a compatible version of DFDSS.  I
>> would at least hope that none of the DFDSS JCL examples imply that
>> BLKSIZE is recommended or a wise idea for tape output DDs.  I still
>> remember seeing the HOLD data on the PTF that added 256KiB block support
>> to DFDSS --  It was critical to know that once that support was added,
>> that the DFDSS used at a DR site or on a recovery system or on your
>> stand-alone IPL tapes had to also be at the new level in order to
>> restore from the generated backup tapes.
>>     Joel C. Ewing
>
> Joel:
>
> But this was how long ago? The DFDSS doc should have been update by
> now. no?
>
> Ed
>
>
Well granted it is hard to find and much more complicated than I
remembered, but this feature was incorporated into z/OS 1.12 and
"DFSMSdss Storage Administration" manual for z/OS 1.12 does have under
"Chapter 1 Introduction...", "Dumping data efficiently", "Space
Considerations" the following paragraph relating to DUMP output:

"The default block size for output records that are written to tape is
the optimum
block size for the output device (262 144 is the maximum). You can
change this
default to 32 760 by using the installation options exit routine. See
the discussion of
system-determined block size in z/OS DFSMS Using Data Sets for a
description of
the optimum block sizes of the supported tape devices."

The DFDSS manual doesn't explicitly say what the default value is
because it is dependent on the specific tape device type (or
installation exits) and apparently the optimum tape device block size is
part of z/OS Large Block Interface support and not part of DFDSS (which
makes sense when you think about it).  Since DFDSS does not control what
the actual values are, you have to go to a non-DFDSS manual to find a
table of the actual optimum values ("z/OS DFSMS Using Data Sets",
"Chapter 21 Specifying and Initializing Data Control Blocks", "Selecting
Data Set Options", "Block Size").

This is not a tidbit of information that the average user needs to know
to use DFDSS successfully, so perhaps it is OK that it takes some
digging to locate.

-- 
Joel C. Ewing,    Bentonville, AR       jcew...@acm.org 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to