Discussion:
Strange application (or A.P.A) behaviour.
(too old to reply)
Massimo Biancucci
2017-11-28 15:37:37 UTC
Permalink
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 ****************
IGZXFPW COBOL 2 Module 12.43 ******
FPVDFPCX CSECT in IGZXLPKA 9.53 *****
IGZXPR2 COBOL 2 Module 5.40 ***
IGZXFCAL COBOL 2 Module 0.02
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bernd Oppolzer
2017-11-28 20:30:37 UTC
Permalink
This post might be inappropriate. Click to display it.
Bernd Oppolzer
2017-11-28 22:22:33 UTC
Permalink
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

     > ***@BCD   COBOL 2 Module     12.76 ******
something with BCD

     > IGZXFPW   COBOL 2 Module     12.43 ******
FP ...

     > FPVDFPCX  CSECT in IGZXLPKA   9.53 *****
FP ..

     > ***@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
Post by Bernd Oppolzer
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
Post by 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 ****************
     > IGZXFPW   COBOL 2 Module     12.43 ******
     > FPVDFPCX  CSECT in IGZXLPKA   9.53 *****
     > IGZXPR2   COBOL 2 Module      5.40 ***
     > IGZXFCAL  COBOL 2 Module      0.02
     > 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,
----------------------------------------------------------------------
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
Massimo Biancucci
2017-12-12 16:46:46 UTC
Permalink
Thanks for your support.

One of the programs does heavy use of FP variables (mortgage calculation).

Regards.
Massimo
Post by Bernd Oppolzer
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
IGZBXXMU COBOL 2 Module 31.51 ****************
multiply
something with BCD
IGZXFPW COBOL 2 Module 12.43 ******
FP ...
FPVDFPCX CSECT in IGZXLPKA 9.53 *****
FP ..
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
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
Post by 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 ****************
IGZXFPW COBOL 2 Module 12.43 ******
FPVDFPCX CSECT in IGZXLPKA 9.53 *****
IGZXPR2 COBOL 2 Module 5.40 ***
IGZXFCAL COBOL 2 Module 0.02
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
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
computer chyck
2017-12-12 18:22:22 UTC
Permalink
Post by Massimo Biancucci
Thanks for your support.
One of the programs does heavy use of FP variables (mortgage calculation).
Regards.
Massimo
Post by Bernd Oppolzer
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
IGZBXXMU COBOL 2 Module 31.51 ****************
multiply
something with BCD
IGZXFPW COBOL 2 Module 12.43 ******
FP ...
FPVDFPCX CSECT in IGZXLPKA 9.53 *****
FP ..
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
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
Post by 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 ****************
IGZXFPW COBOL 2 Module 12.43 ******
FPVDFPCX CSECT in IGZXLPKA 9.53 *****
IGZXPR2 COBOL 2 Module 5.40 ***
IGZXFCAL COBOL 2 Module 0.02
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
something else to look at is if you're using an optimizer or not at compile time. (This came from a CA guy years ago) Optimizers are great but can be cpu expensive.
Tony Harminc
2017-12-14 00:59:30 UTC
Permalink
Post by Massimo Biancucci
Thanks for your support.
One of the programs does heavy use of FP variables (mortgage calculation).
I hate to ask, but *binary* FP for financial calculations?

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-12-14 01:22:32 UTC
Permalink
I was going to say that too, but then decided not to. But it certainly makes me wonder!
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Tony Harminc <***@HARMINC.NET>
Sent: Wednesday, December 13, 2017 6:00 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Strange application (or A.P.A) behaviour.
Post by Massimo Biancucci
Thanks for your support.
One of the programs does heavy use of FP variables (mortgage calculation).
I hate to ask, but *binary* FP for financial calculations?

Tony H.

----------------------------------------------------------------------
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
Bernd Oppolzer
2017-12-14 06:49:45 UTC
Permalink
When I worked for a big insurance company (for more than 20 years),
we did all our insurance math using binary FP. After some problems
(rounding issues) in the beginning, it worked without problems, and
it still does today. It was driven by the design decision to have the same
software working on all platforms, Windows, OS/2, all sorts of Unixes,
and IBM mainframe, and to use C to do this. The project started in 1992
and was in hindsight very successful. Before that, the insurance math was
done using Mainframe ASSEMBLER.

I conceived and held the C classes to enable the existing ASSEMBLER and
PL/1
developers to code in C for all the different platforms in the first years.
Later I worked on the project as a developer and consultant.

Kind regards

Bernd
Post by Frank Swarbrick
I was going to say that too, but then decided not to. But it certainly makes me wonder!
________________________________
Sent: Wednesday, December 13, 2017 6:00 PM
Subject: Re: Strange application (or A.P.A) behaviour.
Post by Massimo Biancucci
Thanks for your support.
One of the programs does heavy use of FP variables (mortgage calculation).
I hate to ask, but *binary* FP for financial calculations?
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Massimo Biancucci
2017-12-14 14:36:29 UTC
Permalink
I'm not "into" the application enough.

It seems they use FP for different calculations. To do "capital
discounting", for instance, they use "**" operator and this is the most
hungry cpu consumer.

Maybe they prefer to work at the maximum precision rounding at the end.

Sorry for being not so effective.

Massimo
Post by Massimo Biancucci
Post by Massimo Biancucci
Thanks for your support.
One of the programs does heavy use of FP variables (mortgage
calculation).
I hate to ask, but *binary* FP for financial calculations?
Tony H.
----------------------------------------------------------------------
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
Attila Fogarasi
2017-11-28 22:13:17 UTC
Permalink
Looks like this app is using floating point judging by the library module
names, hence the huge cpu time (XMU is fp multiply from my dim memory of 20
years ago). Converting to DFP in Cobol v5 will reduce cpu time
dramatically.
Post by 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 ****************
IGZXFPW COBOL 2 Module 12.43 ******
FPVDFPCX CSECT in IGZXLPKA 9.53 *****
IGZXPR2 COBOL 2 Module 5.40 ***
IGZXFCAL COBOL 2 Module 0.02
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...