Re: Real Storage Allocation
Thank you all for your replies. My immediate concern was whether there were any issues/problems with over-allocating storage and with your responses, I am confident I can plough ahead. Thanks also for all the tips on how to debug and what to analyze. That's a step for later. Your time and assistance are much appreciated. Regards, Phil On Mon, Feb 15, 2016 at 9:22 AM, John Abell < john.ab...@intnlsoftwareproducts.com> wrote: > As long as your z/OS isn't running under, z/VM like may smaller ISVs, > where LFAREA is not yet supported. > > John T. Abell > Tel:800-295-7608Option 4 > President > International: 1-416-593-5578 Option 4 > E-mail: john.ab...@intnlsoftwareproducts.com > Fax:800-295-7609 > > International: 1-416-593-5579 > > > International Software Products > www.ispinfo.com > > This email may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review, use, retention, distribution > or disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive on behalf of the named recipient), > please contact the sender by reply email and delete all copies of this > message. Also,email is susceptible to data corruption, interception, > tampering, unauthorized amendment and viruses. We only send and receive > emails on the basis that we are not liable for any such corruption, > interception, tampering, amendment or viruses or any consequence thereof. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Jaffe > Sent: Sunday, February 14, 2016 5:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Real Storage Allocation > > On 2/14/2016 11:19 AM, Graham Harris wrote: > > Ed Jaffe wrote: > > > > > >> The nice thing about an overabundance of real storage is the ability > >> to > > create a very large LFAREA with plenty of room for 1MB >pageable pages > > and > > -- if you have software that can truly benefit from it (which we > > don't) -- 2G fixed pages. > > > > > > LFAREA does of course only generally hold fixed large pages, although > > it does also handle overflow of PLAREA when that becomes full, which > > maybe what you were thinking. > > LFAREA (Large Frame Area) provides frame space for both fixed and pageable > large pages. We specify: > > LFAREA=7782M, Large frame area > > which is more than enough for our needs. Right after IPL I see some fairly > small numbers: > > D VS,LFAREA > IAR019I 13.56.52 DISPLAY VIRTSTOR 507 > SOURCE = 20 > TOTAL LFAREA = 7782M , 0G > LFAREA AVAILABLE = 7257M , 0G > LFAREA ALLOCATED (1M) = 0M > LFAREA ALLOCATED (4K) = 311M > MAX LFAREA ALLOCATED (1M) = 0M > MAX LFAREA ALLOCATED (4K) = 311M > LFAREA ALLOCATED (PAGEABLE1M) = 214M > MAX LFAREA ALLOCATED (PAGEABLE1M) = 214M > LFAREA ALLOCATED NUMBER OF 2G PAGES = 0 > MAX LFAREA ALLOCATED NUMBER OF 2G PAGES = 0 > > Of course, these numbers grow over time... > > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Real Storage Allocation
As long as your z/OS isn't running under, z/VM like may smaller ISVs, where LFAREA is not yet supported. John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609 International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Sunday, February 14, 2016 5:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Real Storage Allocation On 2/14/2016 11:19 AM, Graham Harris wrote: > Ed Jaffe wrote: > > >> The nice thing about an overabundance of real storage is the ability >> to > create a very large LFAREA with plenty of room for 1MB >pageable pages > and > -- if you have software that can truly benefit from it (which we > don't) -- 2G fixed pages. > > > LFAREA does of course only generally hold fixed large pages, although > it does also handle overflow of PLAREA when that becomes full, which > maybe what you were thinking. LFAREA (Large Frame Area) provides frame space for both fixed and pageable large pages. We specify: LFAREA=7782M, Large frame area which is more than enough for our needs. Right after IPL I see some fairly small numbers: D VS,LFAREA IAR019I 13.56.52 DISPLAY VIRTSTOR 507 SOURCE = 20 TOTAL LFAREA = 7782M , 0G LFAREA AVAILABLE = 7257M , 0G LFAREA ALLOCATED (1M) = 0M LFAREA ALLOCATED (4K) = 311M MAX LFAREA ALLOCATED (1M) = 0M MAX LFAREA ALLOCATED (4K) = 311M LFAREA ALLOCATED (PAGEABLE1M) = 214M MAX LFAREA ALLOCATED (PAGEABLE1M) = 214M LFAREA ALLOCATED NUMBER OF 2G PAGES = 0 MAX LFAREA ALLOCATED NUMBER OF 2G PAGES = 0 Of course, these numbers grow over time... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Real Storage Allocation
On 2/14/2016 11:19 AM, Graham Harris wrote: Ed Jaffe wrote: The nice thing about an overabundance of real storage is the ability to create a very large LFAREA with plenty of room for 1MB >pageable pages and -- if you have software that can truly benefit from it (which we don't) -- 2G fixed pages. LFAREA does of course only generally hold fixed large pages, although it does also handle overflow of PLAREA when that becomes full, which maybe what you were thinking. LFAREA (Large Frame Area) provides frame space for both fixed and pageable large pages. We specify: LFAREA=7782M, Large frame area which is more than enough for our needs. Right after IPL I see some fairly small numbers: D VS,LFAREA IAR019I 13.56.52 DISPLAY VIRTSTOR 507 SOURCE = 20 TOTAL LFAREA = 7782M , 0G LFAREA AVAILABLE = 7257M , 0G LFAREA ALLOCATED (1M) = 0M LFAREA ALLOCATED (4K) = 311M MAX LFAREA ALLOCATED (1M) = 0M MAX LFAREA ALLOCATED (4K) = 311M LFAREA ALLOCATED (PAGEABLE1M) = 214M MAX LFAREA ALLOCATED (PAGEABLE1M) = 214M LFAREA ALLOCATED NUMBER OF 2G PAGES = 0 MAX LFAREA ALLOCATED NUMBER OF 2G PAGES = 0 Of course, these numbers grow over time... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Real Storage Allocation
Ed Jaffe wrote: >The nice thing about an overabundance of real storage is the ability to create a very large LFAREA with plenty of room for 1MB >pageable pages and -- if you have software that can truly benefit from it (which we don't) -- 2G fixed pages. LFAREA does of course only generally hold fixed large pages, although it does also handle overflow of PLAREA when that becomes full, which maybe what you were thinking. I use SMF71s extensively to trend long term REAL memory use by LPAR, and augment that with LFAREA info from D VS,LFAREA commands (RMF still doesnt provide an equivalent for all the metrics displayed, last time i looked), and PLAREA from a rexx I acquired from the RSM guys (RMF provides little info on that currently). Joining everything together can be quite revealing, especially whats happening inside PLAREA, which is generally hidden from view at the moment, with the current lack of RMF instrumentation, although i am sure will be forthcoming at some point in the future. On 13 February 2016 at 08:30, Martin Packer wrote: > As for monitoring use SMF 71 (RMF Paging Activity) data, most especially > MINIMUM as well as AVERAGE Available Frame Count. Study how they both > behave with time and how the Minimum deviates from the Average. > > That's what Dave Betten and I do in every engagement. And Dave probably > has some choice words on how to manage DFSORT use of memory - which often > accounts for the difference. > > One thing I would say is: Understand how your choices help or hinder your > ability to add memory to LPARs - whether the one it's allocated to or a > different one that subsequently needs it. This, to me, is still not an > exact science. I would argue the instrumentation (again SMF 71) could be > better in this area. > > Cheers, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, > Worldwide Cloud & Systems Performance, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > > > From: "Rugen, Len" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/02/2016 22:40 > Subject:Re: Real Storage Allocation > Sent by:IBM Mainframe Discussion List > > > > I'd say it depends on your workload :-) > > If you are doing I/O that could be avoided with more buffers, it would be > used. Sort might be able to use it, if you sort much. > > I once did amazing things increasing CICS temp storage buffers :-) > > Len Rugen > > University of Missouri > Division of Information Technology > Systems & Operations - Metrics & Automation Team > > ____ > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of phil yogendran [philyo...@gmail.com] > Sent: Friday, February 12, 2016 4:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Real Storage Allocation > > Hello, > > Is there a downside to over-allocating real storage on an LPAR? > > We will be upgrading current processors which are tired and soon to be out > of service to z13's which will have 4 times the storage we have at > present. > > We don't have any issues with paging or UIC etc. but I feel that on the > new > processors, I need to make use of most if not all that available storage. > > Some of my thoughts are; > > - Will the additional storage be used on an LPAR which already has enough > to do it's work. > - Is there a way to monitor for 'unused' storage? > - If the storage is not used, is there a loss of cycles in an 'overhead' > to > managing this unused storage? > - etc. > > Your comments will be appreciated. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Real Storage Allocation
As for monitoring use SMF 71 (RMF Paging Activity) data, most especially MINIMUM as well as AVERAGE Available Frame Count. Study how they both behave with time and how the Minimum deviates from the Average. That's what Dave Betten and I do in every engagement. And Dave probably has some choice words on how to manage DFSORT use of memory - which often accounts for the difference. One thing I would say is: Understand how your choices help or hinder your ability to add memory to LPARs - whether the one it's allocated to or a different one that subsequently needs it. This, to me, is still not an exact science. I would argue the instrumentation (again SMF 71) could be better in this area. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: "Rugen, Len" To: IBM-MAIN@LISTSERV.UA.EDU Date: 12/02/2016 22:40 Subject: Re: Real Storage Allocation Sent by:IBM Mainframe Discussion List I'd say it depends on your workload :-) If you are doing I/O that could be avoided with more buffers, it would be used. Sort might be able to use it, if you sort much. I once did amazing things increasing CICS temp storage buffers :-) Len Rugen University of Missouri Division of Information Technology Systems & Operations - Metrics & Automation Team From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of phil yogendran [philyo...@gmail.com] Sent: Friday, February 12, 2016 4:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Real Storage Allocation Hello, Is there a downside to over-allocating real storage on an LPAR? We will be upgrading current processors which are tired and soon to be out of service to z13's which will have 4 times the storage we have at present. We don't have any issues with paging or UIC etc. but I feel that on the new processors, I need to make use of most if not all that available storage. Some of my thoughts are; - Will the additional storage be used on an LPAR which already has enough to do it's work. - Is there a way to monitor for 'unused' storage? - If the storage is not used, is there a loss of cycles in an 'overhead' to managing this unused storage? - etc. Your comments will be appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Real Storage Allocation
> > Is there a downside to over-allocating real storage on an LPAR? > > Slower stand-alone dump? Seriously, that's the only "downside" I know > of, but I'm not really a performance guy... And larger stand-alone dumps. So remember to review the sizes of your stand-alone dump output data sets. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Real Storage Allocation
On 2/12/2016 2:07 PM, phil yogendran wrote: Hello, Is there a downside to over-allocating real storage on an LPAR? Slower stand-alone dump? Seriously, that's the only "downside" I know of, but I'm not really a performance guy... We will be upgrading current processors which are tired and soon to be out of service to z13's which will have 4 times the storage we have at present. We don't have any issues with paging or UIC etc. but I feel that on the new processors, I need to make use of most if not all that available storage. We took exactly the same approach on our z13. It's been great! The nice thing about an overabundance of real storage is the ability to create a very large LFAREA with plenty of room for 1MB pageable pages and -- if you have software that can truly benefit from it (which we don't) -- 2G fixed pages. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Real Storage Allocation
I'd say it depends on your workload :-) If you are doing I/O that could be avoided with more buffers, it would be used. Sort might be able to use it, if you sort much. I once did amazing things increasing CICS temp storage buffers :-) Len Rugen University of Missouri Division of Information Technology Systems & Operations - Metrics & Automation Team From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of phil yogendran [philyo...@gmail.com] Sent: Friday, February 12, 2016 4:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Real Storage Allocation Hello, Is there a downside to over-allocating real storage on an LPAR? We will be upgrading current processors which are tired and soon to be out of service to z13's which will have 4 times the storage we have at present. We don't have any issues with paging or UIC etc. but I feel that on the new processors, I need to make use of most if not all that available storage. Some of my thoughts are; - Will the additional storage be used on an LPAR which already has enough to do it's work. - Is there a way to monitor for 'unused' storage? - If the storage is not used, is there a loss of cycles in an 'overhead' to managing this unused storage? - etc. Your comments will be appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Real Storage Allocation
Hello, Is there a downside to over-allocating real storage on an LPAR? We will be upgrading current processors which are tired and soon to be out of service to z13's which will have 4 times the storage we have at present. We don't have any issues with paging or UIC etc. but I feel that on the new processors, I need to make use of most if not all that available storage. Some of my thoughts are; - Will the additional storage be used on an LPAR which already has enough to do it's work. - Is there a way to monitor for 'unused' storage? - If the storage is not used, is there a loss of cycles in an 'overhead' to managing this unused storage? - etc. Your comments will be appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
