IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Difference between Cobol CALL and CICS LINK / XCTL


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
vbhat

New User


Joined: 29 Apr 2005
Posts: 38

PostPosted: Thu May 05, 2005 3:13 pm
Reply with quote

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
Back to top
View user's profile Send private message
ankyhunk

Moderator


Joined: 05 May 2005
Posts: 98
Location: Navi Mumbai, India

PostPosted: Thu May 05, 2005 5:03 pm
Reply with quote

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
Back to top
View user's profile Send private message
kriss

New User


Joined: 17 May 2005
Posts: 2

PostPosted: Thu May 19, 2005 8:08 pm
Reply with quote

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
Back to top
View user's profile Send private message
sarma Kappagantu

New User


Joined: 17 Mar 2005
Posts: 22
Location: Bangalore

PostPosted: Sat May 21, 2005 12:02 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Abhishek_kumar_81

New User


Joined: 03 Jun 2005
Posts: 4

PostPosted: Fri Jun 03, 2005 5:23 pm
Reply with quote

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
Back to top
View user's profile Send private message
sarma Kappagantu

New User


Joined: 17 Mar 2005
Posts: 22
Location: Bangalore

PostPosted: Sun Jun 05, 2005 4:13 am
Reply with quote

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.
Back to top
View user's profile Send private message
Quimetb

New User


Joined: 26 Jan 2007
Posts: 2
Location: S?o Paulo

PostPosted: Fri May 04, 2007 2:00 am
Reply with quote

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!!!
Back to top
View user's profile Send private message
rameshfoa

New User


Joined: 05 Apr 2007
Posts: 27
Location: chennai

PostPosted: Mon May 07, 2007 1:48 pm
Reply with quote

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 " icon_cool.gif

Please refer following link for more detaqils....

ibmmainframes.com/viewtopic.php?t=20391
Back to top
View user's profile Send private message
agkshirsagar

Active Member


Joined: 27 Feb 2007
Posts: 691
Location: Earth

PostPosted: Mon May 07, 2007 6:55 pm
Reply with quote

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'?
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Mon May 07, 2007 7:05 pm
Reply with quote

agkshirsagar wrote:
I am not clear with what you are referring with a 'Remote system'?
A remote CICS.
REMOTESYSTEM(connection) & REMOTENAME(program)
Back to top
View user's profile Send private message
agkshirsagar

Active Member


Joined: 27 Feb 2007
Posts: 691
Location: Earth

PostPosted: Mon May 07, 2007 7:58 pm
Reply with quote

Ok. From the link given above I could understand, 'remote system' means a different cics region.
Thanks.
Back to top
View user's profile Send private message
TG Murphy

Active User


Joined: 23 Mar 2007
Posts: 148
Location: Ottawa Canada

PostPosted: Tue May 08, 2007 2:00 am
Reply with quote

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.
Back to top
View user's profile Send private message
TG Murphy

Active User


Joined: 23 Mar 2007
Posts: 148
Location: Ottawa Canada

PostPosted: Wed May 09, 2007 6:30 pm
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS

 


Similar Topics
Topic Forum Replies
No new posts MacKinney Batch to CICS upgrade causi... CICS 6
No new posts IEW2315E 1369 Link error All Other Mainframe Topics 3
No new posts COBOL sorting, with input GDG base COBOL Programming 7
No new posts Need help with ADABAS query (COBOL-AD... All Other Mainframe Topics 0
No new posts Associating a USERID with a CICS-Libe... CICS 0
Search our Forums:

Back to Top