Thanks for your support. One of the programs does heavy use of FP variables (mortgage calculation).
Regards. Massimo 2017-11-28 23:23 GMT+01:00 Bernd Oppolzer <[email protected]>: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
