Re: Question re: MXG-L post "common storage usage question"

[Elardus Engelbrecht]

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"

[Peter Hunkeler]

> 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"

[Tom Marchant]

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"

[Elardus Engelbrecht]

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"

[Peter Hunkeler]

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

[Jim Mulder]

 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 <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
06/26/2017 07:24:37 AM:

> From: Barry Merrill <ba...@mxg.com>
> 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 <IBM-MAIN@LISTSERV.UA.EDU>
> 
> 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

[Barry Merrill]

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

[Vernooij, Kees (ITOPT1) - KLM]

> -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

[Edward Gould]

> 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

[Ed Jaffe]

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

[Tom Marchant]

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

[Jesse 1 Robinson]

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

[Roach, Dennis]

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

[Pommier, Rex]

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