Few more reasons to read

In earlier version of CICS, Call statements were rarely used because called programs couldn't issue any CICS commands( now its possible). So, the use of LINK commands became the norm in many COBOL shops. Even though this restriction has been lifted now, many shops still continue to use LINK commands.

Few more cobol links : Click here

Please do provide your comments or reactions.

Call Vs Link in Cobol

Syntax:
Call :
CALL SUBPGM USING WS-VAR.

LINK statment is used in CICS statement :
EXEC CICS LINK ('SUBPGM') COMMAREA(WS-VAR) LENGTH( WS-LEN)
END-EXEC.

Here are a few bullet points for the above query.

• LINK is not a COBOL statement(its CICS statement) whereas Call is 100% cobol baby.
• CALL can be used to transfer more than 32K between the calling and called programs.
• CALL can transfer multiple data elements, where as LINK can transfer only one(DFHCOMMAREA).
• Efficiency : Every time you LINK a program it establishes a new unit even if its a repeated module Link and CALL does not. It has been seen in past that LINK and a first-time CALL cost about the same: 250 microseconds (this no. may vary a bit).
  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 100 times, then there should hardly be any difference.
• Memory : Wary CALL. The working storages of the subprograms you call do accumulate and this would significantly increase the memory your transaction uses. Incase of heavy transactions, you could be really running short of memory. CALL is a bit dumb with storage handling. Its a storage slob.
  Working storage that belongs to a Linked program will be released when that program returns to its Linking Program. So the use of LINK will reduce your storage consumption - nice and tidy. It cleans up after itself.
  
  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 one of the rare reason to favour CALL over LINK.
• The Called Program must be in Local Region, while you can LINK a Remote program as well.
• If you have good hand on CICS debugger CEDF then you may be knowing that it doesn't show CALL activity but does show LINKs. If the dynamic COBOL CALL fails, CICS abend handling is not invoked, and you may get a COBOL abend code. Another one in favour of Link.

Fruther details on Calling subprograms from cobol

Note : All calls mentioned above are dynamic calls.

Please do provide your comments or reactions.