Re: Performance issues with VSAM IMBED
My main reason for asking is we still have VSAM defined with IMBED. Fortunately no KEYRANGE or REPLICATE, at least no IEC161I messages with those sub codes. Since the statement was made that there is a performance issue, I was hoping to find some verification so that I could convince my users to reorg their files over the next year to get those removed. But if I cannot support the statement, it may be a more difficult road to travel. Zapping something is so much easier than doing a reorg of a file that may be 4GB or larger or having to have an application outage to do it. Same issue with some user catalogs. Since I know I am not the only shop, I was also wondering if anyone else was running into this situation and how they are going about trying to get their files reorg'd. This is just pure curiosity on my part. Lizette 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 -- 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
Re: Performance issues with VSAM IMBED
Since I know I am not the only shop, I was also wondering if anyone else was running into this situation and how they are going about trying to get their files reorg'd. REORG is not enough. You have to unload, redefine, reload. REORG alone does not remove the attributes. We had to bite the bullet and take application outages. We started three years ago. There were still a lot to do when I was downsized 7 months ago. - Too busy driving to stop for gas! -- 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
Re: Performance issues with VSAM IMBED
As others have mentioned, for VSAM files, there is no way around the outage. You must unload/delete/redefine/reload. For catalogs, you do have options as several products on the market tout the ability to reorganize (including delete/define) a catalog while it remains open. T-REX, is one of those tools. 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 Lizette Koehler Sent: Thursday, January 17, 2008 6:51 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Performance issues with VSAM IMBED My main reason for asking is we still have VSAM defined with IMBED. Fortunately no KEYRANGE or REPLICATE, at least no IEC161I messages with those sub codes. Since the statement was made that there is a performance issue, I was hoping to find some verification so that I could convince my users to reorg their files over the next year to get those removed. But if I cannot support the statement, it may be a more difficult road to travel. Zapping something is so much easier than doing a reorg of a file that may be 4GB or larger or having to have an application outage to do it. Same issue with some user catalogs. Since I know I am not the only shop, I was also wondering if anyone else was running into this situation and how they are going about trying to get their files reorg'd. This is just pure curiosity on my part. Lizette 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 -- 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
Re: Performance issues with VSAM IMBED
Sorry, to me that is a reorg. I know there is a shorter reorg that is unload/reload. But in my mind a true REORG is unload/delete/define/reload. Sorry about not being more specific. Lizette Since I know I am not the only shop, I was also wondering if anyone else was running into this situation and how they are going about trying to get their files reorg'd. REORG is not enough. You have to unload, redefine, reload. REORG alone does not remove the attributes. We had to bite the bullet and take application outages. We started three years ago. There were still a lot to do when I was downsized 7 months ago. -- 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
Re: Performance issues with VSAM IMBED
snip My main reason for asking is we still have VSAM defined with IMBED. Fortunately no KEYRANGE or REPLICATE, at least no IEC161I messages with those sub codes. Since the statement was made that there is a performance issue, I was hoping to find some verification so that I could convince my users to reorg their files over the next year to get those removed. But if I cannot support the statement, it may be a more difficult road to travel. Zapping something is so much easier than doing a reorg of a file that may be 4GB or larger or having to have an application outage to do it. Same issue with some user catalogs. Since I know I am not the only shop, I was also wondering if anyone else was running into this situation and how they are going about trying to get their files reorg'd. This is just pure curiosity on my part. ---unsnip--- Unfortunately, I was reduced to writing a program that would read the entire cluster, then do the same with a copy of the cluster with those options removed. When I finished that demonstration, on a 3000 cylinder cluster, senior management was convinced and issued a order that those clusters still using those options would be immediately converted. No exceptions. The process took 10 days, with all applications managers cooperating fully. Probably the only time I got a change for the better implemented in less than 6 months! :-) -- 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
Re: Performance issues with VSAM IMBED
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: IBM-MAIN@BAMA.UA.EDU 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
Re: 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
Re: Performance issues with VSAM IMBED
I could be wrong, but doesn't SMS stop IMBED and REPLICATE being used now anyway? Maybe it is under some circumstances (extended format?). Whatever, duplicating a index CI around a whole track is going to cost time during index updates. I am not current on the latest dasd and caching, but I seem to remember that the duplication used to pollute the cache and so had an effect on performance. It probably worked fine on 3330s. Those were the days! -- Mike Poil Java z/OS Level 3 Service IBM United Kingdom Limited, Hursley Park, Winchester SO21 2JN Internal: 246824 External: +44 (0)1962 816824 Java debugging: http://www.ibm.com/developerworks/java/jdk/diagnosis/ -- Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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
Re: Performance issues with VSAM IMBED
I could be wrong, but doesn't SMS stop IMBED and REPLICATE being used now anyway? But, on existing files the parameters are still there. If you specify the parms in an IDCAMS job, they are ignored -- no syntax error. The file won't have them. It's not due to SMS, rather DFP. I modified VCLONE from the CBT. It does the same thing, but won't pass the three options through. It will also dump the control cards into a PDS (as an option). I called it VC3, and I don't recall which file it is on. - Too busy driving to stop for gas! -- 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
Re: Performance issues with VSAM IMBED
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
