Discussion:
REGION=0M leads to CPU through the roof
(too old to reply)
Way, Richard
2017-07-24 20:17:25 UTC
Permalink
Raw Message
In the course of trying to duplicate a customer problem, I have run across unexpected behavior that I wonder if anyone can help to explain.

I have an application program (COBOL 4.2, z/OS 2.2, AMODE 31, RENT) that exhibits the following:

When run with our *default* REGION (i.e. no REGION= on the EXEC whatsoever):

CPU: 0 HR 00 MIN 31.34 SEC SRB: 0 HR 00 MIN 00.06 SEC
VIRT: 1056K SYS: 276K EXT: 32740K SYS: 13116K
ATB- REAL: 8K SLOTS: 0K
VIRT- ALLOC: 10M SHRD: 0M

When run with an explicit REGION=0M:

CPU: 0 HR 11 MIN 38.43 SEC SRB: 0 HR 00 MIN 00.07 SEC
VIRT: 7856K SYS: 276K EXT: 1622548K SYS: 13116K
ATB- REAL: 8K SLOTS: 0K
VIRT- ALLOC: 10M SHRD: 0M

You'll note the large increase in storage - which is of course not surprising - but more interesting (and unwelcome) to me is that the CPU time required increased by roughly a factor of 22X to do the exact same work. (The ONLY difference between the two runs is the addition of REGION=0M to the EXEC.)

Can anyone suggest what I should be thinking about here in terms of possible causes? Is it possible that so much "overhead" is needed to manage the much larger memory space? Could it be something to do with LE tuning?

Thanks,

Richard Way
HPE Security - Data Security
HPE Software | Enterprise Security Products

+1 408 857 0216 Mobile

1140 Enterprise Way, Mail Stop 3048
Sunnyvale, CA 94089

[HPE logo]<http://www.hpe.com/>


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-07-24 20:56:37 UTC
Permalink
Raw Message
Your installation may have an IEFUSI exit that turns REGION=0M into a much smaller value, perhaps even smaller than the default with no REGION specified at all.

Less virtual storage allocated may lead to less I/O buffering and more I/O CPU time or even more LE storage use/free issues? Just guessing here.

IMHO your best bet is to run the REGION=0M version with an application tuning product (Strobe, TriTune, etc., I think IBM even has one) and see where the actual CPU hot spots are.

HTH

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Monday, July 24, 2017 4:19 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: REGION=0M leads to CPU through the roof

In the course of trying to duplicate a customer problem, I have run across unexpected behavior that I wonder if anyone can help to explain.

I have an application program (COBOL 4.2, z/OS 2.2, AMODE 31, RENT) that exhibits the following:

When run with our *default* REGION (i.e. no REGION= on the EXEC whatsoever):

CPU: 0 HR 00 MIN 31.34 SEC SRB: 0 HR 00 MIN 00.06 SEC
VIRT: 1056K SYS: 276K EXT: 32740K SYS: 13116K
ATB- REAL: 8K SLOTS: 0K
VIRT- ALLOC: 10M SHRD: 0M

When run with an explicit REGION=0M:

CPU: 0 HR 11 MIN 38.43 SEC SRB: 0 HR 00 MIN 00.07 SEC
VIRT: 7856K SYS: 276K EXT: 1622548K SYS: 13116K
ATB- REAL: 8K SLOTS: 0K
VIRT- ALLOC: 10M SHRD: 0M

You'll note the large increase in storage - which is of course not surprising - but more interesting (and unwelcome) to me is that the CPU time required increased by roughly a factor of 22X to do the exact same work. (The ONLY difference between the two runs is the addition of REGION=0M to the EXEC.)

Can anyone suggest what I should be thinking about here in terms of possible causes? Is it possible that so much "overhead" is needed to manage the much larger memory space? Could it be something to do with LE tuning?

Thanks,

Richard Way
--

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Barry Merrill
2017-07-24 21:06:33 UTC
Permalink
Raw Message
The EXT value in the message for the "no region" shows a 32MB Limit
was enforced, the REGION=0 execution shows no such limit.

Barry


Merrilly yours,

Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive technical questions: ***@mxg.com
Dallas, TX 75229
http://www.mxg.com admin questions: ***@mxg.com
tel: 214 351 1966
fax: 214 350 3694



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Monday, July 24, 2017 3:58 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Your installation may have an IEFUSI exit that turns REGION=0M into a much
smaller value, perhaps even smaller than the default with no REGION
specified at all.

Less virtual storage allocated may lead to less I/O buffering and more I/O
CPU time or even more LE storage use/free issues? Just guessing here.

IMHO your best bet is to run the REGION=0M version with an application
tuning product (Strobe, TriTune, etc., I think IBM even has one) and see
where the actual CPU hot spots are.

HTH

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Way, Richard
Sent: Monday, July 24, 2017 4:19 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: REGION=0M leads to CPU through the roof

In the course of trying to duplicate a customer problem, I have run across
unexpected behavior that I wonder if anyone can help to explain.

I have an application program (COBOL 4.2, z/OS 2.2, AMODE 31, RENT) that
exhibits the following:

When run with our *default* REGION (i.e. no REGION= on the EXEC whatsoever):

CPU: 0 HR 00 MIN 31.34 SEC SRB: 0 HR 00 MIN 00.06 SEC
VIRT: 1056K SYS: 276K EXT: 32740K SYS: 13116K
ATB- REAL: 8K SLOTS: 0K
VIRT- ALLOC: 10M SHRD: 0M

