In CICS to call a cics subprogram we will use LINK / XCTL commands.
Shall we achive the same result using cobol CALL(static or dynamic) in CICS program?
If so ,what is difference between in Cobol CALL and LINK / XCTL commands and which is efficient?
Joined: 05 May 2005 Posts: 98 Location: Navi Mumbai, India
Call statement can be said to be similar to LINK since both transfer control at Lower logical Level whereas XCTL transfers control at the same level. Also in CALL the control must transfer to the calling program like LINK but unlike XCTL. In CICS, information is passed to the called pgm through DFHCOMMAREA alongwith lenght of data. XCTL command requires fewer overheads, hence its performance is relatively better in comparison to the LINK command. Also, the calling program does not expect control to be returned.
Hope this helps,
to call a subprogram in cics we can use CALL statement.
but the subprogram must be declared in PPT TABLE. and subprogram calling using CALL statement in CICS only possible in VS COBOLII i.e.
we can't use this cobol 74
Definitely we can use CALL instead of LINK. However, it can not be replacement for XCTL. Use of Dynamic CALL is preferred over STATIC CALL for a host of reasons.
Assuming Dynamic CALL, the differences are -
1. CALL gives a better performance over LINK. The reason being CALL executes in the same run unit of the main program, wehre as LINK runs in a separate run unit.
2. CALL can be used to transfer more than 32K between the calling and called programs.
3. CALL can transfer multiple data elements, where as LINK can transfer only one. (DFHCOMMAREA)
4. CALL can be used only with-in a single CICS region, where as LINK can be used to transfer control across regions.
LINK was created to support some thing similar to CALL in VS COBOL.
Actually there are three ways to call a subprogram:
1. Using Call statement
2. Using Link Statement
3. Using XCTL statement.
If you are using the Call statement, then everytime at the compilation time you have to link edit to the called program. And every calling program will have its own copy of the called program. For example : ProgA, ProgB, ProgC are the calling program and all of them call ProgD. In this case, there will be 3 copies of ProgD for each of the calling program i.e ProgA, ProgB and ProgC.
On the other hand, if you use either Link or XCTL statement, only one copy of ProgD will be distributed and shared among the calling programs ProgA, ProgB and ProgC. As in CICS, programs are re-enterrant, therefore every program will have its own area of the called program but there would be only one and single copy of the called program shared by all of the calling programs.
So the difference in terms of efficiency. No doubt, in Call you will get more efficiency as every called program will have its own copy of the called program but it will be at a great cost to the CICS system in term of resources. So better use Link and XCTL unless the called program is used very frequently.
I hope this information will be enough to clear your doubts. Still if someone has any input, please let me know.
Joined: 23 Mar 2007 Posts: 149 Location: Ottawa Canada
Sarma covers the differences between CALL and LINK very well.
Here are a few more factors to consider.
As Sarma suggests, LINK establishes a new unit. CALL does not. Our experiences shows that a LINK and a first-time CALL cost about the same: 250 microseconds (this will vary but this is the number we generally use).
However, the cost of subsequent CALLs within the same run unit are dirt cheap - about 40 microseconds. But the cost of LINK is always the same. So if you are calling the same subprogram repeatedly the use of CALL might produce a measurable benefit.
But keep in mind how long 250 microseconds is. There are 1,000,000 microseconds in a second. So it takes 4000 times 250 microseconds to equal 1 second. So if you only loop 10 times or 100 times, then don't expect a big savings. Your time is much, much better spent making sure your SQL is coded correctly.
Beware of CALL. The working storages of the subprograms you call will accumulate and this could significantly increase the memory your transaction uses. It can drive your storage high-water mark right up.
Working storage that belongs to a LINKed program will be released when that program returns to its LINKER. So the use of LINK will reduce your storage consumption - nice and tidy. It cleans up after itself.
CALL on the other hand is a storage slob.
Working storages of called programs are only FREEMAINed when the run unit collapses. That typically happens when you return from a LINK. It doesn't happen when you return from a CALL.
Once you know that CALLed programs have working storages that will stay intact from one call to the next (as long as the run unit has not collapsed) you can use that to your advantage. You can use your working storage as a data cache. When you call the same program you can reuse the same data and avoid having to retrieve it from the database. This is perhaps the best reason to favour CALL over LINK.
If you are fond of the CICS debugger CEDF then you may also know that it doesn't show CALL activity but does show LINKs. One tiny reason to favour LINK over CALL.
If you use Auxtrace, you may be aware that it does not report very well on CALL statements (you see the CALL but at times the identity of the called program does not show). However, Auxtrace has no such problem when reporting on LINKs. Another tiny reason to favour LINK over CALL.
Our debugger has trouble with CALLed programs.
Sometimes LINK is better than CALL.
Sometimes CALL is better than LINK.
What I tell people is this: Use LINK as the default unless you have a compelling reason to use CALL.
Joined: 23 Mar 2007 Posts: 149 Location: Ottawa Canada
1. In my previous post, when I talk about CALL I should have made it clear that I'm talking about a dynamic CALL. Where I work, we almost never use STATIC calls.
STATIC calls are more difficult to manage and thus hardly worth the extra performance they produce. Of course there are exceptions. One problem with STATIC calls is that when you modify your sub-program, you are forced to recompile all programs that call it. That is a pain and can be error-prone.
My suggestion: Always use dynamic CALL unless you have a compelling reason to use STATIC call.
2. The issues I discussed in my previous post are more important withi complicated transactions.
3. I forgot to mention this: I have seen transactions that use a mix of LINKs and CALLs and these transactions can really consume a ton of memory. For example, let's say we have 3 programs A, B and C.
A calls C, C returns to A
A links to B
B calls C
At this point, there are 4 instances of working storage allocated - not 3. There is 1 allocation for A, 1 for B and 2 for C. C gets allocated twice because it participates in 2 different run units.
I have actually seen scenarios where a single program had 6 allocations of its working storage with a given task. And this happens due to a bad mix of LINKs and CALLs.
In my simple example above, if CALL was used exclusively there would only be 3 working storages allocated.
4. In my previous post I did not focus on XCTL. We only use XCTL to navigate from one screen to the next. In other words, we only use it in our presentation layer - never in our business layer.
There is an alternative to XCTL. It is RETURN IMMEDIATE. If you are navigating to a transaction that belongs to a different system and runs under a different DB2 Plan, then you will want to use RETURN IMMEDIATE instead of XCTL. RETURN IMMEDIATE will cause the TRAN ID to flip immediately - thus when control is transfered to your new screen, it will be running under its own plan from the get-go.