CICS functions as a 'mini' Operating System under the control of the System's Operating System (such as OS/390). For CICS and all the tasks which it controls to operate correctly, all requests made by CICS Transactions (Tasks) such as Program Control and Input/Output Operations should be made to CICS and not directly to the Operating System. This is to eliminate any instance of an "OS WAIT" being issued by a Transaction. If a request for service, such as a File Read/Write (GET/PUT) or, in this instance, a program LOAD, as would be a result of a DYNAMIC CALL from the COBOL program executing as a CICS Transaction. This places the entire CICS region, not simply the transaction, in a WAIT while the I/O completes. Never cause an OS WAIT to be issued by a program operating as a CICS Transaction regardless of the programming language.
I hope that is clear.
As to CALL vs LINK, if the program being CALLed is modified, it then becomes necessary to re LINKedit (PGM=HEWL) the CALLing program to include the updated CALLed sub-program code. Using EXEC CICS LINK, the LINKing program will always get the latest version of the LINKed sub-program with no need to repeat the LINKedit (PGM=HEWL). Even if the sub-program is updated while CICS is 'up', a request (CEMT) can be made that the PPT entry be 'refreshed' to point to the new LINKed program.
I hope this is also clear as the term LINK can mean two different things. I've tried to note which is the batch HEWL.
Have a great day... Oops! It's Friday the 13th. Good luck.
If a bug is located in a program product which simply cannot be fixed, it becomes a 'feature'. (IBM)