Alternatively, the called program may be translated with the "NOLINKAGE"
option. NOLINKAGE causes the translator to NOT automatically do any of the
following:
1) Generate the DFHEIBLK group in the LINKAGE SECTION
2) Generate the DFHCOMMAREA field in the LINKAGE SECTION
3) Generate the "USING DFHEIBLK DFHCOMMAREA" clause on the PROCEDURE DIVISION
statement.
This allows one to call the called program without explicitly passing
DFHEIBLK. But it also causes the called program to require the execution of
EXEC CICS ADDRESS EIB (ADDRESS OF DFHEIBLK) if it requires use of the
DFHEIBLK. One also must explicitly include the DFHEIBLK group explicitly in
the LINKAGE SECTION by using the statement "COPY DFHEIBLC" (yes, 'C' not 'K').
The "more manual" method using NOLINKAGE is perhaps more work in the case where
the called program is a "strictly CICS" program. However it does allow for the
possibility of having a subroutine that works in both CICS and in batch. Of
course it must "test" its environment so that it does attempt to execute CICS
commands in batch, and vice versa. As this may actually not be all that common
it can perhaps be determined that using NOLINKAGE is not worth the confusion.
I myself have used it more than once, but your mileage may vary.
One thing to note if you use the standard CICS LINKAGE option (the default;
generally not explicitly specified) is that on the CALLER you (generally) do
not specify the variable known as DFHCOMMAREA. For example, if your program
originally did this:
EXEC CICS LINK
PROGRAM ('MYSUBR')
COMMAREA (MYSUBR-COMMAREA)
END-EXEC
Then if you want to CALL MYSUBR as-is, and you don't wish to change it (which
makes sense), you would call it as follows:
CALL 'MYSUBR' USING DFHEIBLK, MYSUBR-COMMAREA.
(In other words, don't pass the caller's DFHCOMMAREA, except in the probably
rare condition when that's actually want you want to do.)
I have to apologize to the original poster in that my ideas, while "true", also
probably cause more coding changes than might otherwise be necessary. As long
as one doesn't have the "objection" to explicitly passing DFHEIBLK (as above),
then there is really no need for the NOLINKAGE option and it's subsequent
requirement for more manual coding of the "COPY DFHEIBLK" and "EXEC CICS
ADDRESS EIB". The fact of the matter is, if the called program does not itself
have any EXEC CICS LINK commands that you'd like to change to COBOL CALLs, the
called/linked program need not change at all.
I got a little single-minded on why I've chosen to go the NOLINKAGE path in the
past, and now see that in many cases it actually causes more work for little/no
benefit.
Frank
>________________________________
> From: Rick Arellanes <[email protected]>
>To: [email protected]
>Sent: Monday, October 22, 2012 10:14 AM
>Subject: Re: COBOL Compiler Question
>
>> The below information given to us by IBM states we are required by CICS to
>> use LINK (or XCTL) and can't use CALL; we pass a COMMAREA and use EXEC CICS
>> commands within our called module.
>
>COBOL does support the CALL statement under CICS even when you have EXEC CICS
>statements in the called programs. Please see the Migration Guide at
>http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg50/5.4.1.3 or the
>before mentioned COBOL Performance Tuning paper on pages 28-29. Both of these
>tell you how to add the required parms:
>
>If your Enterprise COBOL program was processed by a CICS translator (either
>separate or integrated), then a caller of that program must pass the CICS EXEC
>interface block (DFHEIBLK) and the communication area (DFHCOMMAREA) as the
>first two parameters of the CALL statement. If your Enterprise COBOL program
>was not processed by a CICS translator, then you need to pass DFHEIBLK and
>DFHCOMMAREA only if they are explicitly coded in the called subprogram.
>
>Rick Arellanes
>IBM COBOL Development and Performance
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN
>
>
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
