IIRC, these features caused index entries to be embedded in the data and then replicated to fill out a partially used CI/CA. The idea was to minimize arm/head movement and rotational latency as VSAM tried to satisfied a random read request. It follows that performance implications would vary depending on the access pattern.
I guess one extreme would be a WORM (write once, read many) where the file is loaded once then sequentially read. The price should be limited to dragging around excess data and suboptimal buffer/cache exploitation. The other is a file that suffers from large numbers of random inserts/deletes. Then VSAM would have to expend a lot of energy keeping all those index entries in sync. As the doc suggests, the redundant index entries are created and maintained but never used for anything. So, the results of the definitive performance study is: YMMV :-) HTH and good luck -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Wednesday, January 16, 2008 9:41 AM To: [email protected] Subject: 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- 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
