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
01 dfhcommarea pic x(01).
05 name pic x(10)
05 address pic x(90)
Procedure division using ws-parm.
Set address of emp-layout to
address of dfhcommarea
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
Joined: 14 Jan 2008 Posts: 2504 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.
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.
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.