Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Trace the dynamic calls at runtime of a cobol program
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Mike 1304

New User


Joined: 15 Oct 2011
Posts: 43
Location: Germany

PostPosted: Sat Jan 14, 2012 2:21 pm    Post subject: Trace the dynamic calls at runtime of a cobol program
Reply with quote

Hi,

does anybody know a way to trace the dynamic calls of a cobol programm including calls done by cobol sub programs?

I want to see the complete hierarchy of calls at runtime.
Not by scanning the source code, but by watching at runtime!
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7235

PostPosted: Sat Jan 14, 2012 4:38 pm    Post subject: Reply to: COBOL Call Trace at runtime
Reply with quote

Have you access to any debugging/monitoring tools? Do they give you anything towards what you want?

You want to know every (Cobol?) program which was actually called during a particular batch run with a particular set of data?

What will you use the information for?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Sat Jan 14, 2012 7:29 pm    Post subject: Reply to: COBOL Call Trace at runtime
Reply with quote

Mike,

Have you looked into IBM DebugTool?

I also found the following after Googling, which refers to READY TRACE (which I thought had been removed from the compiler after the introduction of VS/COBOL II) and its usage in Enterprise COBOL 3.4 -

http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic=%2Fcom.ibm.entcobol.doc_3.4%2Frlcdsrea.htm

Mr. Bill
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7235

PostPosted: Sat Jan 14, 2012 7:51 pm    Post subject: Reply to: COBOL Call Trace at runtime
Reply with quote

Looks lie there is an "exit" program provide by LE, used during program initialisation. Maybe if you wrote a little bit of Assembler for that (or C or PL/I, but not Cobol) you'd get something. I haven't looked at the parameters, cos I don't know what you want, but you might be able to get all the dynamic calls that way (what the parameters might also tell you is what did the calling).

There must be, somewhere in storage, a list of program names/addresses, but wouldn't give indicate who called, I'd guess.
Back to top
View user's profile Send private message
Mike 1304

New User


Joined: 15 Oct 2011
Posts: 43
Location: Germany

PostPosted: Sun Jan 15, 2012 12:48 am    Post subject:
Reply with quote

Hi,

thanks for your answers!

Changing compile options of the related programs is not a solution:
I'm not the owner of these programs and I think there where > 3.000 programs involved.
That's the reason why I want to see, what happens in this adress space.

The LE exit sounds good!
Where can I find more information about it?
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7235

PostPosted: Sun Jan 15, 2012 1:07 am    Post subject: Reply to: COBOL Call Trace at runtime
Reply with quote

Well, I googled.

Got to here and then some more clicks, but I haven't followed them.

It would look like you'd get every LE module (Cobol and non-Cobol) when they are initialised. So if you have A and B calling C, I don't think it would give you the connection A->C, but should at least give you all the modules called. The exit would be invoked for dynamic and non-dynamic calls, I imagine. If you can't tell directly, it might still be possible to know, but don't know if it is a problem for you anyway, beacause...

...we still don't know what you want them for. The more we know, the better the answers can be.
Back to top
View user's profile Send private message
Mike 1304

New User


Joined: 15 Oct 2011
Posts: 43
Location: Germany

PostPosted: Sun Jan 15, 2012 1:21 am    Post subject:
Reply with quote

Ok, ok,

My problem is, that the over all consumption of CPU and I/O should be reduced.
Environment and system tuning is not my focus.

Though I want to see what is happening and then think about an improvement.

e.g. If there are repeated calls with a very long path, which gets always the same information, I'll tell the responsible to store the last x results on the top of the path and use them to satisfy the following calls.

It's only a example, my action depends on the results of the trace.

Now I first want to read your google result...
Back to top
View user's profile Send private message
Mike 1304

New User


Joined: 15 Oct 2011
Posts: 43
Location: Germany

PostPosted: Sun Jan 15, 2012 1:42 am    Post subject:
Reply with quote

Hi,

I understood, that there is a module CEEBINT, which is called on every module "initialisation". It just returns to the caller.
I can replace this module by an LE conforming assembler module.

