Fifty percent savings in residence time are likely to be reflections
of larger block sizes, asynchronous, overlapped I/O operations
(possible, even easy, with BSAM), or both.
Some measurements would be in order.
John Gilmore, Ashland, MA 01721 - USA
On 8/17/12, Dana Mitchell mitchd...@gmail.com
All,
We are upgrading to z/OS 1.13 from 1.11. ADRDSSU will now use BSAM and
blocks of 262k (1.11 used 65k).
Has anyone seen big benefits in their shop from this change?
Mike Martin
/PREThis email may contain confidential and privileged material for the sole
use of the intended
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Martin, Mike
Sent: Thursday, August 16, 2012 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ADRDSSU Large block performance
All,
We are upgrading to z/OS 1.13 from 1.11. ADRDSSU will now use BSAM
Yes, significant elapsed time improvement, to start.
Unfortunately, there are instances where someone has hardcoded BLKSIZE= which
overrides the LBI benefits. Consider scaning the tape management catalog,
looking for these improvement opportunities (removing any/all DCB parameter
values).
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADRDSSU Large block performance
My site saw big improvements in DB2 z/OS (Image Copy) backup elapsed times.
We're implementing LBI, but have encountered problems with below-the-line
storage for batch IMS writing sequential files, and with IMS GSAM
@LISTSERV.UA.EDU
:: Subject: ADRDSSU Large block performance
::
:: We are upgrading to z/OS 1.13 from 1.11. ADRDSSU will now use BSAM and
:: blocks of 262k (1.11 used 65k).
::
:: Has anyone seen big benefits in their shop from this change