When run with an explicit REGION=0M:

CPU: 0 HR 11 MIN 38.43 SEC SRB: 0 HR 00 MIN 00.07 SEC
VIRT: 7856K SYS: 276K EXT: 1622548K SYS: 13116K
ATB- REAL: 8K SLOTS: 0K
VIRT- ALLOC: 10M SHRD: 0M

You'll note the large increase in storage - which is of course not
surprising - but more interesting (and unwelcome) to me is that the CPU time
required increased by roughly a factor of 22X to do the exact same work.
(The ONLY difference between the two runs is the addition of REGION=0M to
the EXEC.)

Can anyone suggest what I should be thinking about here in terms of possible
causes? Is it possible that so much "overhead" is needed to manage the much
larger memory space? Could it be something to do with LE tuning?

Thanks,

Richard Way
--

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Allan Kielstra
2017-07-24 21:25:43 UTC
Permalink
Raw Message
I want to be clear on one thing....The program produces the same result and has the same return code in both cases? Possibly another way of asking the same thing is: why did you alter the region size in the first place?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-07-24 21:31:19 UTC
Permalink
Raw Message
Same result, same return code - yes. Customer found that one release of our product got an 878 when a prior release had not. I was experimenting to see if I could drive the 878 by finding the point (REGION=xxxx) at which the 878 first occurs in the two releases of our product (to see if it was just "normal" additional memory needs or something more sinister). As it turned out, I got this other behavior (wild CPU consumption) in the course of experimentation.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra
Sent: Monday, July 24, 2017 2:27 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

