Re: Question re: MXG-L post "common storage usage question"
Peter Hunkeler wrote: >> Wasn't this asked here recently? Check the archives. >Sorry, I missed that one. My excuse is: Been on holiday :-)-- But does that discussion started by Rex Pommier relates to that two APARs? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question re: MXG-L post "common storage usage question"
> Wasn't this asked here recently? Check the archives. Sorry, I missed that one. My excuse is: Been on holiday :-)-- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question re: MXG-L post "common storage usage question"
On Mon, 10 Jul 2017 14:43:00 +0200, Peter Hunkeler wrote: >Below text was posted on MXG-L recently. It made me curious, so I tired >to read the APARs mentioned. Unfortunately, IBM's support site does not >have them (for public access) anymore. >Can someone shed some light on this? What was the original problem? >Why did it increase CPU time for many STCs *over time*? What path >length was increased. Just curious. Wasn't this asked here recently? Check the archives. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question re: MXG-L post "common storage usage question"
Peter Hunkeler wrote: >Below text was posted on MXG-L recently. It made me curious, so I tired (sic) >to read the APARs mentioned. Unfortunately, IBM's support site does not have >them (for public access) anymore. Can someone shed some light on this? What >was the original problem? Why did it increase CPU time for many STCs *over >time*? What path length was increased. I looked around in IBM 'My Support' pages, and find this snippet from z/OS Parallel Sysplex Configuration Overview (SG24-6485-00) I see this: "Note: The WLM service that added dynamic application environments is a prerequisite for WebSphere Application Server for z/OS Version 6.0.1. See SPE (APAR OW54622, included in z/OS Version 1.5 and above), which is described at: http://www-1.ibm.com/support/docview.wss?uid=isg1OW54622"; I just get a 'Our apologies...' statement. I see other references, but they are about WebSphere which requires that WLM APAR, like thise RedBook 'Problem Avoidance for WebSphere Application Server for z/OS.' (First Edition (March 2006)) It states: "The dynamic WLM application environment is a function of WLM that became available when APAR OW54622 was made available for Workload Manager. It is incorporated into z/OS Version 1.5 and later. With the new WLM function, programs can dynamically create application environments on the fly." Sorry, Nothing more information. Perhaps you need a formal request to IBM? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question re: MXG-L post "common storage usage question"
Below text was posted on MXG-L recently. It made me curious, so I tired to read the APARs mentioned. Unfortunately, IBM's support site does not have them (for public access) anymore. Can someone shed some light on this? What was the original problem? Why did it increase CPU time for many STCs *over time*? What path length was increased. Just curious. Peter Posted on MXG-L My 2003 Newsletter has this note: 29. APAR OW54622 introduced an SQA overflow into CSA condition that increased CPU time for many STCs over time; the new GETMAIN larger than FREEMAIN was corrected by APAR OW55360. It has long been known that when SQA is too small and expands into the CSA area, path lengths are dramatically increased; you can detect this condition in MXG dataset TYPE78VS variables SQAEXPNx. Unfortunately, I do NOT know if that statement with regard to increased CPU time due to path length when there is an overflow is still true, and I can't find the "long known" source. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: common storage usage question
For an SQA request which needs to convert some multiple of 4K pages from CSA to SQA, the path length is longer. As to the question of whether or not it is dramatic, the answer is the same as for most performance questions - "it depends". One could construct an artificial workload where the SQA 4k multiple free page space is not fragmented, and the CSA multiple 4k page free space is highly fragmented, and then be doing a lot SQA getmains for a size which requires a long CSA search, and produce a measurable (even dramatic, for some definition of dramatic) performance effect. For a particular customer's workload, the only way to tell whether or not there is a measurable difference is to measure it both ways. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List wrote on 06/26/2017 07:24:37 AM: > From: Barry Merrill > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 06/26/2017 03:38 PM > Subject: FW: common storage usage question > Sent by: IBM Mainframe Discussion List > > My 2003 Newsletter has this note: > > 29. APAR OW54622 introduced an SQA overflow into CSA condition that > increased CPU time for many STCs over time; the new GETMAIN larger > than FREEMAIN was corrected by APAR OW55360. It has long been known > that when SQA is too small and expands into the CSA area, path > lengths are dramatically increased; you can detect this condition in > MXG dataset TYPE78VS variables SQAEXPNx. > > > Unfortunately, I do NOT know if that statement with regard to increased > CPU time due to path length when there is an overflow is still true, and > I can't find the "long known" source. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: common storage usage question
My 2003 Newsletter has this note: 29. APAR OW54622 introduced an SQA overflow into CSA condition that increased CPU time for many STCs over time; the new GETMAIN larger than FREEMAIN was corrected by APAR OW55360. It has long been known that when SQA is too small and expands into the CSA area, path lengths are dramatically increased; you can detect this condition in MXG dataset TYPE78VS variables SQAEXPNx. Unfortunately, I do NOT know if that statement with regard to increased CPU time due to path length when there is an overflow is still true, and I can't find the "long known" source. Barry Merrilly yours, Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive technical questions: supp...@mxg.com Dallas, TX 75229 http://www.mxg.comadmin questions: ad...@mxg.com tel: 214 351 1966 fax: 214 350 3694 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Monday, June 26, 2017 4:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: common storage usage question > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Pommier, Rex > Sent: 20 June, 2017 16:12 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: common storage usage question > > Hi all, > > Curiosity question. Due to some storage issues we've had recently > with old 24 bit programs, I am revisiting our common storage > configuration - CSA and SQA. Taking fragmentation into account, it > appears that I'm using about 38% of my allocated SQA and about 46% of my > allocated CSA. > So I'm wondering if anybody has a good feel as to what a "good" > percentage of used versus allocated space for these areas is. How low > can I safely go in free space in these areas if we decide we want to > try to eke out an additional MB of below-the-line private? Our > current private size is 11MB. > > TIA, > > Rex > > The information contained in this message is confidential, protected > from disclosure and may be legally privileged. If the reader of this > message is not the intended recipient or an employee or agent > responsible for delivering this message to the intended recipient, you > are hereby notified that any disclosure, distribution, copying, or any > action taken or action omitted in reliance on it, is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by replying to > this message and destroy the material in its entirety, whether in electronic > or hard copy format. > Thank you. > > - Usually I check the peaks of the last 6 or 12 months and consider those good guidelines, if you don't plan upgrades that might change the picture. - You can cut SQA to near 100% usage, because it can overflow to CSA, so you don't only need 1 free space area. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: common storage usage question
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pommier, Rex > Sent: 20 June, 2017 16:12 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: common storage usage question > > Hi all, > > Curiosity question. Due to some storage issues we've had recently with > old 24 bit programs, I am revisiting our common storage configuration - > CSA and SQA. Taking fragmentation into account, it appears that I'm > using about 38% of my allocated SQA and about 46% of my allocated CSA. > So I'm wondering if anybody has a good feel as to what a "good" > percentage of used versus allocated space for these areas is. How low > can I safely go in free space in these areas if we decide we want to try > to eke out an additional MB of below-the-line private? Our current > private size is 11MB. > > TIA, > > Rex > > The information contained in this message is confidential, protected > from disclosure and may be legally privileged. If the reader of this > message is not the intended recipient or an employee or agent > responsible for delivering this message to the intended recipient, you > are hereby notified that any disclosure, distribution, copying, or any > action taken or action omitted in reliance on it, is strictly prohibited > and may be unlawful. If you have received this communication in error, > please notify us immediately by replying to this message and destroy the > material in its entirety, whether in electronic or hard copy format. > Thank you. > > - Usually I check the peaks of the last 6 or 12 months and consider those good guidelines, if you don't plan upgrades that might change the picture. - You can cut SQA to near 100% usage, because it can overflow to CSA, so you don't only need 1 free space area. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: common storage usage question
> On Jun 20, 2017, at 3:37 PM, Ed Jaffe wrote: > > On 6/20/2017 8:24 AM, Jesse 1 Robinson wrote: >> SWA is another candidate, but don't just move it up across the board without >> some testing. Above the line can cause problems there. > > Of course SWA is private, not common... Good heavens, is this still an issue with vendors??? It was new in the 1990’s and I tested each vendor and some came up short. I remembered delaying an upgrade due top one vendors recalcitant attempts to fix it. I finely found the part is CA code and fixed its myself. This had to be 25+ years ago.I think Compuware did it but only after I asked pretty please. Another strike against COMUWARE. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: common storage usage question
On 6/20/2017 8:24 AM, Jesse 1 Robinson wrote: SWA is another candidate, but don't just move it up across the board without some testing. Above the line can cause problems there. Of course SWA is private, not common... -- 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: common storage usage question
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Tuesday, June 20, 2017 12:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: common storage usage question On Tue, 20 Jun 2017 14:11:39 +, Pommier, Rex wrote: >Hi all, > >Curiosity question. Due to some storage issues we've had recently with >old 24 bit programs, I am revisiting our common storage configuration - >CSA and SQA. Taking fragmentation into account, it appears that I'm >using about 38% of my allocated SQA and about 46% of my allocated CSA. >So I'm wondering if anybody has a good feel as to what a "good" >percentage of used versus allocated space for these areas is. >How low can I safely go in free space in these areas if we decide we >want to try to eke out an additional MB of below-the-line private? Our >current private size is 11MB. I'll turn your question around, and maybe it will help you decide. Assuming that you are not able to get below the line relief by moving UCBs or anything else, remember that you can only change CSA+SQA in increments of 1MB. If you reduce CSA+SQA by 1MB, how much room does that leave you for CSA/SQA growth? What if you reduce it by 2MB? Is that even possible? -- Tom Marchant Hi Tom, Good questions. Based on my back-of-the-napkin calculations with help from RMF PP for the past 2 months, even with accounting for the fragmentation, both CSA and SQA should be sitting around 70% used if I drop the numbers to get another MB. No way will I be able to reduce it another 2 MB. All my UCBs except my consoles and CTC are above the line. Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: common storage usage question
On Tue, 20 Jun 2017 14:11:39 +, Pommier, Rex wrote: >Hi all, > >Curiosity question. Due to some storage issues we've had >recently with old 24 bit programs, I am revisiting our common >storage configuration - CSA and SQA. Taking fragmentation >into account, it appears that I'm using about 38% of my >allocated SQA and about 46% of my allocated CSA. So I'm >wondering if anybody has a good feel as to what a "good" >percentage of used versus allocated space for these areas is. >How low can I safely go in free space in these areas if we >decide we want to try to eke out an additional MB of >below-the-line private? Our current private size is 11MB. I'll turn your question around, and maybe it will help you decide. Assuming that you are not able to get below the line relief by moving UCBs or anything else, remember that you can only change CSA+SQA in increments of 1MB. If you reduce CSA+SQA by 1MB, how much room does that leave you for CSA/SQA growth? What if you reduce it by 2MB? Is that even possible? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: common storage usage question
SWA is another candidate, but don't just move it up across the board without some testing. Above the line can cause problems there. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roach, Dennis Sent: Tuesday, June 20, 2017 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: common storage usage question Things to consider SQA can expand into CSA but not the other way around. You need enough SQA to get up and running. I would have no issue with trying half of the existing SQA CSA has become pretty stable, with most of the growth in ECSA. With this in mind, I would feel comfortable reducing CSA by as much as 25% to start. Have you moved UCBs above the line? Look at other MVS areas that are optionally movable. Dennis Roach, CISSP, PMP AIG IAM Platform Administration | Identity & Access Management 2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019 Phone: 713-831-8799 dennis.ro...@aig.com | www.aig.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Tuesday, June 20, 2017 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: common storage usage question Hi all, Curiosity question. Due to some storage issues we've had recently with old 24 bit programs, I am revisiting our common storage configuration - CSA and SQA. Taking fragmentation into account, it appears that I'm using about 38% of my allocated SQA and about 46% of my allocated CSA. So I'm wondering if anybody has a good feel as to what a "good" percentage of used versus allocated space for these areas is. How low can I safely go in free space in these areas if we decide we want to try to eke out an additional MB of below-the-line private? Our current private size is 11MB. TIA, Rex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: common storage usage question
Things to consider SQA can expand into CSA but not the other way around. You need enough SQA to get up and running. I would have no issue with trying half of the existing SQA CSA has become pretty stable, with most of the growth in ECSA. With this in mind, I would feel comfortable reducing CSA by as much as 25% to start. Have you moved UCBs above the line? Look at other MVS areas that are optionally movable. Dennis Roach, CISSP, PMP AIG IAM Platform Administration | Identity & Access Management 2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019 Phone: 713-831-8799 dennis.ro...@aig.com | www.aig.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Tuesday, June 20, 2017 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: common storage usage question Hi all, Curiosity question. Due to some storage issues we've had recently with old 24 bit programs, I am revisiting our common storage configuration - CSA and SQA. Taking fragmentation into account, it appears that I'm using about 38% of my allocated SQA and about 46% of my allocated CSA. So I'm wondering if anybody has a good feel as to what a "good" percentage of used versus allocated space for these areas is. How low can I safely go in free space in these areas if we decide we want to try to eke out an additional MB of below-the-line private? Our current private size is 11MB. TIA, Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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
common storage usage question
Hi all, Curiosity question. Due to some storage issues we've had recently with old 24 bit programs, I am revisiting our common storage configuration - CSA and SQA. Taking fragmentation into account, it appears that I'm using about 38% of my allocated SQA and about 46% of my allocated CSA. So I'm wondering if anybody has a good feel as to what a "good" percentage of used versus allocated space for these areas is. How low can I safely go in free space in these areas if we decide we want to try to eke out an additional MB of below-the-line private? Our current private size is 11MB. TIA, Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
