|
View previous topic :: View next topic
|
| Author |
Message |
akodakka
New User
.jpg)
Joined: 20 May 2010
Posts: 75
Location: India
|
|
|
|
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 |
|
 |
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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. 
Just my 2ยข.... |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
akodakka
New User
Joined: 20 May 2010
Posts: 75
Location: India
|
|
|
|
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 |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3051
Location: NYC,USA
|
|
|
|
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 |
|
|
|
|