But the description of the parameters in
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/topic/com.ibm.zos.r9.ceea200/clcaexa.htm?resultof=%22%63%65%65%62%69%6e%74%22%20

does not tell me how I can get the name of the caller, the name of the called program and the parameters given to it.


Additional question:
Is the "initialisation" of a module only the first call of it?
I need to get control on every call, even if it is the 2nd or 3rd one.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 641
Location: Whitby, ON, Canada

PostPosted: Sun Jan 15, 2012 4:29 am    Post subject: Re: Reply to: COBOL Call Trace at runtime
Reply with quote

Bill O'Boyle wrote:
Mike,

Have you looked into IBM DebugTool?

I also found the following after Googling, which refers to READY TRACE (which I thought had been removed from the compiler after the introduction of VS/COBOL II) and its usage in Enterprise COBOL 3.4 -

http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic=%2Fcom.ibm.entcobol.doc_3.4%2Frlcdsrea.htm

Mr. Bill
So had I. I read the reference, and it uses the phrase "has no effect on your program". This usually means that the statement is tolerated, but treated as a comment. I must admit I haven't tried it though. I was never a fan of READY TRACE even back in the old days. I preferred to use a few well-chosen DISPLAY statements rather than wade through the reams of output produced by READY TRACE.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7235

PostPosted: Sun Jan 15, 2012 5:09 am    Post subject:
Reply with quote

Mike 1304 wrote:
Hi,

I understood, that there is a module CEEBINT, which is called on every module "initialisation". It just returns to the caller.
I can replace this module by an LE conforming assembler module.


That is how I understand it. I've not done it.


Quote:
But the description of the parameters in
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/topic/com.ibm.zos.r9.ceea200/clcaexa.htm?resultof=%22%63%65%65%62%69%6e%74%22%20

does not tell me how I can get the name of the caller, the name of the called program and the parameters given to it.



Why do you think it would be likely to give you everything you want on a plate :-) That would have been some co-incidence.

For the name of the called program, you have the address of the entry-point, it shiould be OK from that. Name of the caller? I assume the calling-chain is normal if you want to go back and find who called, I think it would be possible. You want to find the items passed from caller to called? First time you've mentioned that. What would you do with them?

Quote:
Additional question:
Is the "initialisation" of a module only the first call of it?
I need to get control on every call, even if it is the 2nd or 3rd one.


I first thought when writing earlier that this would be a "once-only" thing. Here at the moment I make an assumption. In that you can return the program to its' initial state, if you want to, for each call, and this is code to do with "init" then I'd go for on each call. Also, looking at a dump from a distance a few weeks ago, which was failing in the init code on the third call to a program, supports that idea. Must be something in either the Cobol manuals or the LE manuals to confirm how it works. Is it down to me to check it? :-)

I think again we need some more detail. Do you have a mix of languages, and if so which? From Cobol, are they CALL literal, with compiler option DYNAM, or CALL identifier? What do you want to do with the knowledge of data passed between the programs, if you can identify it (in the "old" days the last parameter had x'80' in the high-order byte of its address - AMODE gets in the way now, I guess, I haven't looked for a while). Anything else you think might help.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Sun Jan 15, 2012 11:10 am    Post subject:
Reply with quote

Hello,

If you have 3000 modules, suggest you do a bit of SMF analysis (possibly this already exists - most organizations have reports that are run regularly).

From your populaton of 3000, look for the top 10 users of reasources you want to track (i.e. cpu, i/o, elapsed time, etc). Then look at these more closely and determine where/how they can be improved.

You might want to separate the analysis between processes that use database and those that do not.
Back to top
View user's profile Send private message
Mike 1304

New User


Joined: 15 Oct 2011
Posts: 43
Location: Germany

PostPosted: Sun Jan 15, 2012 1:54 pm    Post subject:
Reply with quote

Bill Woodger wrote:
You want to find the items passed from caller to called? First time you've mentioned that. What would you do with them?

It's just another way to see, what's happening in the adress space.
If not possible, I have to read the coding.
But like caller and called module, I think normal chain und register usage will lead me to the needed information.

Thanks so far!

Quote:
Additional question:
Is the "initialisation" of a module only the first call of it?
I need to get control on every call, even if it is the 2nd or 3rd one.


Bill Woodger wrote:
I first thought when writing earlier that this would be a "once-only" thing. Here at the moment I make an assumption. In that you can return the program to its' initial state, if you want to, for each call, and this is code to do with "init" then I'd go for on each call. Also, looking at a dump from a distance a few weeks ago, which was failing in the init code on the third call to a program, supports that idea. Must be something in either the Cobol manuals or the LE manuals to confirm how it works. Is it down to me to check it? :-).

