I am trying to tune a job. From IBM Application performance Analyzer, I could see that, job is spending 13% of CPU time, in loading load modules.
I could see that CSQBCON module is loaded several times. This module is already placed in LLA/VLF.
I tried to run the job with REGION=0M and adding the load libary of CSQBCON in STEPLIB. But it did not work.
Is there any way to prevent the module CSQBCON loading multiple times ?
Code:
File View Navigate Help
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
C01: CPU Usage by Category (91292/J00W000N) Row 00001 of 00022
Command ===> Scroll ===> CSR
Name Description Percent of CPU Time * 10.00% ±1.5%
*....1....2....3....4....5....6....7...
SYSTEM System/OS Services 47.91 llllllllllllllllllllllll
± SVC SVC Routines 25.51 lllllllllllll
± SVC008 LOAD 13.27 lllllll
± SVC006 LINK 7.31 llll
± SVC122 LOAD/LINK/XCTL/EVENT 2.38 l
S
± SVC120 GETMAIN/FREEMAIN 0.88
± SVC009 DELETE 0.64
± SVC048 DEQ 0.42
± SVC056 ENQ RESERVE 0.38
± SVC003 EXIT 0.14
± SVC010 GETMAIN/FREEMAIN 0.04
± SVC060 ESTAE 0.02
Code:
File View Navigate Help
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
S03: Load Module Summary (91292/J00W000N) Row 00037 of 00303
Command ===> Scroll ===> CSR
I am trying to tune a job. From IBM Application performance Analyzer, I could see that, job is spending 13% of CPU time, in loading load modules.
I could see that CSQBCON module is loaded several times. This module is already placed in LLA/VLF.
I tried to run the job with REGION=0M and adding the load libary of CSQBCON in STEPLIB. But it did not work.
Is there any way to prevent the module CSQBCON loading multiple times ?
File View Navigate Help
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
C01: CPU Usage by Category (91292/J00W000N) Row 00001 of 00022
Command ===> Scroll ===> CSR
Name Description Percent of CPU Time * 10.00% ±1.5%
*....1....2....3....4....5....6....7...
SYSTEM System/OS Services 47.91 llllllllllllllllllllllll
± SVC SVC Routines 25.51 lllllllllllll
± SVC008 LOAD 13.27 lllllll
± SVC006 LINK 7.31 llll
± SVC122 LOAD/LINK/XCTL/EVENT 2.38 l
S
± SVC120 GETMAIN/FREEMAIN 0.88
± SVC009 DELETE 0.64
± SVC048 DEQ 0.42
± SVC056 ENQ RESERVE 0.38
± SVC003 EXIT 0.14
± SVC010 GETMAIN/FREEMAIN 0.04
± SVC060 ESTAE 0.02
File View Navigate Help
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
S03: Load Module Summary (91292/J00W000N) Row 00037 of 00303
Command ===> Scroll ===> CSR
What are the attributes of that load module? Load modules may have the attributes of serially-reusable, reentrant, refreshable. These are set at linkedit time and determine if the load module could be executed by only one task or could be executed by multiple tasks concurrently and if reloading into virtual storage is required between executions. If a load module does not have any of these attributes then it is considered to be nonreusable. In the case of nonreusable load module, a fresh copy of load module will be brought to virtual storage each time you invoke LOAD or LINK or ATTACH macros. The load module that you are referring to is probably nonreusable, and hence brought to virtual storage each time it is invoked.
I just now saw the messages more closely. Looks like the load module CSQBCON is reentrant, and it's address is always 1F02E000 in JPA. I am not familiar with reports generated by "IBM Application performance Analyzer". So are you sure the module is deleted and loaded fresh each time LINK is invoked? Because address of the module is always same. You could also follow below steps if you think you module is loaded fresh each time you invoke LINK/XCTL,
STEP1:- Explicitly issue LOAD to bring the module to virtual storage.
STEP2:- Issue LINK/XCTL against the module as many times as you need, and it will refer to the same copy of load module that was loaded in the previous step.
STEP3:- Issue DELETE at the end to explicitly delete the load module.
Yes the CSQBCON module is reusable and re-entrant. The module comes as part of MQ series from IBM. This module seems to be loaded to VLF.
Module Information for CSQBCON
Load Address 1F02E000 to 1F03A5BF
Module Size 50,624
Attributes REUS,RENT,APFLIB
Module Location JPA
Loadlib DDNAME -VLF-
Load Library MQ.V9R1M0.SCSQAUTH
Program Group MQSeries
Subgroup MQSeries
Function MQSeries Batch Adapter
When the COBOL program tries to connect to MQ manager using "MQCONN" call, I think CSQBCON module is internally invoked.
You can see the module load count after the address. Sorry about the fomatting.
From IBM APAR manual, count refers to "the number of unique instances of the load module observed at the indicated address. This value exceeds 1 if the module was loaded, deleted and then loaded again. A high value could indicate the module was loaded (and deleted) excessively and could be causing a performance problem."
From IBM APAR manual, count refers to "the number of unique instances of the load module observed at the indicated address. This value exceeds 1 if the module was loaded, deleted and then loaded again. A high value could indicate the module was loaded (and deleted) excessively and could be causing a performance problem."
Thanks,
Ravikumar
Right Ravi. This count is maintained in CDE control block for that module (Content Directory entry). The module will be deleted from virtual storage when the count, in CDE, reaches zero. But when a load module is brought to virtual storage using explicit LOAD, only an explicit DELETE could delete the load module from the storage. So, you could try loading that MQ module, using an explicit LOAD, at the beginning to see if it makes any difference.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Apoorva wrote:
... Right Ravi. This count is maintained in CDE control block for that module (Content Directory entry). The module will be deleted from virtual storage when the count, in CDE, reaches zero. But when a load module is brought to virtual storage using explicit LOAD, only an explicit DELETE could delete the load module from the storage. So, you could try loading that MQ module, using an explicit LOAD, at the beginning to see if it makes any difference.
Apoorva is correct. OS/360 contents management generally would retain an unused reenterable module in storage until the storage was required for some other purpose. MVT TSO (and, later, MVS) changed this approach to what Apoorva has described. I think the goal was to reduce I/O when a TSO swap region (MVT TSO) or address space was swapped.
But I'm not sure this is the behavior the messages appear to be documenting. I suspect we're seeing a LOAD request resolved by a module in storage. In other words, the LOAD isn't actually doing anything except adjusting the use count in the CDE. How to prove this? I don't know.
Apoorva,
How count in CDE reaches zero and where does CDE reside ?
Is there anyway to a LOAD/DELETE module from COBOL ?. I havent done this before.
Thanks,
Ravikumar
Hello Ravi,
Please note that the below explanation applies only to reusable load modules.
For each load module system will maintain two counts (called responsibility count).
First count gets incremented by one each time you invoke LOAD macro, and gets decremented by one each time you invoke DELETE macro. For example if you invoke LOAD macro 7 times, and issue DELETE 5 times after that then this count will be 2. You need to invoke DELETE same number of times as LOAD to make the count zero. Also if the task, that issued LOAD, ends then the count will be made zero irrespective of number of times LOAD was invoked.
The other count gets incremented by one each time LINK/ATTACH is invoked, and decremented by one after the execution of the program is complete.
The sum of above two counts is maintained in CDE control block for that module. (CDUSE field to be precise). Please find the link for CDE mapping below,
A load module will be deleted from virtual storage ONLY when the above count (which is sum of two different responsibility counts) is zero. In your case if you bring that particular MQ module using an explicit LOAD then count is always > 0 even after completion of LINK, and hence the module will NEVER be deleted until the end of that task.
I am not sure how to issue LOAD from COBOL. But you could call the below Assembler instructions (or program) from your COBOL program to explicitly LOAD CSQBCON at the beginning.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
ravikumar_sri2001 wrote:
Apoorva,
Thank you so much for your reply!!
How count in CDE reaches zero and where does CDE reside ?
Is there anyway to a LOAD/DELETE module from COBOL ?. I havent done this before.
Thanks,
Ravikumar
Where (in storage) is a CDE? Below the line in LSQA.
How can I LOAD (and DELETE) a module in Cobol? Cobol dynamic call appears to perform a LOAD and perform a subsequent branch to the module (as opposed to a LINK to the module, which would implies a DELETE when the module is finished). I know no way for Cobol to directly LOAD and DELETE a module.
Apoorva's BAKR/LOAD/PR Assembler module will get the job done, though it needs a little more code the flesh it out: it needs to prepare a base register before the LOAD macro.[/list]
Apoorva's BAKR/LOAD/PR Assembler module will get the job done, though it needs a little more code the flesh it out: it needs to prepare a base register before the LOAD macro.[/list]
That' right Steve. I forgot to add the BASE REG.
Ravi,
Please find the modified code in case you want to use it. Please note that I am assuming here that LOAD will never fail, and hence not checking the return code after LOAD.
BAKR 14,0
BASR 12,0
USING *,12
LOAD EP=CSQBCON
LA 15,0
PR