I want to be clear on one thing....The program produces the same result and has the same return code in both cases? Possibly another way of asking the same thing is: why did you alter the region size in the first place?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Kirk Wolf
2017-07-24 21:43:29 UTC
Permalink
Raw Message
Running both with RPTSTG(ON) may provide insight.
See also: http://www-01.ibm.com/support/docview.wss?uid=swg27018287&aid=1

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Post by Way, Richard
Same result, same return code - yes. Customer found that one release of
our product got an 878 when a prior release had not. I was experimenting
to see if I could drive the 878 by finding the point (REGION=xxxx) at which
the 878 first occurs in the two releases of our product (to see if it was
just "normal" additional memory needs or something more sinister). As it
turned out, I got this other behavior (wild CPU consumption) in the course
of experimentation.
-----Original Message-----
Behalf Of Allan Kielstra
Sent: Monday, July 24, 2017 2:27 PM
Subject: Re: REGION=0M leads to CPU through the roof
I want to be clear on one thing....The program produces the same result
and has the same return code in both cases? Possibly another way of asking
the same thing is: why did you alter the region size in the first place?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-07-24 21:49:07 UTC
Permalink
Raw Message
Thanks! I'm a little reluctant to run a job that already takes 12 CPU-minutes with RPTSTG(ON), but I may be able to cut the test data back significantly and still see the relative increase, in which case this may be very useful. I'll read through that tuning document as well!



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf
Sent: Monday, July 24, 2017 2:45 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Running both with RPTSTG(ON) may provide insight.
See also: http://www-01.ibm.com/support/docview.wss?uid=swg27018287&aid=1

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Post by Way, Richard
Same result, same return code - yes. Customer found that one release of
our product got an 878 when a prior release had not. I was
experimenting to see if I could drive the 878 by finding the point
(REGION=xxxx) at which the 878 first occurs in the two releases of our
product (to see if it was just "normal" additional memory needs or
something more sinister). As it turned out, I got this other behavior
(wild CPU consumption) in the course of experimentation.
-----Original Message-----
On Behalf Of Allan Kielstra
Sent: Monday, July 24, 2017 2:27 PM
Subject: Re: REGION=0M leads to CPU through the roof
I want to be clear on one thing....The program produces the same
result and has the same return code in both cases? Possibly another
way of asking the same thing is: why did you alter the region size in the first place?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-07-24 21:58:50 UTC
Permalink
Raw Message
On Mon, 24 Jul 2017 21:49:43 +0000, Way, Richard (***@HPE.COM)
wrote about "Re: REGION=0M leads to CPU through the roof" (in
Post by Way, Richard
Thanks! I'm a little reluctant to run a job that already takes 12
CPU-minutes with RPTSTG(ON), but I may be able to cut the test data
back significantly and still see the relative increase, in which case
this may be very useful. I'll read through that tuning document as well!
When you are fiddling with the LE parameters, you might also constrain
the stack and heap sizes. Your excess CPU time could well be the LE
memory management routines having to manage excessive amounts of virtual
storage, and limiting the stack and/or heap could save much CPU.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-07-24 22:18:50 UTC
Permalink
Raw Message
ELEVEN MINUTES of CPU time to manage the stack and heap???

Something is very wrong here. It's either a flaw in the measurement process or something is very wrong in LE, MVS, etc. If it is eleven minutes of heap management then I would say that is a PMRable problem.

I would be checking my work -- the measurement process -- and then reporting the problem to IBM.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David W Noon
Sent: Monday, July 24, 2017 3:00 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof
Post by Way, Richard
Thanks! I'm a little reluctant to run a job that already takes 12
CPU-minutes with RPTSTG(ON), but I may be able to cut the test data
back significantly and still see the relative increase, in which case
this may be very useful. I'll read through that tuning document as well!
When you are fiddling with the LE parameters, you might also constrain the stack and heap sizes. Your excess CPU time could well be the LE memory management routines having to manage excessive amounts of virtual storage, and limiting the stack and/or heap could save much CPU.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-07-24 22:24:14 UTC
Permalink
Raw Message
There's no "measurement process" per se - I'm reporting the data as indicated directly from the job log.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Monday, July 24, 2017 3:20 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

ELEVEN MINUTES of CPU time to manage the stack and heap???

Something is very wrong here. It's either a flaw in the measurement process or something is very wrong in LE, MVS, etc. If it is eleven minutes of heap management then I would say that is a PMRable problem.

I would be checking my work -- the measurement process -- and then reporting the problem to IBM.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David W Noon
Sent: Monday, July 24, 2017 3:00 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof
Post by Way, Richard
Thanks! I'm a little reluctant to run a job that already takes 12
CPU-minutes with RPTSTG(ON), but I may be able to cut the test data
back significantly and still see the relative increase, in which case
this may be very useful. I'll read through that tuning document as well!
When you are fiddling with the LE parameters, you might also constrain the stack and heap sizes. Your excess CPU time could well be the LE memory management routines having to manage excessive amounts of virtual storage, and limiting the stack and/or heap could save much CPU.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-07-24 23:04:07 UTC
Permalink
Raw Message
On Mon, 24 Jul 2017 15:20:01 -0700, Charles Mills (***@MCN.ORG)
wrote about "Re: REGION=0M leads to CPU through the roof" (in
Post by Charles Mills
ELEVEN MINUTES of CPU time to manage the stack and heap???
It can happen when memory is in a lot of fragments.
Post by Charles Mills
Something is very wrong here. It's either a flaw in the measurement
process or something is very wrong in LE, MVS, etc. If it is eleven
minutes of heap management then I would say that is a PMRable problem.
Indeed.

But if the memory is being referenced (i.e. committed) when the memory
management routines a trying to consolidate fragments, there could also
be a lot of paging -- and paging really slows things down.
Post by Charles Mills
I would be checking my work -- the measurement process -- and then
reporting the problem to IBM.
"Doctor, it hurts when I do this!"
"Well don't do that."

:-)
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gerhard Adam
2017-07-24 22:08:40 UTC
Permalink
Raw Message
How much did the elapsed time change? I find it hard to believe that the job actually ran 22 x longer and that wasn't notable as a difference.

Adam

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Monday, July 24, 2017 2:50 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Thanks! I'm a little reluctant to run a job that already takes 12 CPU-minutes with RPTSTG(ON), but I may be able to cut the test data back significantly and still see the relative increase, in which case this may be very useful. I'll read through that tuning document as well!



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf
Sent: Monday, July 24, 2017 2:45 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Running both with RPTSTG(ON) may provide insight.
See also: http://www-01.ibm.com/support/docview.wss?uid=swg27018287&aid=1

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Post by Way, Richard
Same result, same return code - yes. Customer found that one release of
our product got an 878 when a prior release had not. I was
experimenting to see if I could drive the 878 by finding the point
(REGION=xxxx) at which the 878 first occurs in the two releases of our
product (to see if it was just "normal" additional memory needs or
something more sinister). As it turned out, I got this other behavior
(wild CPU consumption) in the course of experimentation.
-----Original Message-----
On Behalf Of Allan Kielstra
Sent: Monday, July 24, 2017 2:27 PM
Subject: Re: REGION=0M leads to CPU through the roof
I want to be clear on one thing....The program produces the same
result and has the same return code in both cases? Possibly another
way of asking the same thing is: why did you alter the region size in the first place?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-07-24 22:11:17 UTC
Permalink
Raw Message
Oh, the elapsed time absolutely changed in a very noticeable way, of course. 12.55 minutes with REGION=0M, 0.60 minutes without any REGION specified. This is (more-or-less) repeatable at will. But the work being done (number of records read, processed, written, and the nature of the processing) was identical in both cases.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam
Sent: Monday, July 24, 2017 3:10 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

How much did the elapsed time change? I find it hard to believe that the job actually ran 22 x longer and that wasn't notable as a difference.

Adam

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Monday, July 24, 2017 2:50 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Thanks! I'm a little reluctant to run a job that already takes 12 CPU-minutes with RPTSTG(ON), but I may be able to cut the test data back significantly and still see the relative increase, in which case this may be very useful. I'll read through that tuning document as well!



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf
Sent: Monday, July 24, 2017 2:45 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Running both with RPTSTG(ON) may provide insight.
See also: http://www-01.ibm.com/support/docview.wss?uid=swg27018287&aid=1

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Post by Way, Richard
Same result, same return code - yes. Customer found that one release of
our product got an 878 when a prior release had not. I was
experimenting to see if I could drive the 878 by finding the point
(REGION=xxxx) at which the 878 first occurs in the two releases of our
product (to see if it was just "normal" additional memory needs or
something more sinister). As it turned out, I got this other behavior
(wild CPU consumption) in the course of experimentation.
-----Original Message-----
On Behalf Of Allan Kielstra
Sent: Monday, July 24, 2017 2:27 PM
Subject: Re: REGION=0M leads to CPU through the roof
I want to be clear on one thing....The program produces the same
result and has the same return code in both cases? Possibly another
way of asking the same thing is: why did you alter the region size in the first place?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Allan Kielstra
2017-07-24 22:26:50 UTC
Permalink
Raw Message
Do you have access to Application Performance Analyzer (APA) or Strobe (or FreezeFrame)? If not, can you cut the program down to some kernel that exhibits the same characteristic?

Also, do you happen to have COBOL V5 or V6 (maybe the trial version)?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gerhard Adam
2017-07-24 22:32:48 UTC
Permalink
Raw Message
What's strange to me, is that the program used up all the available storage indicated by coding REGION=0M. This clearly means that the program is dynamically adjusting the amount of storage that it needs based on the available region. After all, if it were of fixed size, then coding 0M wouldn't have any effect on what was going used.

Since the amount of storage was nearly 50 times greater than the original, it seems that the program is clearly managing [or searching] are large amount of storage that it doesn't need. It seems that that might account for the CPU time increase.

I see no reason why a program that successfully ran using the default region, should suddenly allocate all the available memory just because 0M was coded.

Even though you said the increase in storage was not surprising, it actually is.

Adam

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra
Sent: Monday, July 24, 2017 3:28 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Do you have access to Application Performance Analyzer (APA) or Strobe (or FreezeFrame)? If not, can you cut the program down to some kernel that exhibits the same characteristic?

Also, do you happen to have COBOL V5 or V6 (maybe the trial version)?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-07-24 23:41:25 UTC
Permalink
Raw Message
Post by Charles Mills
ELEVEN MINUTES of CPU time to manage the stack and heap???
Something is very wrong here. It's either a flaw in the measurement process or something is very wrong in LE, MVS, etc. If it is eleven minutes of heap management then I would say that is a PMRable problem.
Could it be that garbage collection is cheaper than paging? I once used a product that
tried to compare paging with garbage collection dynamically and use the optimum
tradeoff point.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-07-25 13:39:15 UTC
Permalink
Raw Message
Post by Gerhard Adam
Since the amount of storage was nearly 50 times greater than the original, it seems that the program is clearly managing [or searching] are large amount of storage that it doesn't need. It seems that that might account for the CPU time increase.
I see no reason why a program that successfully ran using the default region, should suddenly allocate all the available memory just because 0M was coded.
Even though you said the increase in storage was not surprising, it actually is.
I agree. Increasing the region doesn't ordinarily increase the storage utilization.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Denis
2017-07-25 13:43:08 UTC
Permalink
Raw Message
I have seen that happening with JVMs in regions, e.g. comparing 384M and 512M and 0M.
So if you don't find any logic in the COBOL source that does its own allocation, its very likely the runtime.

dg.

-----Original Message-----
From: Tom Marchant <0000000a2a8c2020-dmarc-***@LISTSERV.UA.EDU>
To: IBM-MAIN <IBM-***@LISTSERV.UA.EDU>
Sent: Tue, Jul 25, 2017 3:40 pm
Subject: Re: REGION=0M leads to CPU through the roof
Post by Gerhard Adam
Since the amount of storage was nearly 50 times greater than the original, it seems that the program is clearly managing [or searching] are large amount of storage that it doesn't need. It seems that that might account for the CPU time increase.
I see no reason why a program that successfully ran using the default region, should suddenly allocate all the available memory just because 0M was coded.
Even though you said the increase in storage was not surprising, it actually is.
I agree. Increasing the region doesn't ordinarily increase the storage utilization.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2017-07-25 13:52:10 UTC
Permalink
Raw Message
Post by Farley, Peter x23353
-----Original Message-----
Behalf Of Tom Marchant
Sent: 25 July, 2017 15:40
Subject: Re: REGION=0M leads to CPU through the roof
Post by Gerhard Adam
Since the amount of storage was nearly 50 times greater than the
original, it seems that the program is clearly managing [or searching]
are large amount of storage that it doesn't need. It seems that that
might account for the CPU time increase.
Post by Gerhard Adam
I see no reason why a program that successfully ran using the default
region, should suddenly allocate all the available memory just because
0M was coded.
Post by Gerhard Adam
Even though you said the increase in storage was not surprising, it
actually is.
I agree. Increasing the region doesn't ordinarily increase the storage utilization.
--
Tom Marchant
Ordinarily/usually not, but it can effect VL Getmains. If an application does an unlimited VL Getmain and is then unable to handle (the huge amount) what it received, this problem might be the result.

I am testing SMFLIMxx and planning to make regionsizes Unlimited, hoping to help applications a little. So I am very interested in what mal-coded software might hang around.

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-07-25 15:56:05 UTC
Permalink
Raw Message
On Tue, 25 Jul 2017 08:40:25 -0500, Tom Marchant
(0000000a2a8c2020-dmarc-***@LISTSERV.UA.EDU) wrote about "Re:
REGION=0M leads to CPU through the roof" (in
<***@listserv.ua.edu>):

