Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

DFHCOMMAREA addressing

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
akodakka

New User


Joined: 20 May 2010
Posts: 75
Location: India

PostPosted: Fri May 30, 2014 5:17 pm    Post subject: DFHCOMMAREA addressing
Reply with quote

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]
Back to top
View user's profile Send private message

Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Fri May 30, 2014 5:38 pm    Post subject: Reply to: DFHCOMMAREA addressing
Reply with quote

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. icon_cry.gif

Just my 2ยข....
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Fri May 30, 2014 6:31 pm    Post subject: Reply to: DFHCOMMAREA addressing
Reply with quote

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.
Back to top
View user's profile Send private message
akodakka

New User


Joined: 20 May 2010
Posts: 75
Location: India

PostPosted: Fri May 30, 2014 7:03 pm    Post subject: Reply to: DFHCOMMAREA addressing
Reply with quote

Hi

I just took 100 bytes as an example. I do have much bigger data in actual prog.And yes I think I am saving something here. Thanks very much for discussing this
Back to top
View user's profile Send private message
Rohit Umarjikar

Senior Member


Joined: 21 Sep 2010
Posts: 1609
Location: NY,USA

PostPosted: Wed Jun 11, 2014 4:44 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts base+displacement addressing scheme jackzhang75 PL/I & Assembler 3 Tue Mar 03, 2015 2:07 am
No new posts Data passing using DFHCOMMAREA sachinji84 CICS 2 Thu Aug 01, 2013 12:50 am
No new posts Address error - probable corrupted - ... Bill Woodger CICS 7 Mon Feb 11, 2013 9:33 pm
No new posts Is Addressing Issue depends on nature... Robert Sample COBOL Programming 7 Sun Sep 09, 2012 11:13 pm
No new posts DFHCOMMAREA maximum size and why hiravibk Mainframe Interview Questions 5 Thu Jul 28, 2011 3:35 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us