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.

I Can’t NEWCOPY My Program!

Why can’t I NEWCOPY the program I just compiled? The answer is almost always, “Because it’s in use.” Occasionally, for new programs, the answer may be that the compile or link edit was not successful. It’s possible that there is a problem with the PDS containing the load module. It’s conceivable that the person trying to issue the NEWCOPY does not have security to do so. But just about every time I’ve been asked to help answer this question, the reason has been that the program is in use.

The key to resolving such an issue is to find out what is using the program. I usually start by issuing a CEMT INQ PROG(yourpgm), and looking at the RES field (resource use count). If it is greater than 0, then the program is currently in use. I’ll hit enter several times, watching to see if the use count is varying, or staying at the same number. If it happens to be 0, then it’s possible that whatever had the program in use earlier has released it, and a NEWCOPY now will be successful.

If the RES field is varying, then I ask, “Is the module one that is invoked often?” If so, you may not be lucky enough to hit it when it is not being invoked. In that situation, issue CEMT SET PROGRAM (your-pgm) PHASEIN. This will bring in a new copy on the next invocation, even if it is currently in use.

If the RES field is staying at the same value (typically at “1”), then chances are good that a debug facility has it held. It could be held by someone running through CEDF, or a product such as Xpediter. It should be obvious from a CEMT INQ TAS command what has it held. What to do next in this situation depends on the debug product. If CEDF, then contact whoever has it (you should be able to identify the person running the CEDF transaction from the terminal id shown in the CEMT display). If Xpediter, use XPSP (System Facilities, then Resource Summary) to release Xpediter’s hold on the program. I’m sure each debug product has its own way of releasing its hold on a program in a similar fashion.

As a last resort, try issuing a CECI REL PROG(yourpgm) to release the program.

One of these methods has always worked in my experience. It is best to try to learn what the situation is rather than just start canceling tasks or issuing the CECI REL command – otherwise, you may be affecting somone else’s testing!