CALL or LINK?

It’s an old question … In my CICS program, should I invoke a subprogram using a standard COBOL CALL, or should I use the EXEC CICS LINK API?

The traditional answer was, “LINK is easier to debug, CALL is more efficient.” However, there have been some changes in the CICS environment in recent years that blur the efficiency line and add other variables to consider.

The reason that LINK was considered easier to debug is that CALLs are “invisible” to CICS – you won’t see the transfer take place if using CEDF to debug. However, modern debug tools (e.g., Xpediter) have no problems showing CALLs, and virtually all shops use such a tool these days. So, if CALLs are more efficient and there is no debugging advantage to LINK, why use the CICS API?

The biggest advantage is probably the fact that using LINK can send control over to another CICS region. Since CICS has minimal involvement with a CALL, the processing stays in the same region; use LINK, and the program could be invoked in the same region, or it may be statically or dynamically routed to another region. If the program has special resource needs that are best served (or only served) in a particular region, statically route its execution to that region; if load balancing, let WLM route it to the least busy region. In my mind, those are huge. Other advantages include the fact that when using LINK, CICS will handle DATALOCATION (any/below) and EXECKEY (user/CICS) differences, and it will handle mode switches between THREADSAFE/QUASIRENT CONCURRENCY and OPENAPI/CICSAPI.

Another consideration that used to exist was that more than 32K could be passed in a CALL, but COMMAREA used to pass data in a LINK have that limit. However, use of CHANNELS and CONTAINERS overcome this limitation starting in CICS/TS 3.1.

My general rule of thumb is this … If invoking a subprogram that does not do “CICS stuff” (i.e., has no EXEC CICS statements), the same subprogram could easily be called from batch, so use a COBOL CALL so that the interfaces are consistent. If it does “CICS stuff”, then use LINK. But that’s just a rule of thumb – if efficiency concerns override the advantages of using LINK, then it’s perfectly fine to CALL a program that has “CICS stuff” in. If there are issues with CONCURRENCY or other items mentioned above, using LINK to invoke a program with no “CICS stuff” is perfectly fine, too. Use the tool that is best fitted for the situation.