Why is blksize concerning you? Are you trying to reduce tape usage (reducing 
IRG) or make backup faster? Something entirely different?

If it's to speed up the dump, then as Lizette says, optimize will reduce 
overall time but take care because it can have an affect on other work. You may 
cause unacceptable delays in other jobs (e.g DB2).

As for the physical record size (block size), DFDSS is choosing it based on the 
environment. I'm guessing but you might be able to affect block size with the 
following:
1. Only INCLUDE a single dataset. ".**" wildcard selection may be allowing 
DFDSS to backup multiple datasets concurrently thus causing multiple buffers to 
be allocated. 
2. Increasing REGION size may allow virtual storage size.
3. Non-VSAM versus VSAM (CI's can have significant wasted space).
4. Dataset block size or track size.

I hope you find what you are looking for.

Jon Perryman. 
On Tuesday, May 6, 2014 9:38 PM, Lizette Koehler <stars...@mindspring.com> 
wrote:
 
The SPHERE is needed when dumping VSAM.  If this is PS it is not needed
>
>Second, the default, OPTIMIZE(1), reads one track at a time. OPTIMIZE(2), (3), 
>or (4) results in less elapsed time and fewer I/O operations on the DASD 
>device whenever the load on the tape channel is low enough and the tape speed 
>is high enough to keep pace with the data being read from the DASD volume. To 
>obtain the best performance with DFSMSdss and 3592's, specify OPTIMIZE(4).
>
>So I would try adding OPTIMIZE(4) to your control cards and remove the SPHERE 
>unless you are dumping VSAM.
>
>I am not sure why the BLKSIZE is of concern.  I would work on optimizing DFDSS 
>to run at its best.  Remember DFDSS will probably add to your output file 
>certain key information it needs to restore the file.
>
>For a physical dump, each logical volume of a DFSMSdss dump data set contains 
>the following data in the following sequence:
>
>    Volume header record, which identifies and contains data pertinent to the 
>whole volume and identifies the type of operation that created the dump.
>    Map record or records, which map the tracks that were dumped. The data in 
>this record is described by the ADRBMB Data Area.
>    Track 0: dump of track 0 of cylinder 0.
>    VSAM volume data set (VVDS) track records, if VSAM or SMS-managed data 
>sets exist on the volume and were dumped.
>    Volume table of contents (VTOC) track records.
>    Data track records, which include VVDS if it is part of the dump. This 
>item is repeated for all tracks being dumped.
>    Two volume trailer records, which identify the end of the data for the 
>DASD volume.
>
>For a logical dump, the format of the DFSMSdss dump data set contains the 
>following data in the following sequence:
>
>    Tape header record.
>    List of potential data sets record.
>    Data set header record.
>    Volume header record (one for non-VSAM data sets, one for each VSAM 
>component).
>    Sphere information record (if the SPHERE keyword was specified and this 
>data set is part of a sphere).
>    Data track records (one or more for each track of the data set on this 
>volume).
>    Two data set trailer records.
>
>So, I am still trying to understand your problem with BLKSIZE.  What 
>specifically is the issue?  If it is performance, then the OPTIMIZE should 
>help.
>
>DFDSS output dump file does its own process.  I have coded my own BLKSIZE on a 
>Dump output.  It did not matter.  DFDSS did what it felt was correct.
>
>Lizette
>
>
>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Victor Zhang
>> Sent: Tuesday, May 06, 2014 9:10 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Change tape block size
>> 
>> Lizette,
>> Here it is:
>> For PS  dataset:
>>   DUMP -
>>      OUTDDNAME(ODD) -
>>          DATASET(INCLUDE(TEST.DATA)) -
>>          TOL(ENQF) SPHERE
>> 
>> For SMS compact extended format dataset:
>>   DUMP -
>>      OUTDDNAME(ODD) -
>>          DATASET(INCLUDE(TEST.AB2F.**)) -
>>          TOL(ENQF) SPHERE
>> 
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

----------------------------------------------------------------------
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