Great information Frank. Excellent, thanks.
On Sat, Oct 13, 2012 at 11:11 AM, Frank Swarbrick
<frank.swarbr...@yahoo.com> wrote:
> What is CTRCOBMOD?
>
> If you do a COBOL static call, or even a COBOL dynamic call, you are for the
> most part not using CICS services to invoke your routine. For static I don't
> think CICS knows or cares at all. For a dynamic call I think a CICS service
> is invoked by the COBOL/LE runtime to load the module, but from there its
> basically COBOL.
>
> If you have no CICS commands inside the called module you don't have to do
> anything special with the called module. You compile it just as a "batch"
> COBOL program. (You still don't want to use things that directly invoke MVS
> services, though, such as COBOL I/O, etc.)
>
> If you have CICS commands you have a couple options. Others will probably
> tell you about the way that I do not prefer. What I prefer is the following:
>
> Place the following at the top of the called modules source code:
> PROCESS CICS('NOLINKAGE')
> (This assumes you're using the COBOL/CICS integrated preprocessor; if you
> still use the CICS translator then specify the NOLINKAGE translator option in
> the appropriate manner.)
>
> By doing this, the CICS translator/preprocessor will not add the implicit
> DFHEIBLK and DFHCOMMAREA fields to the COBOL LINKAGE SECTION and PROCEDURE
> DIVISION USING. This allows you to do a COBOL CALL to the routine just like
> you would in a batch program, i.e.:
>
> CALL 'MYSUBR' USING PARM-1, PARM-2, PARM-3.
>
> In your example below you could just do:
> CALL 'PROGRAM1' USING WS-COMMAREA
>
> Your called routine, if executing a CICS command, still needs to have the
> DFHEIBLK area; you just have to add it explicitly. Add the following to your
> LINKAGE SECTION:
>
> COPY DFHEIBLC.
>
> Then add the following to the beginning of your PROCEDURE DIVISION:
> exec cics address
> eib (address of dfheiblk)
> end-exec
>
> You now have DFHEIBLK addressability without requiring it to be passed as a
> parameter from your calling program.
>
> For the most part your called program can stay the same. You must eliminate
> any "EXEC CICS RETURN" statements, though, and replace them with a COBOL
> GOBACK. If you do EXEC CICS RETURN it behaves as if the calling program
> executed it, and most likely will not be what you want (which is to go back
> to the caller, not to return to CICS). This is because to CICS your calling
> program and your called program ARE THE SAME PROGRAM. With EXEC CICS LINK
> you go "up a level", and a RETURN goes back down. With COBOL CALL you do not
> go up a level, so if you do RETURN you still go back a level, which is
> probably back to CICS (unless your caller was LINKed to...)
>
> Anyway, once you get a few things straight there's not much to it.
> I'm sure that a static call gives the best performance.
> I believe a dynamic call is still "better" than a LINK because when you do a
> LINK you enter and initialize a new LE enclave each time.
>
> Which brings up another caveat. If you do a CALL to the same program from
> the same program multiple times within a task it behaves exactly as how this
> behaves in batch. That is, your WORKING STORAGE section is initialized only
> upon the first call. This is different than CICS LINK where you get "fresh"
> working-storage each time. This can actually be quite an advantage, but you
> have to make sure that your program that your currently LINKing to doesn't
> depend on it. If it does, there are a couple of things you can do:
> - Use the AS INITIAL clause of the COBOL PROGRAM-ID statement.
> - Do a COBOL CANCEL after each COBOL CALL (I don't recommend this, and I
> don't think it even works if you do a static call).
> - Place any variables that you need initialized each time your program is
> called in LOCAL-STORAGE SECTION rather than WORKING-STORAGE SECTION. (You
> could just put all of your variables in LOCAL STORAGE, but I imagine this
> would have unwanted overhead.)
> - Leave everything in WORKING-STORAGE and add PROCEDURE DIVISION statements
> to explicitly initialize any fields that require it.
>
> I would guess that options 3 (LOCAL STORAGE) or 4 (explicit initialization)
> would give you the best performance.
>
> Have I forgotten anything? Possibly.
>
> Have fun!
>
> Frank
>
>
>
>
>
>>________________________________
>> From: John Weber <j...@fiteq.com>
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Sent: Friday, October 12, 2012 5:21 PM
>>Subject: COBOL Compiler Question
>>
>>We have a COBOL CICS module being called using the LINK command.
>>
>>Here is the interface call:
>>
>>EXEC CICS
>> LINK PROGRAM('PROGRAM1')
>> RESP(WS-RESP)
>> COMMAREA(WS-COMMAREA)
>>END-EXEC
>>
>>However, it has been brought up that creating a bound module instead of
>>using LINK can speed up response time.
>>
>>Is this binding compiler in question CTRCOBMOD? If so, is this worth
>>pursuing?
>>
>>Thanks a lot...
>>
>>John
>>
>>----------------------------------------------------------------------
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Wayne V. Bickerdike
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