[snip]
Post by Tom Marchant
I agree. Increasing the region doesn't ordinarily increase the storage utilization.
As a PL/I programmer of more than 40 years, I am sufficiently familiar
with IBM's run-time libraries to offer a contrary experience. The
start-up code for the old PL/I OS Optimizing compiler would check the
VSM parameters and GETMAIN 50% of the remaining storage in the
region/partition. [I wrote "partition" because this goes back to the
OS/VS1 days.] The upshot was that the bigger the region one coded in the
JCL the more memory the RTL would acquire at start-up time -- and would
hold for the duration of the job step. It could acquire still more if
the program needed it.

One could override this by coding a PLIXOPT string in the OPTIONS(MAIN)
procedure or by putting similar options in the PARM field of the JCL.

Since LE is largely analogous to the old PL/I RTL, I would bet dollars
to doughnuts that it will do something similar if allowed. Coding memory
constraints in the RTL options can work wonders.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-07-25 16:27:59 UTC
Permalink
Raw Message
Not a huge expert but I do a certain amount of tuning of storage requirements as the developer of a vendor product, and I have the distinct impression that LE's initial program runtime storage parameters are fixed at either compile or startup time and based on supplied parameters, independent of the actual region size. That is, there is no algorithm like "get half the free storage." It is "get X bytes."