Sorry, I did not get the message!
Is CEEBINT called on every call of a module or only on the first call?

Bill Woodger wrote:

I think again we need some more detail. Do you have a mix of languages, and if so which? From Cobol, are they CALL literal, with compiler option DYNAM, or CALL identifier? .


Maybe, there are also some Assembler Programs, but I do not want to have a look on them.
All Calls are dynamic, mixed literal and identifier with DYNAM option.
Back to top
View user's profile Send private message
Mike 1304

New User


Joined: 15 Oct 2011
Posts: 43
Location: Germany

PostPosted: Sun Jan 15, 2012 2:32 pm    Post subject:
Reply with quote

dick scherrer wrote:
Hello,

If you have 3000 modules, suggest you do a bit of SMF analysis (possibly this already exists - most organizations have reports that are run regularly).

From your populaton of 3000, look for the top 10 users of reasources you want to track (i.e. cpu, i/o, elapsed time, etc). Then look at these more closely and determine where/how they can be improved.

You might want to separate the analysis between processes that use database and those that do not.


Hi Dick,

thanks for your answer!

I have to tell again more details:

Colleagues of me are looking on the performance from system side,
my job is only to look from application programmers side.

Other colleagues have already looked at the application to find the top consumer of CPU and DB2 load, but they told me every statement is ok,
the problem is the heavy use of all this modules.

So, the situation is:
Environment / system is optimized, all code is optimized and I have still to improve the performance.
(of course everything could be done better, but the most benefits are already taken).

I'm also aware, that splitting an application in small modules and call them dynamically is not good for performance.
But this is what we want to do from our architectual point of view.

I want to look on the calls, maybe I notice something unusual/important/interesting.

I have 2 ideas so far what could be found:
1. Maybe there are multiple equal calls to big functions,
where already the first call returns the results needed.
So we can avoid all additional following calls without changing the business logic.

2. If a module is only used by 1 other module, nested program could be a solution


