Thanks for the clarification. It's been three or four years since I did this.
I created SYSPDCBE DCBE BLKSIZE=0 and added a pointer in the existing SYSPRINT DCB DCBE=SYSPDCBE It all worked like a charm. . . 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] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Steve Thompson Sent: Thursday, February 16, 2017 10:46 AM To: [email protected] Subject: (External):Re: LBI w/ TAPE|DASD [Was:31 vs 24 QSAM] 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
