The wave in the company I work is to replace any little function in the program for another program, and access this new program through a CALL command.
This way, the number of CALLs in programs are increasing dramatically.
My questions: how harmful is the CALL command in terms of performance? Does it impact significantly the execution of a batch application? How about an online application? Does it cost the same as a PERFORM? Should I care about it?
I made some measurements and couldn't perceive any difference.
It really depends on the environment and the type of call. If the CALL is going to an external program and there are many parameters then the setup and linkage can be fairly expensive. If the call is not to the same load module (static?) then the system has to search the job pack area, possibly the link list and LPA as well. But even if it is local, the call can be more expensive than a local subroutine because the called program is probably going to do a getmain/freemain or similar to get/free working storage. It is very unlikely that your measurements will see a difference, but scaled up to many jobs, it can significantly affect performance system wide if the system is heavily loaded and the calls are frequent enough. I've seen (more to the point, I've caused) severe problems by making frequent calls to small modules. But that was 20 years ago and processors are much faster now.
I will point out that this tendency to use lots of small programs seems to come from people who have programming experience in languages that use a stack and heap ratherthan the z/OS memory model. In C, for example getting storage is just a single pointer increment pointing into the stack. Hence the fact that a zillion little routines are used in C doesn't really matter. MVS isn't that simple. In most cases it is very efficient, but not as efficient as a simple stack or heap.
Performance considerations for using CALLs (measuring CALL overhead only):
CALL to nested programs was 50% to 60% faster than static CALL.
Static CALL literal was 45% to 55% faster than dynamic CALL literal.
Static CALL literal was 60% to 65% faster than dynamic CALL identifier.
18 IBM Enterprise COBOL Version 3 Release 1 Performance Tuning
Dynamic CALL literal was 15% to 25% faster than dynamic CALL identifier.
Note: These tests measured only the overhead of the CALL (i.e., the subprogram did only a GOBACK);
thus, a full application that does more work in the subprograms may have different results.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
As the paper mentions, there is some different % improvement when different choices are made. Unfortunately, this does not provide much for making a decision.
If the CALLs used in a process use only an unmeasurable amount of overhead, a 60 (or even 80) percent improvement will still probably not be measurable. . .
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Years ago, I had experimented with PROCEDURE-POINTER in Batch, which loads (under the covers) the target dynamic sub-program into memory (very similar to an MVS LOAD Macro). The given sub-program was Called millions of times from the Batch caller and I was looking for some CPU reduction.
Afterwards, I used the entry point address (the PROCEDURE-POINTER value) in the CALL instead of the sub-program name and it resulted in less CPU.
In 2008, I met an IBM COBOL compiler guy at Share-Orlando and explained this to him. His reply was "must have hit some Blue code", which I took as undocumented IBM logic.
PROCEDURE-POINTER should NEVER be used in CICS. Instead, use the LOAD PROGRAM API.
PROCEDURE-POINTER was introduced with COBOL/370, in the early 1990's.
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Quote:
I made some measurements and couldn't perceive any difference.
Not surprising -- I wouldn't expect a large difference for as many as several thousand CALL statements. For a few million executions, I would expect to start seeing some big differences -- possibly affecting the batch window. I've got a test program that adds 1 to a counter 10 million times. Our z800 runs this COBOL code in 3 seconds (.05 minutes) of CPU time, and z10 machines are 6 times faster. Unless your measurements were carefully designed and measuring millions of operations, you're not likely to see enough difference to be able to notice it.
Years ago, I had experimented with PROCEDURE-POINTER in Batch, which loads (under the covers) the target dynamic sub-program into memory (very similar to an MVS LOAD Macro). The given sub-program was Called millions of times from the Batch caller and I was looking for some CPU reduction.
Afterwards, I used the entry point address (the PROCEDURE-POINTER value) in the CALL instead of the sub-program name and it resulted in less CPU.
In 2008, I met an IBM COBOL compiler guy at Share-Orlando and explained this to him. His reply was "must have hit some Blue code", which I took as undocumented IBM logic.
PROCEDURE-POINTER should NEVER be used in CICS. Instead, use the LOAD PROGRAM API.
PROCEDURE-POINTER was introduced with COBOL/370, in the early 1990's.
Bill
When you say "procedure-pointer" do you mean "entry-points" in the procedure divison?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Yes, using PROCEDURE-POINTER will return the main entry point of the target program (CSECT) and should NOT be confused with POINTER, which was introduced with VS/COBOL II in the mid/late 1980's.
However, I'm unsure whether you can use PROCEDURE-POINTER to return an alternate entry-point. I guess it would depend on the target ENTRY value in the actual SET PROCEDURE-POINTER statement.
Substituting a sub-program, which issued an MVS LOAD Macro with a PROCEDURE-POINTER, did make life easier in shops where Assembler expertise had dwindled or had become non-existent.
Using PROCEDURE-POINTER to reduce CPU (in the above experiment) was a yield which was not anticipated, but was certainly welcomed.
Performance considerations for using CALLs (measuring CALL overhead only):
CALL to nested programs was 50% to 60% faster than static CALL.
Static CALL literal was 45% to 55% faster than dynamic CALL literal.
Static CALL literal was 60% to 65% faster than dynamic CALL identifier.
18 IBM Enterprise COBOL Version 3 Release 1 Performance Tuning
Dynamic CALL literal was 15% to 25% faster than dynamic CALL identifier.
Note: These tests measured only the overhead of the CALL (i.e., the subprogram did only a GOBACK);
thus, a full application that does more work in the subprograms may have different results.
The text above mentions "dynamic call literal".
I wonder if they are talking about the call to a subprogram which name is between quotes, and the caller has the compiler option DYNAMIC. Example:
However, I'm unsure whether you can use PROCEDURE-POINTER to return an alternate entry-point. I guess it would depend on the target ENTRY value in the actual SET PROCEDURE-POINTER statement.
Bill,
Your level of expertise is to high for me.
I wonder if you're suggesting that calling entry-points is faster than calling the program-id.
If so, it's going to be very useful for us because we:
1-call the subprogram program-id;
2-test the function code passed to the subprogram;
3-execute only a section of the subprogram;
4-go back to the caller.
Called subprogarm procedure divison:
Code:
PROCEDURE DIVISON.
EVALUETE FUNCTION-CODE
WHEN 01
PERFORM FUNCTION-01
WHEN 02
PERFORM FUNCTION-02
WHEN ...
END-EVALUATE.
GOBACK.
FUNCTION-01 SECTION.
...
FUNCTION-02 SECTION.
...
FUNCTION... SECTION.
...
We have many applications with a very bad performance. Most of the problem is due to DB2 access but I suspect that a good amount of this is caused by massive use dynamic calls.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
As you've surmised, there can be a big difference in CALL-Time between a Statically Called and Dynamically-Called sub-program, with Statically Called being much more efficient, but with potential issues.
Statically Called sub-programs are merged together with the Caller, forming a single load-module, whereas, Dynamically Called sub-programs are separate load-modules.
It really comes down to maintenance and the number of potential times a sub-program is changed.
If the sub-program is changed infrequently, then it could be a candidate for a Static Call, whereas, if the sub-program is changed on a regular basis, then it would probably make more sense that it should be Called Dynamically.
However, if you're using sub-programs in a dual-mode environment, where they can be called in both Batch and CICS (no CICS commands in the given sub-program) and the CICS Call is Static, then WS needs to be passed by the serially-reusable Caller, for use by the sub-program. By doing this, you'll eliminate one issue (probably of many) of migrating your applications to Threadsafe/OpenAPI, which is IBM's statement of direction for CICS.
But, if the parmlist can't be changed and you would like to be Threadsafe compliant in a Static Call environment, then review EXTERNAL storage, which was introduced with VS/COBOL II about 20 years ago. External storage allows all program's in the run-unit (all programs associated with a given transaction) to access this same EXTERNAL storage.
Statically Called sub-programs, which don't contain reentrant-storage, cannot be made Threadsafe compliant (multiple TCB's accessing the sub-program concurrently) until the storage is deemed reentrant. Otherwise, many "opportunities" will be raised and you would want to avoid these.
Statically Called COBOL programs, which don't utilize reentrant WS are akin to Called Assembler sub-programs (regardless whether they are Static or Dynamic). You can certainly pass COBOL WS to an Assembler sub-program. Note that this "heads-up" is for CICS environments only as Batch environments shouldn't have these issues.
In addition, regardless whether a CICS sub-program is called Dynamically or Statically, it inherits the PPT characteristics of the Caller. So, if the Caller is defined as Threadsafe, all sub-programs accessed by the Caller must be Threadsafe compliant as well.
