Re: VSAM in extents
John, For your first paragraph, lets just put it with all those other extent myths. I mean, for sequential access you're just reading the sequence set anyway - what is there to flush!!! Striping sequential datasets can definitely speed up sequential access, but you may need to experiment with the BUFND number that gives you the best results for the combination of stripes and CISZ you use. There is no need to spread stripes across LCU or LSS. It would be more important to spread the STORGRUP evenly across the Bays, Parity Groups and Cache-Halves to give ESS the best chance of pre-fetching from disk faster than the channels request it. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of McKown, John > Sent: Thursday, July 26, 2007 9:07 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: [IBM-MAIN] VSAM in extents > > I'm curious about this one. A person here has stated that when a VSAM > KSDS file is in multiple extents, it performs more poorly than it would > in a single contigueous extent. He said something to the effect that > when a portion of the index is referenced which is in "another extent" > that the entire in-memory buffer for the file is flushed. I have no idea > where he got this information. > > Also, he wants to use SMS striping for VSAM files which are mainly > accessed sequentially because it would significantly decrease the I/O > time to read. We are using multiple FICON connections to a single 2105 > ESS (Shark). We do not have the volumes in any storage group spread > across LCUs. My contention is that it may well decrease I/O, but it > would require that we likewise stripe the volumes across the 2105's LCUs > as well. We don't do this at present. > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology > -- 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: VSAM in extents
I'm curious about this one. A person here has stated that when a VSAM KSDS file is in multiple extents, it performs more poorly than it would in a single contigueous extent. He said something to the effect that when a portion of the index is referenced which is in "another extent" that the entire in-memory buffer for the file is flushed. I have no idea where he got this information. --- In my experience, that's completely bogus. Increasing index buffers in storage is still, IMHO, the best way to improve index performance. The fewer times you do real I/O to the index, the better. Also, he wants to use SMS striping for VSAM files which are mainly accessed sequentially because it would significantly decrease the I/O time to read. We are using multiple FICON connections to a single 2105 ESS (Shark). We do not have the volumes in any storage group spread across LCUs. My contention is that it may well decrease I/O, but it would require that we likewise stripe the volumes across the 2105's LCUs as well. We don't do this at present. -- Striping might help "a little bit", but increasing buffers will help immensely more. You've got loads of storage for buffers; use it! In my experience, striping on RAID hardware seems to have very little effect, what with PVA's and all. Bear in mind: for sequential access, the most important part of the index is the Sequence Set, the very bottom level of the index tree structure. Consider using larger Index CI's and more storage for index buffers. The number of extents has very little, if any, relationship to overall performance. -- 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: VSAM in extents
Where's Mark Thomen when we need him. This is really a little out of my area and when it is I tend not to respond, but I'll have a go anyway... On Thu, 26 Jul 2007 11:06:36 -0500, McKown, John <[EMAIL PROTECTED]> wrote: >I'm curious about this one. A person here has stated that when a VSAM >KSDS file is in multiple extents, it performs more poorly than it would >in a single contigueous extent. He said something to the effect that >when a portion of the index is referenced which is in "another extent" >that the entire in-memory buffer for the file is flushed. I have no idea >where he got this information. Nonsense. I have seen some benchmarks with extents vs. no extents and there is perhaps some small performance saving but I think the bottom line was it was very minimal. And I know one of the line items for z/OS 1.5 (I think that was when it came in) - VSAM extent consolidation - mentioned improved performance, but I think the benefit was more towards decreasing the chance you would run into the 123 extent volume limit than performance improvement. > >Also, he wants to use SMS striping for VSAM files which are mainly >accessed sequentially because it would significantly decrease the I/O >time to read. We are using multiple FICON connections to a single 2105 >ESS (Shark). We do not have the volumes in any storage group spread >across LCUs. My contention is that it may well decrease I/O, but it >would require that we likewise stripe the volumes across the 2105's LCUs >as well. We don't do this at present. But striping will still allow parallel I/O to multiple devices. Consider this analogy. You have a 4 volume multi-volume data set all on that same LCU. Can you dump them quicker by running 4 full volume dumps single threaded, or by running 4 at a time - one per volume. BTW, have you looked at the VSAM Demystified Redbook? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: VSAM in extents
Hi John: The cost for extra extents occurs when the extent is required because of thbe overhead of having to go to the catalog and VTOC. There is a little more virtual storage required. The only other danger is that you run out of available extents allowed for the component. Regards, Gene Sent via BlackBerry by AT&T -Original Message- From: "McKown, John" <[EMAIL PROTECTED]> Date: Thu, 26 Jul 2007 11:06:36 To:IBM-MAIN@BAMA.UA.EDU Subject: VSAM in extents I'm curious about this one. A person here has stated that when a VSAM KSDS file is in multiple extents, it performs more poorly than it would in a single contigueous extent. He said something to the effect that when a portion of the index is referenced which is in "another extent" that the entire in-memory buffer for the file is flushed. I have no idea where he got this information. Also, he wants to use SMS striping for VSAM files which are mainly accessed sequentially because it would significantly decrease the I/O time to read. We are using multiple FICON connections to a single 2105 ESS (Shark). We do not have the volumes in any storage group spread across LCUs. My contention is that it may well decrease I/O, but it would require that we likewise stripe the volumes across the 2105's LCUs as well. We don't do this at present. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: VSAM in extents
If he wishes to improve VSAM KSDS performance, increase the buffers and be generous doing it. If that fails to reach your performance target look at using BLSR and allocate enough buffers for the entire index. Also what is your Index CI size? If it is small 512 or 1024 and your Index level is 3, 4 or higher then increase the Index CI size to 4096. That will reduce the level to 1 or 2 thus reducing the path to find your data. I stand to be corrected but the idea that changing extents will flush the buffer is nonsense. Sequential access would also benefits from large allocations of data buffers, eg. bufnd=180 ( assuming a 4k CI size) From: McKown, John [mailto:[EMAIL PROTECTED] Sent: Thu 7/26/2007 12:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: VSAM in extents I'm curious about this one. A person here has stated that when a VSAM KSDS file is in multiple extents, it performs more poorly than it would in a single contigueous extent. He said something to the effect that when a portion of the index is referenced which is in "another extent" that the entire in-memory buffer for the file is flushed. I have no idea where he got this information. Also, he wants to use SMS striping for VSAM files which are mainly accessed sequentially because it would significantly decrease the I/O time to read. We are using multiple FICON connections to a single 2105 ESS (Shark). We do not have the volumes in any storage group spread across LCUs. My contention is that it may well decrease I/O, but it would require that we likewise stripe the volumes across the 2105's LCUs as well. We don't do this at present. -- 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: VSAM in extents
If the main access of a VSAM file is Sequential, or mixed Random and Sequential, then performance gains can be made without using striping. Use CISZ 18436 for the data part of cluster and CISZ 512 for the index part (assuming DASD is a 3390 model 9 or later). In fact for the most part the 18436 data and 512 index CISZ's usually better for random access as well. Darren -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Thursday, July 26, 2007 9:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: VSAM in extents I'm curious about this one. A person here has stated that when a VSAM KSDS file is in multiple extents, it performs more poorly than it would in a single contigueous extent. He said something to the effect that when a portion of the index is referenced which is in "another extent" that the entire in-memory buffer for the file is flushed. I have no idea where he got this information. Also, he wants to use SMS striping for VSAM files which are mainly accessed sequentially because it would significantly decrease the I/O time to read. We are using multiple FICON connections to a single 2105 ESS (Shark). We do not have the volumes in any storage group spread across LCUs. My contention is that it may well decrease I/O, but it would require that we likewise stripe the volumes across the 2105's LCUs as well. We don't do this at present. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: VSAM in extents
> -Original Message- > From: McKown, John [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 26, 2007 12:07 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: VSAM in extents > > I'm curious about this one. A person here has stated that when a VSAM > KSDS file is in multiple extents, it performs more poorly than it would > in a single contigueous extent. He said something to the effect that > when a portion of the index is referenced which is in "another extent" > that the entire in-memory buffer for the file is flushed. I have no idea > where he got this information. Hmm-m-m. I guess that might possibly be true for small numbers of buffers, but in my experience it's demonstrably NOT true when using SUBSYS=(BLSR...) or the newer SMB facility (AMP='ACCBIAS=...'). With sufficient in-memory buffers, there should be no or little distinction between one or many extents. Might this be knowledge that dates back to real SLED devices and constrained memory environments? Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
VSAM in extents
I'm curious about this one. A person here has stated that when a VSAM KSDS file is in multiple extents, it performs more poorly than it would in a single contigueous extent. He said something to the effect that when a portion of the index is referenced which is in "another extent" that the entire in-memory buffer for the file is flushed. I have no idea where he got this information. Also, he wants to use SMS striping for VSAM files which are mainly accessed sequentially because it would significantly decrease the I/O time to read. We are using multiple FICON connections to a single 2105 ESS (Shark). We do not have the volumes in any storage group spread across LCUs. My contention is that it may well decrease I/O, but it would require that we likewise stripe the volumes across the 2105's LCUs as well. We don't do this at present. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
