Ok, please ignore that below ...
my assumption was based only on the remark done by the OP,
that the module with the high CPU usage is used to manage
dynamic calls.
The other poster IMO showed the real reason for the high
CPU usage; the names of the CSECTs make perfect sense with
respect to floating point usage:
> IGZBXXMU COBOL 2 Module 31.51 ****************
multiply
> IGZ@BCD COBOL 2 Module 12.76 ******
something with BCD
> IGZXFPW COBOL 2 Module 12.43 ******
FP ...
> FPVDFPCX CSECT in IGZXLPKA 9.53 *****
FP ..
> IGZ@CV COBOL 2 Module 6.17 ***
convert ??
> IGZXPR2 COBOL 2 Module 5.40 ***
print ?
If the batch does a lot of computations and floating
point is really needed, this high percentage of CPU
in that part of the LE library is OK, maybe. Of course,
there could be some potential for improvement.
HTH,
kind regards
Bernd
Am 28.11.2017 um 21:31 schrieb Bernd Oppolzer:
Very wild guess:
I had a similar behaviour once in an IBM system component.
The problem was, that this component, trying to find out if
a peculiar module has been loaded already, sequentially scanned
the list of loaded modules (CDE/XTLST). This is no big problem,
if the number of modules in the CDE/XTLST is small. But in our case,
it was in the hundreds, and the search was done on every (dynamic)
call of the module, and it was called millions of times. So the CPU
went up in the component doing this sequential search.
We found this problem by using STROBE to identify the code section
where the CPU hot spot was and by looking at the machine code there;
the control block scan was obvious. We could not convince IBM to change
this component, so we had to replace it by a complete different technique
(more details offline, if you want).
You could at least make sure, that THIS IS NOT YOUR PROBLEM by
taking a dump of your batch job in this particular situation and looking
at the CDE queue.
Don't know, if this helps :-)
Kind regards
Bernd
Am 28.11.2017 um 16:38 schrieb Massimo Biancucci:
Hi everybody,
in a customer shop we use IBM APA to trace some cpu-bound
applications in
order to find out in which modules and statement applications use the
most
of the cpu.
For a particular job APA shows a big "SYSTEM" cpu usage on IGZXLPKA
module
as you can see in the following data.
Name Description Percent of CPU Time * 10.00% .0.6%
*....1....2....3....4....5....6....7...
SYSTEM System/OS Services 78.03
**************************************
LERUNLIB Language Environment 77.88
**************************************
Runtime
> IGZXLPKA COBOL 2 Module 77.88
**************************************
> IGZBXXMU COBOL 2 Module 31.51 ****************
> IGZ@BCD COBOL 2 Module 12.76 ******
> IGZXFPW COBOL 2 Module 12.43 ******
> FPVDFPCX CSECT in IGZXLPKA 9.53 *****
> IGZ@CV COBOL 2 Module 6.17 ***
> IGZXPR2 COBOL 2 Module 5.40 ***
> IGZ@DSP COBOL 2 Module 0.02
> IGZXFCAL COBOL 2 Module 0.02
> IGZ@DCS2 COBOL 2 Module 0.01
> IGZXFCA4 COBOL 2 Module 0.00
MVS MVS System 0.11
SVC SVC Routines 0.03
DB2 DB2 Subsystem 0.00
DB2SQL SQL Processing 12.13 ******
APPLCN Application Code 9.70 *****
NOSYMB No Module Name 0.11
In such a shop applications are Cobol (main V4 moving to V5) and this
case
is a DB2 batch applications. There're different programs involved
dynamically called (to prevent questions, the whole shop is the same and
only this job shows this behaviour). There's a mix between V4 and V5
in the
call chain.
I was not able to find out lots of infos about the IGZXLPKA module
but it's
manages dynamic call.
I've tried with a different programs-chain (written to test the call
up to
5 level of nesting) but nothing similar happened.
Any hint ?
Thanks a lot in advance.
Massimo
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
