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 <[email protected]>
>To: [email protected]
>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 [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
