CALL vs. LINK
From CICS Wiki
Contents |
Introduction
This article is a collection of thoughts and experience as expressed in the CICS List.
The question is related to whether it is better to do program-to-program communication using the EXEC CICS LINK Api call or the "CALL" statement. There are clear advantages to both approaches.
Method one: LINK
Program A would set up a Working Storage or Local Storage area that would serve as communications area between the two programs. This Working Storage or Local Storage area would typically consist of some fields that are filled with input information and output fields that are expected to be filled with the reply from program A. Program A's communications area might look something like this in :
01 WS-Comm. 03 WS-Input-Employee-Id PIC X(8). 03 WS-Output. 05 WS-Output-LastName PIC X(50). 05 WS-Output-FirstName PIC X(50).
The program will now code a LINK API call that would look something like this:
Exec Cics Link Program('B')
CommArea(WS-Comm)
End-Exec
Program B can now address this communications area in its Linkage Section (In the case of ) in the follow way:
Linkage Section. 01 DfhCommArea. 03 Comm-Input-Employee-Id PIC X(8). 03 Comm-Output. 05 Comm-Output-LastName PIC X(50). 05 Comm-Output-FirstName PIC X(50).
The employee id field can be used as input to (for example) lookup information in a file or database and then fill the output fields (last name and first name in this example) with information.
Program B will now return control to program A using the EXEC CICS RETURN END-EXEC Api call.
Method two: CALL
Program A would set up a Working Storage or Local Storage area that would serve as communications area between the two programs. This Working Storage or Local Storage area would typically consist of some fields that are filled with input information and output fields that are expected to be filled with the reply from program A. Program A would then Call program B using the CALL statement:
Call 'B' using WS-Comm. or Move "B" to Prog-Name Call Prog-Name using WS-Comm
Program B would address the argument that it is called with using the following syntax in its Procedure Division. In the first case it's a static call if the Cobol-Compile Option NODYNAM, which is required for the seperate CICS precompile. In the second case it's dynamic call regardless of the Cobol-Compile Option DYNAM/NODYNAM
Linkage Section. 01 Link-Comm. 03 Comm-Input-Employee-Id PIC X(8). 03 Comm-Output. 05 Comm-Output-LastName PIC X(50). 05 Comm-Output-FirstName PIC X(50). Procedure Division using Link-Comm.
In its Linkage Section it would have the communications area defined. Program B can now fulfill its contract and return control to program A using the GOBACK statement.
Advantages of using a LINK
- LINK is easier to debug. This is because in the case of a program failure in program B (the linked to program) CICS will accurately report the program offset. You will see the dynamic load in the CICS trace table but only for the first time.
- Dynamic program link is possible. This means the LINK could be routed to a connected CICS region.
- The LINK is visible in the CICS Debugger CEDF.
- CICS takes care of AMODE DATAALLOC and EXEXKEY.
- CICS will handle the needed mode switches for THREADSAFE and QUASIRENT programs.
- CICS will handle the needed mode switches for OPENAPI and CICSAPI programs.
- CICS statistics counter show the current usage of program B.
- Don't even think about using the Cobol statement CANCEL.
- CICS can route via CPSM dynamicly programs (DPL) into a another region depending on the workload and the system programmer definition. Of course you shouldn't pass pointer in the DfhCommArea.
Advantages of using a CALL
- A CALL statement and specifically repetitive calls have better performance than using a LINK statement.
- A called subroutine can be used in both CICS and batch. If it use SQL you need to linked it twice one with DSNCLI and one with DSNALI/DSNRLI/DSNELI but only one source and compiled once. Of course the EXCI API commands available in a CICS environment only.
- A called routine will not create another LE Enclave.
- Call could send more data than 32k but this advantage has disappeared due to the CHANNELS capability of CICS Transaction Server V3. Keep in mind that CHANNELS require the storage three times. One in the Working Storage or Local Storage for program A, one in the CICS DSA and one in the Working Storage or Local Storage of program B.
- If you could turn off the LE runtime CBLPSHPOP the performance will be much better for dynamic calls.
- You can pass multiple parameters which is much better then a large DfhCommArea. However look also at the new Channel/Container stuff
- You can use CICS commands in program B (no advantage, just to point it out).
- Current Debug-Tools like Xpediter or DebugTool works fine.
- Repetitive Calls will be hidden for CICS statistics.
- You don't need to precompile the program unless you are using EXEC CICS commands. In this case use the CICS precompiler option NOLINKAGE and the precompiler won't touch your Procedure using .... statement.
- Don't even think about using the Cobol statement CANCEL.
- The working storage in your program might be in a last-used state. However don't even think about it. Using this feature can be very dangerous
- If you call another program C in program B you can also use CICS commands in this program BUT you will never get the correct EIBRESP unless you are passing a dummy DfhEibBlk and address the current DfhEibBlk in program C. Well you can also pass the original DfhEibBlk.
Local Storage 01 Dummy-Dfheiblk Pic x(85). Move "C" to Prog-Name CALL Prog-Name using Dummy-DfhEibBlk WS-Comm
In program C you need to use the EXEC CICS ADDRESS EIB(Address of DfhEibBlk) END-EXEC to address the real DfhEibblk before you can access some fields (e.g . EibResp) in the DfhEibBlk.
Dynamic DFHRPL (CTS 3.2)
This feature introduced with CTS 3.2 works for both.
Further reading
- IBM Redbook CICS Performance Analyzer, Chapter 15, "CALL and LINK performance"
