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.

About these ads

5 responses to “CALL or LINK?

  1. I’m not clear about whether a called program will issue non-threadsafe commands on the qr tcb or from the same tcb as the calling program ?

    Thanks Andy.

    • Hi, Andy.

      A called program (invoked using a COBOL CALL) will inherit the TCB state from the calling program. A program that is invoked using CICS API (EXEC CICS LINK, EXEC CICS XCTL, etc.) will use whatever is coded in the program definition in RDO. Hope this helps.

      Steve

  2. How can we base on the printout in an abbrevated aux trace to tell a COBOL program dynamically calling another COBOL program under cics? I keep seeing additional AP EIP ADDRESS, LOAD, PUSH and POP cics entries of the callee. What is the exact way to tell it’s a COBOL calling another cics COBOL program in the trace?

    • Hi, Peter.

      Thanks for checking out the blog. I’m afraid I do not know the answer to your question, but will keep it in mind in case I get deeply involved in trace reading in the near future. In the meantime, maybe someone else can jump in and answer your question. If you need an answer quicker, I would suggest coding a simple program that does nothing but an XCTL, a LINK, and a CALL, to three different programs, and look at the trace for one of its executions. It should be easy to distinguish what happens with each style of transfer of control.

      Good luck!

      Steve

  3. How is WORKING-STORAGE “newcopied” in dynamically called COBOL subroutines? I understand how it is copied in Command Level programs, but how does CICS do it in non-CICS-compiled programs? There is no address hook into the program.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s