About 2 years ago, I was working on determining a performance
problem with an ISV product. They were processing a very large
amount of data and so we moved their data off to Tape, with the
idea that we could cut the CPU burn of the product (as in, make
it wait for I/O as it was eating 65-85% of a single CPU - single
tasking, not multi-tasking).
What I found, in moving it to tape (VTS) is that the virtual tape
was responding faster than DASD. And this was w/o LBI.
Did some further testing with LBI (and a test program that had
the ability to handle LBI), to find that it was able to process
the data faster than it could from DASD. Significantly faster --
it seems that the VTS was reading from disks into cache, and it
was caching the "tape" at a rate greater than the DASD Raid boxes
could respond for the same I/O.
Then we put in a request to the vendor of the first product for
LBI support and had to explain to them why.
Also, to a different post -- You can't replace a DCB with a DCBE.
You use them in conjunction with each other, and store the
address of the DCBE into the DCB BEFORE OPEN, and if all the
flags are correct, you have LBI support once OPEN is finished.
Regards,
Steve.T
On 02/16/2017 11:44 AM, Jesse 1 Robinson wrote:
I mentioned having modified a QSAM program to write 'large blocks' by replacing
DCB with DCBE. My goal was to test the effect of very large blocks in our new
tape subsystem, which we had learned was highly biased in favor of large
blocks. This had nothing to do with AMODE, which was all 31. The program
certainly ran faster with large blocks such as 260K. I could not distinguish
improvement at the IOS level (lower I/O count) vs. improvement at the tape
level. Most likely a combination.
My problem with the new tape was that the vendor seemed to assume that a
customer could just tweak JCL to create giant blocks. In fact many of our
largest tape files are created by utilities--IBM or otherwise--that are not
written for large blocks. In practice you can code as large a block size as you
wish, but if the program contains only DCBs, any size greater than 32K is
simply ignored without error. While the change to DCBE was very simple, it has
to be accomplished by the program owner.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
[email protected]
<SNIPPAGE>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
