|
View previous topic :: View next topic
|
| Author |
Message |
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
Hi,
I know there are a lot of questions involving DFHEIBLK, but I just want to make sure I understand what happened in this situation.
We had a Cobol Cics subprogram B that was called by program A in the following way:
Program A:
| Code: |
77 SUBPROGR PIC X(08) VALUE ‘B’.
77 WS-CICS-AREA PIC X(85) VALUE SPACES.
01 WS-PARAMETER.
03 …. PIC X(123).
03 … PIC S9(09) COMP-3.
CALL SUBPROGR USING WS-CICS-AREA WS-PARAMETERS |
SubProgram B:
| Code: |
LINKAGE SECTION.
01 DFHCOMMAREA.
03 LINK-PARAMETER.
05 …. PIC X(123).
05 … PIC S9(09) COMP-3.
PROCEDURE DIVIDION USING DFHCOMMAREA.
…
EXEC CICS
START BROWSE
FILE(…)
RESP(…)
END EXEC |
Because of that, when trying to start a browse on a Vsam file under Cics, B was receiving an invalid EIBRESP.
The Cics guy told us to do the following:
Program A:
| Code: |
77 SUBPROGR PIC X(08) VALUE ‘B’.
01 WS-PARAMETER.
03 ….
03 …
CALL SUBPROGR USING DFHEIBLK WS-PARAMETERS
|
It solved the problem.
He explained that the use of WS-CICS-AREA in program A was messing with EIBRESP in subprogram B when it attempted to execute a Cics API.
Can someone explain why?
My understanding is that that EIBRESP doesn't belong to B because it's defined in the Linkage Section.
Because A called B without the DFHEIBLK variable, is it true that NO EIBRESP was available to B when it needed it?
Thanks. |
|
| Back to top |
|
 |
Bill O'Boyle
CICS Moderator

Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Any program that is passed through the CICS translator, automatically suffixed to the PROCEDURE DIVISION statement is DFHEIBLK DFHCOMMAREA.
If a program is intended to be CALLED, then the source code will look something like this -
| Code: |
PROCEDURE DIVISION USING LS-PARM-REC.
|
In LINKAGE SECTION, you'll find -
| Code: |
01 LS-PARM-REC PIC X(xxxx).
|
After passing through the translator and compiler, you'll find -
| Code: |
PROCEDURE DIVISION USING DFHEIBLK DFHCOMMAREA LS-PARM-REC.
|
If a DFHCOMMAREA is not defined to LINKAGE, then the translator will insert a 01-Byte DFHCOMMAREA automatically. The DFHEIBLK will always be inserted by the translator. These insertions are based upon the translator options PROLOGUE and EPILOGUE being active, which is usually the case.
Regardless whether this is CICS or Batch, when program 'A' calls program 'B' and parms are passed from 'A' to 'B', the parameters are 'positional'. So, if 'A' calls 'B', using WS-YELLOW and 'B' is coded with PROCEDURE DIVISION USING LS-PURPLE, this is perfectly fine, although confusing.
If DFHEIBLK is not passed, then issue -
| Code: |
EXEC CICS ADDRESS EIB(ADDRESS OF DFHEIBLK) END-EXEC.
|
HTH....
Bill |
|
| Back to top |
|
 |
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
hey Bill,
program A didn't pass dfheiblk to B, but it passed a "pic x(85) value space" field instead.
isn't it the same as that yellow-purple thing you mentioned?
thanks? |
|
| Back to top |
|
 |
Bill O'Boyle
CICS Moderator

Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Hello,
If the PIC X(85) field had the contents of DFHEIBLK moved to it before the CALL, then yes, that would have worked and would have acted as a positional parameter.
But, using DFHEIBLK and DFHCOMMAREA consistently, should be the method used.
Bill |
|
| Back to top |
|
 |
|
|
 |
All times are GMT + 6 Hours |
|