Calling subprograms from COBOL. In a CICS® system, when control is transferred from the active program to an external program, but the transferring program remains. In a receiving COBOL program, you must give the data area the name DFHCOMMAREA. In this COBOL program, if a program passes a COMMAREA as part of a LINK, XCTL,.

IBM MAINFRAME: DFHCOMMAREA addressing ->:::: Author Message akodakka New User Joined: 20 May 2010 Location: India Posted: Fri May 30, 2014 5:17 pm Post subject: DFHCOMMAREA addressing Hi, I was referring to an existing program and came across this code. So just want confirm my assumption is right. ProgA is called by another prog Progx. Unfortunately I dont have listing of progX. But ProgA flows as below ProgA Code: Linkage section 01 dfhcommarea pic x(01). 01 emp-layout. 05 name pic x(10) 05 address pic x(90) Procedure division using ws-parm.

Set address of emp-layout to address of dfhcommarea Display name Address. Goback Here my assumption is progX was passing a dfhcommarea of 100 bytes but progA instead of defining dfhcommarea with x(100) it defined it as just x(1) and then it map dfhcommarea address to emp-layout which allows progA to access the dfhcommarea passed by Progx Please advise if am correct[/code]. Bill O'Boyle CICS Moderator Joined: 14 Jan 2008 Location: Atlanta, Georgia, USA Posted: Fri May 30, 2014 5:38 pm Post subject: Reply to: DFHCOMMAREA addressing What you have here is DFHCOMMAREA being used as a placeholder (for addressability purposes) and this code (although awkward and misleading) will work and (in the long run) it would be best to refrain from this type of 'Cuteness'.

But, this could raise an error if a MOVE were to be done from DFHCOMMAREA, using reference modification and the length portion of the MOVE (for both operands 1 and 2) exceeds the LENGTH OF DFHCOMMAREA, which is 1. COBOL will find this as an error (raising a S0C4 Protection Exception) with the program being compiled with SSRANGE active and the LE run-time option CHECK being on. 'Cute' code does not help the poor slob who has to debug this at O'Dark Thirty. Bill Woodger DFSORT Moderator Joined: 09 Mar 2011 Posted: Fri May 30, 2014 6:31 pm Post subject: Reply to: DFHCOMMAREA addressing If the only reason it is on the PROCEDURE DIVISION USING is because it is passed on to another program. Then PIC X is fine. Note Mr Bill's warning.

If used in the program, rather than just passed on, define it correctly and fully. However, for an item of 100 bytes, I don't especially see the point in doing it. I've used it a lot for data-definitions exceeding 4095 bytes, because only one BLL Cell is required to load the address of the entire data (this happens in code generated for the PROCEDURE DIVISON USING.), if PIC X, rather than 300 BLL Cells for a table which is close to 300*4095 bytes in size. With an example of 100 bytes, you don't get any 'saving'. You do have some documentary value, as it does indicate that DFCOMMAREA is not modified in the program. However, in Impact Analysis you have to check that that first byte isn't used either, so you don't really have that. With Enterprise COBOL V5.1, the BLL-saving goes out of the window, because the management of addressability is extended.

Akodakka New User Joined: 20 May 2010 Location: India Posted: Fri May 30, 2014 7:03 pm Post subject: Reply to: DFHCOMMAREA addressing Hi I just took 100 bytes as an example. I do have much bigger data in actual prog. Igo Primo Gurjon Skin there. And yes I think I am saving something here.

Thanks very much for discussing this Rohit Umarjikar Senior Member Joined: 21 Sep 2010 Location: NY,USA Posted: Wed Jun 11, 2014 4:44 pm Post subject: This might not impact anything because it looks like there is no dfhcommarea is being shared between these two programs. As this is a compile listing so cics translator would add a byte of dfhcommarea by default to the linkage section. Also this set of address is done to ensure the correct eibcalen is populated in the called program which would indirectly ensure to have a data in emp-layout.:::: ->All times are GMT + 6 Hours Page 1 of 1 Search our Forum.

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. Turtle Odyssey Download Crack. John ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to with the message: INFO IBM-MAIN Frank Swarbrick 12.10.12 17:11. What is CTRCOBMOD?