If there are any other ideas, what could be wrong with this application,
or other ways to look on it to find something.... I'm very interested in!
    Back to top
    View user's profile Send private message
    Bill Woodger

    DFSORT Moderator


    Joined: 09 Mar 2011
    Posts: 7235

    PostPosted: Sun Jan 15, 2012 3:00 pm    Post subject:
    Reply with quote

    Mike 1304 wrote:
    Bill Woodger wrote:
    You want to find the items passed from caller to called? First time you've mentioned that. What would you do with them?

    It's just another way to see, what's happening in the adress space.
    If not possible, I have to read the coding.
    But like caller and called module, I think normal chain und register usage will lead me to the needed information.

    Thanks so far!



    What I dont' know these days is how to reliably identify the final item for a call, to put it another way, can you tell from the object/load how many items are passed to the called module?

    Quote:
    Additional question:
    Is the "initialisation" of a module only the first call of it?
    I need to get control on every call, even if it is the 2nd or 3rd one.



    Quote:
    Bill Woodger wrote:
    I first thought when writing earlier that this would be a "once-only" thing. Here at the moment I make an assumption. In that you can return the program to its' initial state, if you want to, for each call, and this is code to do with "init" then I'd go for on each call. Also, looking at a dump from a distance a few weeks ago, which was failing in the init code on the third call to a program, supports that idea. Must be something in either the Cobol manuals or the LE manuals to confirm how it works. Is it down to me to check it? :-).

    Sorry, I did not get the message!
    Is CEEBINT called on every call of a module or only on the first call?


    I dont' know, but I think CEEBINT will be called on every call. One of the manuals should confirm somewhere. Or "dummy it up" with a basic Cobol call Cobol set-up and a small version of the exit, and see what happens.

    Bill Woodger wrote:

    I think again we need some more detail. Do you have a mix of languages, and if so which? From Cobol, are they CALL literal, with compiler option DYNAM, or CALL identifier? .


    Maybe, there are also some Assembler Programs, but I do not want to have a look on them.
    All Calls are dynamic, mixed literal and identifier with DYNAM option.[/quote]

    Pity they are not all literal, as that would give you another possibility.
    Back to top
    View user's profile Send private message
    dbzTHEdinosauer

    Global Moderator


    Joined: 20 Oct 2006
    Posts: 6966
    Location: porcelain throne

    PostPosted: Sun Jan 15, 2012 6:25 pm    Post subject:
    Reply with quote

    nested modules is just another word for spaghetti code.
    Back to top
    View user's profile Send private message
    enrico-sorichetti

    Global Moderator


    Joined: 14 Mar 2007
    Posts: 10202
    Location: italy

    PostPosted: Sun Jan 15, 2012 8:14 pm    Post subject: Reply to: COBOL Call Trace at runtime
    Reply with quote

    Quote:
    Environment / system is optimized, all code is optimized and I have still to improve the performance.

    good luck icon_cool.gif
    Back to top
    View user's profile Send private message
    Mike 1304

    New User


    Joined: 15 Oct 2011
    Posts: 43
    Location: Germany

    PostPosted: Sun Jan 15, 2012 9:10 pm    Post subject: Re: Reply to: COBOL Call Trace at runtime
    Reply with quote

    enrico-sorichetti wrote:
    Quote:
    Environment / system is optimized, all code is optimized and I have still to improve the performance.

    good luck icon_cool.gif


    Oh I think, if a task is easy, it is not an interesting task for me,
    and also not a reason to post in this forum!
    Back to top
    View user's profile Send private message
    Mike 1304

    New User


    Joined: 15 Oct 2011
    Posts: 43
    Location: Germany

    PostPosted: Sun Jan 15, 2012 9:26 pm    Post subject:
    Reply with quote

    I think the high-order bit is still used today, otherwise i'll check for BALR R14,R15 and BASSM R14,R15 behind the last parameter.
    Back to top
    View user's profile Send private message
    Robert Sample

    Global Moderator


    Joined: 06 Jun 2008
    Posts: 7913
    Location: Bellevue, IA

    PostPosted: Sun Jan 15, 2012 9:35 pm    Post subject:
    Reply with quote

    You DO realize, I hope, that if the environment and code are optimized (a statement I, personally, would be very reluctant to make since there's a HUGE difference between optimized code and code that someone has worked on to improve performance), then your stated goal of improving performance most likely will turn out to be impossible. With optimized code and environment, your only real chance of improving performance will be to acquire faster hardware (if any is available).

    Are you looking at CPU-bound processes or I/O-bound processes? If you do not know, then by definition you must find out which before you can make any improvements, at all. After all, you don't want to spend 2 months changing the algorithm to improve performance only to find the process is I/O-bound and hence there's not one iota of improvement from implementing the new algorithm.
    Back to top
    View user's profile Send private message
    Bill Woodger

    DFSORT Moderator


    Joined: 09 Mar 2011
    Posts: 7235

    PostPosted: Mon Jan 16, 2012 5:32 am    Post subject:
    Reply with quote

    Mike 1304 wrote:
    [...]

    I have to tell again more details:

    Colleagues of me are looking on the performance from system side,
    my job is only to look from application programmers side.

    Other colleagues have already looked at the application to find the top consumer of CPU and DB2 load, but they told me every statement is ok,
    the problem is the heavy use of all this modules.

    So, the situation is:
    Environment / system is optimized, all code is optimized and I have still to improve the performance.
    (of course everything could be done better, but the most benefits are already taken).

    I'm also aware, that splitting an application in small modules and call them dynamically is not good for performance.
    But this is what we want to do from our architectual point of view.



    Sometimes we have to be careful about what we "know". As referred to in the IBM Cobol Performance Tuning paper, a Dynamic uses up to 40% more CPU than s Static call. Don't get all excited about it until you've checked what it means. The testing for the paper was done with CALL to a module which just issued a GOBACK, nothing else. The Dynamic call I believes goes through a Cobol or LE module each time, the Static call does not. With not-an-awful-lot-of-instructions-involved, 40% doesn't amount to much, it sounds more like a quote from Benjamin Disraeli.

    To see the effect of the modules on your system, I'd estimate how many calls are done in a run (doesn't have to be too close). Then "dummy it up". A stub-program calling a sub-program, the estimated number of times. Run it wiht NODYNAM. Run it with DYNAM. That will give you a figure for the CPU "overhead" of the Dynamic calls over Static calls, and calls over no calls. I'd be surprised if there was much to write home about in terms of gross cpu usage that could be reduced just from the calls (I know that you are looking at other things). Any IO here, you couldn't do much about.

    Presumably at the top of the hierachy is some sort of sizable control program. For fun, I'd run that, amended so it does no calls. That would give you basic IO and CPU.

    If the DB2 guys are so sure, they may be able to give you some idea of CPU usage/IO usage for the DB2 accesses.

    You then have a basic "pot" which is (mostly) out of your equation (I'd peruse the control program for dumbities). You'd have some idea of what part of the CPU/IO you might be able to have an impact on.

    The rest of the stuff is code that is going to run, whether called or inlined.

    Quote:

    I want to look on the calls, maybe I notice something unusual/important/interesting.

    I have 2 ideas so far what could be found:
    1. Maybe there are multiple equal calls to big functions,
    where already the first call returns the results needed.
    So we can avoid all additional following calls without changing the business logic.

    2. If a module is only used by 1 other module, nested program could be a solution


    If there are any other ideas, what could be wrong with this application,
    or other ways to look on it to find something.... I'm very interested in!


    We can have many ideas. Without knowing what you know about the system, and more, it could be mostly idle banter.

    As has been pointed out, we don't know if IO-bound or CPU-bound. If your colleagues are to be believed fully, I guess CPU-bound, but we don't know.

    Are you happy with all the compile options? Presumably you'd avoid these for


    1. Having to recompile 3000 modules
    2. Having to test a system of 3000 modules
    3. There are always three things


    But if you can't change everything (costs, manpower, time expended, etc) then you have to identify the "heavy hitters". If you identify the sort of duplicated-request-thing you are hoping for, it is no use changing it if it is only used 100,000 times when the "heavy hitters" are executed several million times.

    If you can change everything, show us the compile options at the moment.

    Otherwise, identify the heavy hitters, you might see problems there, and run them by us for conftimation (or not).

    If may be something generally wrong with all the modules, if they are done in such a way as to be somehow "inefficient" (can be done). If you are thinking of that, show us a couple of (small) example programs which are representative of large numbers of the called programs. Better yet, test the examples by comparing "inlinded" to "called" and let us know if there is a significant saving on CPU (remember, with the small module approach, you are (hopefully) reducing maintenance/development time and it need not be only CPU usage taken into consideration).

    When you find something "suspect" you really have to quantify its use before doing anything about it.

    At some point it might dawn on us that you are getting an amount of free consultation. I'll assume you site is German-speaking, so I'm not really potentially missing-out :-)
    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
    Goto page 1, 2  Next
    Page 1 of 2

     

    Search our Forum:

    Similar Topics
    Topic Author Forum Replies Posted
    No new posts DUMP DATASETS VS TRACE DATASETS! lind sh CICS 4 Tue Dec 06, 2016 11:31 pm
    No new posts I can not compile my program PL1 V3.R... Miguel Fernandez PL/I & Assembler 13 Tue Dec 06, 2016 8:30 pm
    No new posts What is the code in CLIST to enable t... jackzhang75 CLIST & REXX 1 Fri Dec 02, 2016 3:02 am
    No new posts IMS BMP program causes 878 system abend Artemk IMS DB/DC 7 Tue Nov 22, 2016 8:26 pm
    This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm


    Facebook
    Back to Top
     
    Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us