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 out in San
Jose. But through the years the best thruput as to always code 32K
for job where performance is needed. Of course with new technology I
expect that the device that can handle 256K blocksize be used.
I have often disliked the DFDSS manuals for not being straight
forward in their documentation. I don't think DFSMS does the right
thing with blksize=0 for tape, my memory is obsolete here but it used
to be 16K when blocksize eq zero is used.
Ed
On May 13, 2014, at 6:25 PM, Skip Robinson wrote:
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
easy
demonstrate by coding ever larger block sizes. EXCP count and
elapsed time
will both decrease.
-- You can't just increase output block size willy-nilly. A program
that
uses a traditional DCB is limited to 32K bytes per block. To exceed
that
value, a program must employ DCBE, which is not hard to use but
requires
coding changes.
-- If you attempt to code >32K block size in JCL for a program with
DCB,
the value will be ignored and revert to 32K. You might miss that fact
because there's no message. Your tape management product (CA-1,
RMM, etc.)
will show you the actual block size of a file.
-- Some IBM utilities are coded with DCBE to enable >32K block size.
Others are not. Doc for each utility should indicate the maximum
allowable
output block size.
-- DFSMSdss Storage Administration has this to say:
"If the DCB keyword BLKSIZE is specified on the DD statement for
tape, it
must be in the range of 7,892 through 262,144. If the DCB keyword
BLKSIZE
is specified on the DD statement for DASD, it must be in the range of
7,892 through 32,760."
So DFDSS uses DCBE and can write 256K blocks. In my testing, a job ran
quite a bit faster with the maximum block size than with a smaller
one. (I
did not test DFDSS per se.) But as already indicated, the inhibitor to
stellar performance may be on the input side, over which you have
little
control.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Ron Hawkins <ronjhawk...@sbcglobal.net>
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 05/13/2014 09:15 AM
Subject: Re: Performance for DFDSS with ORACLE Tape Drives
VSM5 (
was Change tape block size)
Sent by: IBM Mainframe Discussion List <IBM-
m...@listserv.ua.edu>
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 the
time
spent processing the input files? I may be having a senior moment, but
there are two things that may be affecting the performance of the PS-E
data set. (1) I seem to recall that DFSMSdss will process a compressed
PS-E data set at block level and not attempt to compress it in
order to
avoid double compression overhead when COMPRESS is specified, and (2)
compressed PS-E data sets do not chain more than one track of at a
time.
I'll leave it to you to hit the manuals and see if I recall correctly.
Considered together this means the input file may well be the choke
on the
backup performance. It may pay to start some RMF monitor II background
sessions at 5 second intervals for the input volumes and output tape
addresses and have a look at the make-up of response time on both.
Omegamon or similar may also provide a delay analysis that shows
where the
job is spending its time.
An extreme consideration would be to ask if you are using FX8S
channels
and zHPF? Channel microprocessor usage with Extended format IO was
one of
the many benefits of zHPF and channel throughput from DASD may be
part of
your problem.
Ron
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Lizette Koehler
Sent: Monday, May 12, 2014 7:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Performance for DFDSS with ORACLE Tape Drives
VSM5 ( was Change tape block size)
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 hardware
controls
the process.
I would open an issue with STK and ask them to assist you with this
configuration. There may be a parm or function unique to STK that
may
help
you.
I might also open an SR/ETR with IBM DFDSS to see if they have any
suggestions.
Lizette
PS I changed the subject to for more visibility
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-
m...@listserv.ua.edu]
On Behalf Of Victor Zhang
Sent: Sunday, May 11, 2014 11:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Change tape block size
Hello,
First I need thank you who replied to my question.
I should introduce my problem's background and my concern.
The tape is virutal tape of oralce, vsm5.
I am backing up extended format PS dataset to VSM5 using ADRDSSU.
I tested using dss to backup, no matter what block size I
specified in
JCL, ADRDSSU will report same number of blocks in message IEC205I.
And the backup speed will also be same no matter what block size I
specified in JCL.
Here is my testing result:
st_TIME end_TIME backup source data type
VOLSER
VTV
size(mb) VTV size(comp)(mb) tape block
size(KB) Total block
count
reported by DSS backup speed(MB/S)
11:31:41 11:33:12 Extended format
compressed AB3968
1854.15 647.77 128 33879
20.38
11:33:12 11:34:42 Extended format
compressed AB3974
1854.15 647.77 64 33879 20.60
11:34:42 11:36:17 Extended format
compressed AB3976
1854.15 647.77 256 33879
19.52
But this is not true for BASIC PS dataset, for basic PS dataset, I
did a similar
testing:
st_TIME end_TIME backup source data type
VOLSER
VTV
size(mb) VTV size(comp)(mb) tape block
size(KB) Total block
count
reported by DSS backup speed(MB/S)
13:08:07 13:11:37 Basic PS AB4075
6273.86
360.15
128 49117 29.88
13:11:37 13:16:00 Basic PS AB4078
6274.57
367.9
64 98426 23.86
13:16:00 13:19:04 Basic PS AB4082
6273.51
355.52
256 24528 34.10
Please note the total block count reported by DSS is different when
specifying different tape block size.
My goal was:
To improve backup performance for extended format PS dataset(DB2
image
copy on dasd)using ADRDSSU,I am trying to use 256KB to improve
performace,but I can't.
Do you have any ideas?
Regards
Victor
----------------------------------------------------------------------
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