Of course, region size affects the possibility of an x78 failure if the program requires more storage than initially obtained.

I notice the OP, who was posting hourly or so, has gone quiet. Perhaps the problem has been located.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David W Noon
Sent: Tuesday, July 25, 2017 8:57 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

On Tue, 25 Jul 2017 08:40:25 -0500, Tom Marchant
(0000000a2a8c2020-dmarc-***@LISTSERV.UA.EDU) wrote about "Re:
REGION=0M leads to CPU through the roof" (in
<***@listserv.ua.edu>):

[snip]
Post by Tom Marchant
I agree. Increasing the region doesn't ordinarily increase the storage utilization.
As a PL/I programmer of more than 40 years, I am sufficiently familiar with IBM's run-time libraries to offer a contrary experience. The start-up code for the old PL/I OS Optimizing compiler would check the VSM parameters and GETMAIN 50% of the remaining storage in the region/partition. [I wrote "partition" because this goes back to the
OS/VS1 days.] The upshot was that the bigger the region one coded in the JCL the more memory the RTL would acquire at start-up time -- and would hold for the duration of the job step. It could acquire still more if the program needed it.

One could override this by coding a PLIXOPT string in the OPTIONS(MAIN) procedure or by putting similar options in the PARM field of the JCL.

Since LE is largely analogous to the old PL/I RTL, I would bet dollars to doughnuts that it will do something similar if allowed. Coding memory constraints in the RTL options can work wonders.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-07-25 17:37:26 UTC
Permalink
Raw Message
On Tue, 25 Jul 2017 09:28:35 -0700, Charles Mills (***@MCN.ORG)
wrote about "Re: REGION=0M leads to CPU through the roof" (in
Post by Charles Mills
Not a huge expert but I do a certain amount of tuning of storage
requirements as the developer of a vendor product, and I have the
distinct impression that LE's initial program runtime storage
parameters are fixed at either compile or startup time and based on
supplied parameters, independent of the actual region size. That is,
there is no algorithm like "get half the free storage." It is "get X
bytes."

The change in memory consumption in the step termination reports would
suggest that memory acquisition is varying with region size in this
case. The fact that there is no S80A, S878, etc., abend would indicate
that something inside the application knows how large the region is and
does not exceed its bounds. COBOL programs are not usually that clever.
Post by Charles Mills
Of course, region size affects the possibility of an x78 failure if
the program requires more storage than initially obtained.
That has always been its purpose.
Post by Charles Mills
I notice the OP, who was posting hourly or so, has gone quiet.
Perhaps the problem has been located.
It would be interesting to know the final cause and resolution.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-07-25 17:54:24 UTC
Permalink
Raw Message
FYI, OP wrote "Customer found that one release of our product got an 878 when a prior release had not."

I don't deny that storage utilization is changing with region size; my point was just that AFAIK LE's startup GETMAINs are based on coded parameters, not region size discovery.

Yes, I hope the OP does not leave us hanging here.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David W Noon
Sent: Tuesday, July 25, 2017 10:39 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof
Post by Charles Mills
Not a huge expert but I do a certain amount of tuning of storage
requirements as the developer of a vendor product, and I have the
distinct impression that LE's initial program runtime storage
parameters are fixed at either compile or startup time and based on
supplied parameters, independent of the actual region size. That is,
there is no algorithm like "get half the free storage." It is "get X
bytes."

The change in memory consumption in the step termination reports would suggest that memory acquisition is varying with region size in this case. The fact that there is no S80A, S878, etc., abend would indicate that something inside the application knows how large the region is and does not exceed its bounds. COBOL programs are not usually that clever.
Post by Charles Mills
Of course, region size affects the possibility of an x78 failure if
the program requires more storage than initially obtained.
That has always been its purpose.
Post by Charles Mills
I notice the OP, who was posting hourly or so, has gone quiet.
Perhaps the problem has been located.
It would be interesting to know the final cause and resolution.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-07-25 19:07:02 UTC
Permalink
Raw Message
Oh, sorry, didn’t mean to leave this hanging - I had to leave yesterday and am just getting back to this.

The points are all very interesting - no, I haven't got to the bottom of this yet - but all of this is helpful - particularly the bit about not expecting the used memory to increase with REGION=0M and the suggestion of RPTSTG. (not denigrating / ignoring the other suggestions, just that's what I am focusing on at the moment).

It's a customer COBOL program - quite long and involved. I haven't grokked it in fullness yet - it may well have the attributes someone suggested (variable table searched inefficiently).

Will chime back in when I have results / additional questions.

Thanks all.

Rich Way

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Tuesday, July 25, 2017 10:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

FYI, OP wrote "Customer found that one release of our product got an 878 when a prior release had not."

I don't deny that storage utilization is changing with region size; my point was just that AFAIK LE's startup GETMAINs are based on coded parameters, not region size discovery.

