View previous topic :: View next topic
|
Author |
Message |
Virendra Shambharkar
New User
Joined: 26 Aug 2015 Posts: 55 Location: India
|
|
|
|
Hi ,
We have a job that is continuously polling MQ to read data . If there is no data in MQ it goes to MQ wait and then again polls the MQ to read . Other than this it does not do any other function.It runs for 10-12 hours and is showing to consume around 1 hour of CPU in JESYSMSG .
A STROBE report on this job shows 80 % of CPU in common area . The Program Usage by Procedure sections (PSU) shows 80 % in module name as COMMON as system service description as 'EXTENDED COMMON AREA'.
Can you help me understand why the CPU consumption in Common area and if there is any pointer on optimization for the same.
Thanks,
Virendra |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
Many programming systems load modules that must be in shared storage (that is, storage available to all address spaces) into the “common” storage area rather than place the module into LPA. Alternatively, if the module is small, it is simply copied into common storage. It appears the MQ executive is doing the latter since the module is not in the list of modules known to the system.
There is a fundamental difference between 80% of the CPU and 80% of the time in the program, if the program is using, say, 1% of the total CPU capacity. If your program is periodically waking up and checking if there is a message, “optimizing,” or in your context, reducing this time is a matter of the design of the MQ programming system and is properly a matter to be discussed with IBM's MQ support. |
|
Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006 Posts: 1353 Location: Israel
|
|
|
|
Which value do you have for MQ wait interval ? |
|
Back to top |
|
|
Virendra Shambharkar
New User
Joined: 26 Aug 2015 Posts: 55 Location: India
|
|
|
|
Thanks on further research we found program BPXWDYN is called down the line which is TSO command executor program . COMMONX is related to MVS and we suspect because of this module there is MVS involvement which could cause more CPU.
Thanks a lot. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
I doubt that BPXWDYN calls could be the cause for a <high> CPU utilisation |
|
Back to top |
|
|
Virendra Shambharkar
New User
Joined: 26 Aug 2015 Posts: 55 Location: India
|
|
|
|
Not the calls but loading of the module could be causing high CPU . Since COMMONX relates to loading program at run time . I got reference from below:-
www.idug.org/p/fo/et/thread=3965 |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
the link You posted also tells that
Quote: |
COMMONX stuff is MVS-related only that was put
there at IPL time. |
and BPXWDYN does not belong to that category
and if BPXWDYN were the the culprit You would face other problems
related this time to dynamic allocation |
|
Back to top |
|
|
Virendra Shambharkar
New User
Joined: 26 Aug 2015 Posts: 55 Location: India
|
|
|
|
Thanks Enrico . Is there a way to identify what are the modules/subroutines that belong to COMMONX.
Thanks,
Virendra |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
Virendra Shambharkar wrote: |
Thanks Enrico . Is there a way to identify what are the modules/subroutines that belong to COMMONX.
Thanks,
Virendra |
This is something you must discuss with MQ support. Since Strobe cannot deduce a module name it appears the code was moved to common outside of standard MVS program management controls. This was common before MVS provided directed load capabilities. I did it myself for a Strobe like project in the early 1980s, though the code was small and had no embedded address constants. |
|
Back to top |
|
|
|