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] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Elardus Engelbrecht Sent: Wednesday, February 15, 2017 9:53 PM To: [email protected] Subject: (External):Re: 31 vs 24 QSAM Joseph Reichman wrote: >I'm going to run it again tomorrow >Just to double check With varying LRECL, BLKSIZE and quantity of records/blocks. If you can, of course. Also read a block, read it again, write and write it again. I'm sure you will get 'interesting' numbers. Good luck. If you do that properly, that testing should be a good Red-Book article. Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