Yes, I hope the OP does not leave us hanging here.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David W Noon
Sent: Tuesday, July 25, 2017 10:39 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof
Post by Charles Mills
Not a huge expert but I do a certain amount of tuning of storage
requirements as the developer of a vendor product, and I have the
distinct impression that LE's initial program runtime storage
parameters are fixed at either compile or startup time and based on
supplied parameters, independent of the actual region size. That is,
there is no algorithm like "get half the free storage." It is "get X
bytes."

The change in memory consumption in the step termination reports would suggest that memory acquisition is varying with region size in this case. The fact that there is no S80A, S878, etc., abend would indicate that something inside the application knows how large the region is and does not exceed its bounds. COBOL programs are not usually that clever.
Post by Charles Mills
Of course, region size affects the possibility of an x78 failure if
the program requires more storage than initially obtained.
That has always been its purpose.
Post by Charles Mills
I notice the OP, who was posting hourly or so, has gone quiet.
Perhaps the problem has been located.
It would be interesting to know the final cause and resolution.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-07-26 00:26:25 UTC
Permalink
Raw Message
[Default] On 25 Jul 2017 12:07:02 -0700, in bit.listserv.ibm-main
Oh, sorry, didn’t mean to leave this hanging - I had to leave yesterday and am just getting back to this.
The points are all very interesting - no, I haven't got to the bottom of this yet - but all of this is helpful - particularly the bit about not expecting the used memory to increase with REGION=0M and the suggestion of RPTSTG. (not denigrating / ignoring the other suggestions, just that's what I am focusing on at the moment).
It's a customer COBOL program - quite long and involved. I haven't grokked it in fullness yet - it may well have the attributes someone suggested (variable table searched inefficiently).
Will chime back in when I have results / additional questions.
Is the COBOL program using the SORT verb? What language(s) are any
called sub-programs in? Is DB2, IMS or other database involved?

Clark Morris
Thanks all.
Rich Way
-----Original Message-----
Sent: Tuesday, July 25, 2017 10:56 AM
Subject: Re: REGION=0M leads to CPU through the roof
FYI, OP wrote "Customer found that one release of our product got an 878 when a prior release had not."
I don't deny that storage utilization is changing with region size; my point was just that AFAIK LE's startup GETMAINs are based on coded parameters, not region size discovery.
Yes, I hope the OP does not leave us hanging here.
Charles
-----Original Message-----
Sent: Tuesday, July 25, 2017 10:39 AM
Subject: Re: REGION=0M leads to CPU through the roof
Post by Charles Mills
Not a huge expert but I do a certain amount of tuning of storage
requirements as the developer of a vendor product, and I have the
distinct impression that LE's initial program runtime storage
parameters are fixed at either compile or startup time and based on
supplied parameters, independent of the actual region size. That is,
there is no algorithm like "get half the free storage." It is "get X
bytes."
The change in memory consumption in the step termination reports would suggest that memory acquisition is varying with region size in this case. The fact that there is no S80A, S878, etc., abend would indicate that something inside the application knows how large the region is and does not exceed its bounds. COBOL programs are not usually that clever.
Post by Charles Mills
Of course, region size affects the possibility of an x78 failure if
the program requires more storage than initially obtained.
That has always been its purpose.
Post by Charles Mills
I notice the OP, who was posting hourly or so, has gone quiet.
Perhaps the problem has been located.
It would be interesting to know the final cause and resolution.
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bernd Oppolzer
2017-07-25 20:08:37 UTC
Permalink
Raw Message
IMHO, this kind of behaviour MUST have to do with some
logic inside the application, which allocates storage dynamically
and reacts on "short on storage" conditions from LE (aka language
environment) - which is the runtime for all compiled languages today.

Storage consumption by LE is controlled by HEAP and STACK
parameters, which define primary and secondary extent sizes
and where the storage is taken from (BELOW/ABOVE) - very short
description.

See more details here:

http://www-03.ibm.com/systems/resources/Stack+and+Heap.pdf

I saw large CPU consumption in the past, but most of the time
due to very bad LE options (small extent sizes, leading to many
small storage alloc and free requests) - or, when LE is working
near the short on storage condition, but then we had an error
in the end, normally.

FWIW: I wrote a routine that can be called on the fly and monitors
the usage of dynamic storage (it does some sort of bookkeeping,
based on the LE control blocks and tells, which areas have been
allocated and not freed between two control points of an application).
My customers used this very successfully to detect memory leaks
in their applications (C, C++, even PL/1). If you are interested,
contact me offline.

And: I rewrote the LE storage management, based on the description
above, using the Pascal language - for the use in the Hercules
environment (for MVS and CMS).

Look here:

http://bernd-oppolzer.de/job9k14.htm

Kind regards

Bernd
Post by Charles Mills
Not a huge expert but I do a certain amount of tuning of storage requirements as the developer of a vendor product, and I have the distinct impression that LE's initial program runtime storage parameters are fixed at either compile or startup time and based on supplied parameters, independent of the actual region size. That is, there is no algorithm like "get half the free storage." It is "get X bytes."
Of course, region size affects the possibility of an x78 failure if the program requires more storage than initially obtained.
I notice the OP, who was posting hourly or so, has gone quiet. Perhaps the problem has been located.
Charles
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-07-25 19:14:24 UTC
Permalink
Raw Message
I grokked a new word today. MS Word spell check is equally clueless.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Tuesday, July 25, 2017 12:08 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: REGION=0M leads to CPU through the roof

