Hello,
I've noticed a strange dss behavior and want ask explanation:
After I finished dss backup, I always received a message similar to this:
15.29.56 JOB31114 IEC205I ODD,BKDS,BACKUP,FILESEQ=1, COMPLETE VOLUME LIST,
870
870 DSN=BKUP.D003,VOLS=PT0541,TOTALBLOCKS=12122
Is the
Victor, IEC205I gets the TOTALBLOCKS from system control blocks. It should
match what rmm records (gets it from same place.. Actually it depends on
access method and whether that method maintains the block count fields. EXCP
does not and the application must maintain it.
The block count is
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
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
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
Victor,
If I understand problem at the root of your questions, you are trying to speed
up DFSMSdss logical dumps, especially for compressed PS-E data sets.
From your questions you are focusing on the tape output rate as the gating
factor for the elapsed time of the dump, but have you looked at
We had some issues a while back with VSM performance. I did research and
experiments with various block sizes for tape data sets. Questions on
IBM-MAIN and doc reading yielded some answers--though not necessarily
solutions.
-- Tape output is generally faster with larger block sizes. That's
Skip:
Our IBM SE (30+ years ago) wrote an orange manual (how many remember
those?),
About blocksize and tape. It pretty much said that use of a 32K
blocksize as optimum for channel and tape utilization (this was 6250
BPI IIRC).
Jim (our SE has retired) after serving time at the WSC and
Victor,
The blksize is not the only way to tune a process for efficiency. And in some
cases, there is little you can do to affect some applications like DFDSS.
If you are using the hardware for tape is virtual tape of oracle, vsm5. Then
there may be nothing more you can do. Sometimes the
It is my recollection that, pretty much since the advent of buffered tape
drives (e.g. 3590, 9840,... ) the actual blocksize written to tape is
independent
of what is specified in the JCL.
In other words, it does not matter what you code in JCL, the actual data block
written to physical tape
W dniu 2014-05-12 21:02, Staller, Allan pisze:
It is my recollection that, pretty much since the advent of buffered tape
drives (e.g. 3590, 9840,... ) the actual blocksize written to tape is
independent
of what is specified in the JCL.
In other words, it does not matter what you code in JCL,
Agreed. Low compression ratios will produce more blocks to actually be
written to the tape, elongating total application time.
snip
W dniu 2014-05-12 21:02, Staller, Allan pisze:
It is my recollection that, pretty much since the advent of buffered
tape drives (e.g. 3590, 9840,... ) the
So what gets sent down the channel? If I put BLKSIZE=1024 on my JCL for the
output DD statement of the DFDSS dump job, will DFDSS dutifully send 1K blocks
down the channel to the tape controller/drive and the hardware builds big
blocks and writes the large block to the tape, or does DFDSS know
W dniu 2014-05-12 21:16, Pommier, Rex pisze:
So what gets sent down the channel? If I put BLKSIZE=1024 on my JCL for the output DD
statement of the DFDSS dump job, will DFDSS dutifully send 1K blocks down the channel to
the tape controller/drive and the hardware builds big blocks and writes
W dniu 2014-05-12 21:12, Staller, Allan pisze:
Agreed. Low compression ratios will produce more blocks to actually be
written to the tape, elongating total application time.
High compression is not good also. BTDT. The optimal compression is the
one assumed by the vendor, usually 3:1 *IBM) or
15 matches
Mail list logo
