Larry, Swings and roundabouts I think. IMBED would cause the sequence set to be pre-fetched along with the data and not pushed out by other cache activity. One cache miss is a lifetime compared to a cache hit on FE4.
Sequential pre-fetch operates on a far wider stripe then one CYL (up to 64 tracks in HDS) so the difference observed would be the connect time for a 7% increase in Start-Sub-channels. That assumes you have buffered up enough to chain one CYL per IO. Users that have default buffering or SMB would not see any noteworthy degradation. And we both assume a well ordered dataset :) Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Larry Crilley > Sent: Wednesday, January 16, 2008 8:30 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: [IBM-MAIN] Performance issues with VSAM IMBED > > I would think IMBED could degrade performance when doing sequential > I/O. > Given enough buffers, VSAM can read in as much as an entire CA's worth > of > data with each I/O. Since IMBED would take an entire track away from > your > CA size, then your CA is significantly smaller and less data can be > returned > with each I/O. Even with a CYLINDER for a CA size, you would only be > able > to return 14 tracks worth of data when the dataset is defined with > IMBED. > Without IMBED, you could return 15 tracks. > > > > Larry Crilley > Dino-Software Corporation > 800.480.DINO > 412.366.3566 > www.dino-software.com > > Dino-Software Utilities > T-REX - Superior catalog management tool inclusive of HSM & Tape audits > REORGadon - First REORG While-OPEN tool for HSM > Teradon - First ever OnLine REPRO MERGECAT utility > Xtinct - DASD Data purge > RTD - DASD Real Time Defrag > DAL - Analysis for Legato in an easy to view format > Sentinel - Real-time FTP Management. All secure, all the time. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf > Of Ron Hawkins > Sent: Wednesday, January 16, 2008 11:15 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Performance issues with VSAM IMBED > > Lizette, > > From the Storage side I would disagree that imbed and replicate degrade > performance. Yes, REPLICATE wastes space, and neither actually improve > performance, but there is no degradation. > > IMBED was meant to reduce seek, and REPLICATE to reduce Latency. Thus > the > statement " have been obsoleted by newer, cached DASD devices" explains > why > they are no longer required. > > Ron > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > > Behalf Of Lizette Koehler > > Sent: Wednesday, January 16, 2008 7:41 AM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: [IBM-MAIN] Performance issues with VSAM IMBED > > > > I have been reading the z/OS V1.7 to V1.9 Migration guide and though > it > > states you do not need to remove IMBED, REPLCIATE or KEYRANGE. It > does > > mention that there is a performance issue by having them on your VSAM > > files. > > > > I was wondering if anyone did an analysis to see what the buy back > for > > VSAM response was if these are removed? It would help me build a > case > > to get the VSAM data sets reorged more quickly. My VSAM seems to be > > strictly IMBED at this time. I did not find any KEYRANGE or > REPLICATE > > definitions. > > > > Redefine existing VSAM data sets that contain the IMBED, REPLICATE, > and > > KEYRANGE attributes > > > > Description: No supported release of z/OS honors the IMBED, > REPLICATE, > > and KEYRANGE attributes for new VSAM data sets. In fact, using these > > attributes can waste DASD space and often degrades performance. > > Servicing these VSAM data sets has become increasingly difficult. In > > some cases, unplanned outages have occurred. For these reasons, IBM > > recommends that you stop using IMBED and REPLICATE, and that you > > minimize or eliminate your use of KEYRANGE. IMBED and REPLICATE were > > intended as performance improvements and have been obsoleted by > newer, > > cached DASD devices. Striped data sets provide much better > performance > > than KEYRANGE and should be viewed as a candidate for any existing > > KEYRANGE data sets. > > > > > > Is the migration action required? > > No, but recommended to avoid degraded performance and wasted DASD > > space. > > > > > > Any comments are always welcomed. > > > > Lizette > > > > --------------------------------------------------------------------- > - > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN > INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
