Portal | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Forum Index
 
Register
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
Job is loading load modules several times

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
ravikumar_sri2001

New User


Joined: 04 Jan 2006
Posts: 6

PostPosted: Fri Sep 18, 2020 1:22 am    Post subject: Job is loading load modules several times
Reply with quote

Experts,

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 
                                                                               
 Module     Locn  Address  Count  Size(bytes)  Attributes  DDName    Load Librar
 CSQBCON    JPA   1F02E000   62       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000    5       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   48       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   10       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000  100       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   13       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   47       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   27       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000    2       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000    5       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   48       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000    7       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000  252       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000    5       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000  109       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   85       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   18       50,624   RU RN       -VLF-     MQ.V9R1M0.S
 CSQBCON    JPA   1F02E000   49       50,624   RU RN       -VLF-     MQ.V9R1M0.S


Thanks,
Ravikumar


Coded for you - do it yourself next time.
Back to top
View user's profile Send private message

Apoorva

New User


Joined: 28 Jan 2020
Posts: 47
Location: India

PostPosted: Fri Sep 18, 2020 8:04 am    Post subject: Re: Job is loading load modules several times
Reply with quote

ravikumar_sri2001 wrote:
Experts,

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

Module Locn Address Count Size(bytes) Attributes DDName Load Librar
CSQBCON JPA 1F02E000 62 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 5 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 48 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 10 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 100 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 13 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 47 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 27 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 2 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 5 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 48 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 7 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 252 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 5 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 109 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 85 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 18 50,624 RU RN -VLF- MQ.V9R1M0.S
CSQBCON JPA 1F02E000 49 50,624 RU RN -VLF- MQ.V9R1M0.S

Thanks,
Ravikumar



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.
Back to top
View user's profile Send private message
Apoorva

New User


Joined: 28 Jan 2020
Posts: 47
Location: India

PostPosted: Fri Sep 18, 2020 8:21 am    Post subject: Re: Job is loading load modules several times
Reply with quote

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.
Back to top
View user's profile Send private message
ravikumar_sri2001

New User


Joined: 04 Jan 2006
Posts: 6

PostPosted: Fri Sep 18, 2020 9:07 am    Post subject:
Reply with quote

Apoorva,

Thanks for your reply!!

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."


Thanks,
Ravikumar
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1012
Location: Richmond, Virginia

PostPosted: Fri Sep 18, 2020 9:12 am    Post subject:
Reply with quote

Apoorva - what is the point of quoting the entire original question?
Back to top
View user's profile Send private message
Apoorva

New User


Joined: 28 Jan 2020
Posts: 47
Location: India

PostPosted: Fri Sep 18, 2020 9:54 am    Post subject:
Reply with quote

ravikumar_sri2001 wrote:
Apoorva,

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.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 860
Location: The Universe

PostPosted: Fri Sep 18, 2020 10:44 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
ravikumar_sri2001

New User


Joined: 04 Jan 2006
Posts: 6

PostPosted: Fri Sep 18, 2020 10:53 am    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
Apoorva

New User


Joined: 28 Jan 2020
Posts: 47
Location: India

PostPosted: Fri Sep 18, 2020 3:29 pm    Post subject:
Reply with quote

ravikumar_sri2001 wrote:
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,

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100372.htm

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.

BAKR 14,0
LOAD EP=CSQBCON
PR
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 860
Location: The Universe

PostPosted: Fri Sep 18, 2020 6:55 pm    Post subject:
Reply with quote

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]
Back to top
View user's profile Send private message
ravikumar_sri2001

New User


Joined: 04 Jan 2006
Posts: 6

PostPosted: Sat Sep 19, 2020 2:10 am    Post subject:
Reply with quote

Thank you so much Apoorva and Steve for your inputs!!!

Thanks,
Ravikumar
Back to top
View user's profile Send private message
Apoorva

New User


Joined: 28 Jan 2020
Posts: 47
Location: India

PostPosted: Sat Sep 19, 2020 10:09 am    Post subject:
Reply with quote

steve-myers wrote:

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
Back to top
View user's profile Send private message
ravikumar_sri2001

New User


Joined: 04 Jan 2006
Posts: 6

PostPosted: Sat Sep 19, 2020 3:36 pm    Post subject:
Reply with quote

Thank you so much Apoorva!!
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Need help on DB2 load in Mainframe subratarec DB2 5 Tue Mar 24, 2020 2:08 am
No new posts Load Module compare showing mismatche... Aditya.Srivastava PL/I & Assembler 5 Tue Dec 10, 2019 8:26 pm
No new posts LOAD JCL for db2 table, taking too lo... Somnath Giri DB2 5 Mon Oct 14, 2019 3:35 pm
No new posts Convert CICS Modules to AMODE ANY CICSWOLF PL/I & Assembler 6 Fri Feb 08, 2019 7:10 pm
No new posts DB2 Unload / Load Multiple tables neo4u DB2 8 Tue Nov 27, 2018 3:43 pm

Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us