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
