|
View previous topic :: View next topic
|
| Author |
Message |
Succor
New User
Joined: 20 Feb 2009
Posts: 96
Location: Bangalore :)
|
|
|
|
| Quote: |
| Verify the length and content of COMMAREAs. Many programmers check for the presence of a COMMAREA by simply checking to see if EIBCALEN is greater than zero and, if true, moving the LINKAGE SECTION item DFHCOMMAREA into a WORKING STORAGE area. This technique may seem proper on the surface, but it is not. CICS has no knowledge of the length of the LINKAGE SECTION item DFHCOMMAREA. The length and layout of this item are set at compile time. At execution time, the actual length passed from the invoking program is provided in the EIB item EIBCALEN. It is the called program's responsibility to insure that EIBCALEN matches the compile time length of DFHCOMMAREA. Failure to verify that EIBCALEN matches the length of the DFHCOMMAREA passed can lead to ASRA 0C4 ABENDs, storage overlays, or invalid data being moved into the working storage area of a program. |
Can we go by the above statement. |
|
| Back to top |
|
 |
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Quote: |
| Failure to verify that EIBCALEN matches the length of the DFHCOMMAREA passed can lead to ASRA 0C4 ABENDs, storage overlays, or invalid data being moved into the working storage area of a program. |
Yes. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Yes -- it is incumbent upon the programmer to check that the expected length of DFHCOMMAREA is what was received per EIBCALEN. I have seen an error occur, from a copybook change not propagated to all programs, where the DFHCOMMAREA length was 6 bytes longer than expected -- a storage violation eventually occurred. |
|
| Back to top |
|
|
Succor
New User
Joined: 20 Feb 2009
Posts: 96
Location: Bangalore :)
|
|
|
|
Thanks ,i was expecting to hear from both of you.
To conclude
| Quote: |
| The length of DFHCOMMAREA is set at compile time which should be checked against the execution time EIBCALEN value ...before going for a move. |
|
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Quote: |
| The length of DFHCOMMAREA is set at compile time.... |
It could be, but it doesn't need to be. It is usually set at execution time. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
If you define a WS area as PIC X(32763), which is the maximum length of a commarea, then (providing EIBCALEN > ZERO), move SPACES to the WS area and then use reference modification to move DFHCOMMAREA (1:EIBCALEN) to WS-COMMAREA (1:EIBCALEN). As a fail-safe, save EIBCALEN in a WS variable.
Storage (for the most part) is no longer an issue and 32K-4 in WS is nothing to worry about.
Regards, |
|
| Back to top |
|
|
|
|
