Yes. Thanks! The LE initialization using LINK caused high CPU consumption.
The alternative was to use the IBM BINDER to bind theirs and the called program together. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Monday, October 15, 2012 8:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Compiler Question 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