<snip>
It's a customer COBOL program - quite long and involved. I haven't grokked it in fullness yet - it may well have the attributes someone suggested (variable table searched inefficiently).
<snip>
Rich Way
<snip>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-07-26 11:52:26 UTC
Permalink
Raw Message
Post by Tom Marchant
Increasing the region doesn't ordinarily increase the
storage utilization.
True. But it might well increase the storage allocation.

Consider an application that does a variable-length GETMAIN so that it
can, in effect, allocate the entire region (and possibly sub-manage the
storage then). I believe HLASM might do just that.

The question is then what does the application do with that allocated
storage. If the extra storage isn't used, then it won't matter much (if at
all) that it has been allocated. But if it is used, then anything could be
going on, whether it's unnecessary clearing or anything else.

Without knowing the details of the application, no one can do more than
guess.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ron Hawkins
2017-07-27 00:09:30 UTC
Permalink
Raw Message
Richard,

You used 1.6GB of virtual storage.

How much paging did the address do? There's no free lunch, and page faults
will increase the TCB time for an address.

Ron

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Way, Richard
Sent: Monday, July 24, 2017 1:19 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: [IBM-MAIN] REGION=0M leads to CPU through the roof

In the course of trying to duplicate a customer problem, I have run across
unexpected behavior that I wonder if anyone can help to explain.

I have an application program (COBOL 4.2, z/OS 2.2, AMODE 31, RENT) that
exhibits the following:

When run with our *default* REGION (i.e. no REGION= on the EXEC whatsoever):

CPU: 0 HR 00 MIN 31.34 SEC SRB: 0 HR 00 MIN 00.06 SEC
VIRT: 1056K SYS: 276K EXT: 32740K SYS: 13116K
ATB- REAL: 8K SLOTS: 0K
VIRT- ALLOC: 10M SHRD: 0M

When run with an explicit REGION=0M:

CPU: 0 HR 11 MIN 38.43 SEC SRB: 0 HR 00 MIN 00.07 SEC
VIRT: 7856K SYS: 276K EXT: 1622548K SYS: 13116K
ATB- REAL: 8K SLOTS: 0K
VIRT- ALLOC: 10M SHRD: 0M

You'll note the large increase in storage - which is of course not
surprising - but more interesting (and unwelcome) to me is that the CPU time
required increased by roughly a factor of 22X to do the exact same work.
(The ONLY difference between the two runs is the addition of REGION=0M to
the EXEC.)

Can anyone suggest what I should be thinking about here in terms of possible
causes? Is it possible that so much "overhead" is needed to manage the much
larger memory space? Could it be something to do with LE tuning?

Thanks,

Richard Way
HPE Security - Data Security
HPE Software | Enterprise Security Products

+1 408 857 0216 Mobile

1140 Enterprise Way, Mail Stop 3048
Sunnyvale, CA 94089

[HPE logo]<http://www.hpe.com/>


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-07-27 00:35:45 UTC
Permalink
Raw Message
By ELEVEN CPU MINUTES???

A modern processor can do a heck of a lot of paging with 11 CPU minutes.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Ron Hawkins
Sent: Wednesday, July 26, 2017 5:08 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Richard,

You used 1.6GB of virtual storage.

How much paging did the address do? There's no free lunch, and page faults
will increase the TCB time for an address.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ron Hawkins
2017-07-28 01:49:28 UTC
Permalink
Raw Message
Charles,

YES I AGREE, storage nowadays can do a lot of paging, and support a CEC
easily burning 11 minutes of CPU time paging. DPR rates of 100,000/sec are a
walk in the park for current IBM, EMC or HDs controllers, and probably
higher on a boxes that can do >2,000,000 cache hits a second.

Of course, if the OP is not actually going to look at anything but the CPU
time, he will probably never find out what cause it.

Ron

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, July 26, 2017 5:37 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] REGION=0M leads to CPU through the roof

By ELEVEN CPU MINUTES???

A modern processor can do a heck of a lot of paging with 11 CPU minutes.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Ron Hawkins
Sent: Wednesday, July 26, 2017 5:08 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof

Richard,

You used 1.6GB of virtual storage.

How much paging did the address do? There's no free lunch, and page faults
will increase the TCB time for an address.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gerhard Adam
2017-07-28 03:17:35 UTC
Permalink
Raw Message
I don't see paging as the culprit. To page out 1.6 GB of memory and then reference it to bring it back in still indicates an application problem. Especially with a total elapsed time of only 12 minutes.

I suspect that the application built a table. Spent wasted time searching it.

Sent from my iPhone
Post by Ron Hawkins
Charles,
YES I AGREE, storage nowadays can do a lot of paging, and support a CEC
easily burning 11 minutes of CPU time paging. DPR rates of 100,000/sec are a
walk in the park for current IBM, EMC or HDs controllers, and probably
higher on a boxes that can do >2,000,000 cache hits a second.
Of course, if the OP is not actually going to look at anything but the CPU
time, he will probably never find out what cause it.
Ron
-----Original Message-----
Behalf Of Charles Mills
Sent: Wednesday, July 26, 2017 5:37 PM
Subject: Re: [IBM-MAIN] REGION=0M leads to CPU through the roof
By ELEVEN CPU MINUTES???
A modern processor can do a heck of a lot of paging with 11 CPU minutes.
Charles
-----Original Message-----
Behalf Of Ron Hawkins
Sent: Wednesday, July 26, 2017 5:08 PM
Subject: Re: REGION=0M leads to CPU through the roof
Richard,
You used 1.6GB of virtual storage.
How much paging did the address do? There's no free lunch, and page faults
will increase the TCB time for an address.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ron Hawkins
2017-07-28 08:09:00 UTC
Permalink
Raw Message
Gerhard,

