Difference between Cobol CALL and CICS LINK / XCTL

vbhat · New User Joined: 29 Apr 2005 Posts: 38

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?

thanks

vbhat

ankyhunk · Posted: Thu May 05, 2005 5:03 pm

Hi,
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,
Cheers,
Ankur

kriss · New User Joined: 17 May 2005 Posts: 2

hi,
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

sarma Kappagantu · New User Joined: 17 Mar 2005 Posts: 22 Location: Bangalore

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.

Regards,
Sarma.

Abhishek_kumar_81 · New User Joined: 03 Jun 2005 Posts: 4

Hi,
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.

Thanks,
Abhishek

sarma Kappagantu · New User Joined: 17 Mar 2005 Posts: 22 Location: Bangalore

Hi,

What you said is correct w.r.t STATIC CALL. However, it is not so with dynamic call.

I suggest a simple test. Assume PGMA is calling PGMB.

1. Create and compile PGMA. (It calls PGMB. However, PGMB is not yet compiled. If it compiles then assumption of copy is incorrect.)

2. Crate and compile PGMB.

3. Execute and test the programs.

4. Modify and compile only PGMB.

5. Execute and test the programs. (If the new bheaviour is displayed by the new set of programs ... again ...).

However, don't forget to use ...

MOVE 'PGMB' TO MY-PGM-NAME (Where MY-PGM-NAME is PIC X(08) )
CALL MY-PGM-NAME USING X, Y, Z

Instead, if you use ... CALL 'PGMB' USING X, Y, Z; it will be a static call.

Regards,
Sarma.

Quimetb · New User Joined: 26 Jan 2007 Posts: 2 Location: S?o Paulo

Hi,

I have doubts about how to decide what is better.

I think that if my only requirement is the best performance, the best solution is CALL.

Other reason to use CALL?

If my principal requirement is the minimum cost for the CICS, it?s better use EXEC CICS LINK, principally for a better management of memory.

This is correct?

Aside from this, I think that the use of EXEC CICS LINK also it brings other advantages due to the management of CICS.
Anyone can explain this advantages?

Thanks!!!

rameshfoa · New User Joined: 05 Apr 2007 Posts: 27 Location: chennai

Hi All,

The main difference is here....

"you can use the LINK command to invoke a program on either a local or a remote system. A Call statement can only invoke a program on a local system "

Please refer following link for more detaqils....

ibmmainframes.com/viewtopic.php?t=20391

agkshirsagar · Posted: Mon May 07, 2007 6:55 pm

Ramesh,
Could you please share the source of your information. A URL/Reference name will be good.
I am not clear with what you are referring with a 'Remote system'?

William Thompson · Posted: Mon May 07, 2007 7:05 pm

agkshirsagar · Posted: Mon May 07, 2007 7:58 pm

Ok. From the link given above I could understand, 'remote system' means a different cics region.
Thanks.

TG Murphy · Posted: Tue May 08, 2007 2:00 am

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.

TG Murphy · Posted: Wed May 09, 2007 6:30 pm

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.