Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
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 -
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
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?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
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.
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.
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.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
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 -
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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
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.
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
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.
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.
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!
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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
Having to recompile 3000 modules
Having to test a system of 3000 modules
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 :-)
At my client's site they use STROBE (by Compuware) to analyze and measure all kinds of metrics. You should ask your system guys whether there is this tool or a similar one available.