Now what if the searching you describe was a sequential scan of said table,
and the LPAR had only 1GB of storage defined?

Ron

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Gerhard Adam
Sent: Thursday, July 27, 2017 8:19 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] REGION=0M leads to CPU through the roof

I don't see paging as the culprit. To page out 1.6 GB of memory and then
reference it to bring it back in still indicates an application problem.
Especially with a total elapsed time of only 12 minutes.

I suspect that the application built a table. Spent wasted time searching
it.

Sent from my iPhone
Post by Ron Hawkins
Charles,
YES I AGREE, storage nowadays can do a lot of paging, and support a
CEC easily burning 11 minutes of CPU time paging. DPR rates of
100,000/sec are a walk in the park for current IBM, EMC or HDs
controllers, and probably higher on a boxes that can do >2,000,000 cache
hits a second.
Post by Ron Hawkins
Of course, if the OP is not actually going to look at anything but the
CPU time, he will probably never find out what cause it.
Ron
-----Original Message-----
On Behalf Of Charles Mills
Sent: Wednesday, July 26, 2017 5:37 PM
Subject: Re: [IBM-MAIN] REGION=0M leads to CPU through the roof
By ELEVEN CPU MINUTES???
A modern processor can do a heck of a lot of paging with 11 CPU minutes.
Charles
-----Original Message-----
On Behalf Of Ron Hawkins
Sent: Wednesday, July 26, 2017 5:08 PM
Subject: Re: REGION=0M leads to CPU through the roof
Richard,
You used 1.6GB of virtual storage.
How much paging did the address do? There's no free lunch, and page
faults will increase the TCB time for an address.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Schramm
2017-07-28 09:50:06 UTC
Permalink
Raw Message
Turn on a monitor while the step is running? With 12 min of CPU, there is
time to dig into it.

Rob
Post by Ron Hawkins
Gerhard,
Now what if the searching you describe was a sequential scan of said table,
and the LPAR had only 1GB of storage defined?
Ron
-----Original Message-----
Behalf Of Gerhard Adam
Sent: Thursday, July 27, 2017 8:19 PM
Subject: Re: [IBM-MAIN] REGION=0M leads to CPU through the roof
I don't see paging as the culprit. To page out 1.6 GB of memory and then
reference it to bring it back in still indicates an application problem.
Especially with a total elapsed time of only 12 minutes.
I suspect that the application built a table. Spent wasted time searching it.
Sent from my iPhone
Post by Ron Hawkins
Charles,
YES I AGREE, storage nowadays can do a lot of paging, and support a
CEC easily burning 11 minutes of CPU time paging. DPR rates of
100,000/sec are a walk in the park for current IBM, EMC or HDs
controllers, and probably higher on a boxes that can do >2,000,000 cache
hits a second.
Post by Ron Hawkins
Of course, if the OP is not actually going to look at anything but the
CPU time, he will probably never find out what cause it.
Ron
-----Original Message-----
On Behalf Of Charles Mills
Sent: Wednesday, July 26, 2017 5:37 PM
Subject: Re: [IBM-MAIN] REGION=0M leads to CPU through the roof
By ELEVEN CPU MINUTES???
A modern processor can do a heck of a lot of paging with 11 CPU minutes.
Charles
-----Original Message-----
On Behalf Of Ron Hawkins
Sent: Wednesday, July 26, 2017 5:08 PM
Subject: Re: REGION=0M leads to CPU through the roof
Richard,
You used 1.6GB of virtual storage.
How much paging did the address do? There's no free lunch, and page
faults will increase the TCB time for an address.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Rob Schramm

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-07-28 04:10:12 UTC
Permalink
Raw Message
Yep.



CharlesSent from a mobile; please excuse the brevity.
-------- Original message --------From: Gerhard Adam <***@CHARTER.NET> Date: 7/27/17 8:18 PM (GMT-08:00) To: IBM-***@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof
I don't see paging as the culprit.  To page out 1.6 GB of memory and then reference it to bring it back in still indicates an application problem.  Especially with a total elapsed time of only 12 minutes.

I suspect that the application built a table.  Spent wasted time searching it.

Sent from my iPhone
Post by Ron Hawkins
Charles,
YES I AGREE, storage nowadays can do a lot of paging, and support a CEC
easily burning 11 minutes of CPU time paging. DPR rates of 100,000/sec are a
walk in the park for current IBM, EMC or HDs controllers, and probably
higher on a boxes that can do >2,000,000 cache hits a second.
Of course, if the OP is not actually going to look at anything but the CPU
time, he will probably never find out what cause it.
Ron
-----Original Message-----
Behalf Of Charles Mills
Sent: Wednesday, July 26, 2017 5:37 PM
Subject: Re: [IBM-MAIN] REGION=0M leads to CPU through the roof
By ELEVEN CPU MINUTES???
A modern processor can do a heck of a lot of paging with 11 CPU minutes.
Charles
-----Original Message-----
Behalf Of Ron Hawkins
Sent: Wednesday, July 26, 2017 5:08 PM
Subject: Re: REGION=0M leads to CPU through the roof
Richard,
You used 1.6GB of virtual storage.
How much paging did the address do? There's no free lunch, and page faults
will increase the TCB time for an address.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...