|
View previous topic :: View next topic
|
| Author |
Message |
joshkahn
New User
Joined: 30 Dec 2005
Posts: 8
|
|
|
|
In command level cobol cics, I have a program with
linkage section.
01 dfhcommarea pic x
occurs 1 to 32767
depending on eibcalen.
When I move dfhommarea to a smaller group area, I get destructive overlap. That is is always mover 32K.
Besides address modification in the move statement, is there any easy way to fix this? |
|
| Back to top |
|
 |
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
what is the value in eibcalen?
what does the move statement look like? |
|
| Back to top |
|
|
dineshness
New User
Joined: 25 Dec 2006
Posts: 63
Location: Perambalur
|
|
|
|
| Code: |
| 01 dfhcommarea pic x occurs 1 to 32767 depending on eibcalen |
I guess declaring the COMMAREA like as above could not be used to communicate the data between transactions. With the above declaration you can not use reference modification in a move statement. At any time only one byte can be transferred between transactions or used in a move statement.
May be you have to declare a sublevel level variable with occurs like below.
| Code: |
01 dfhcommarea.
05 data pic x occurs 1 to 32767 depending on eibcalen.
|
To avoid the destructive overlap in a move statement, I think the only possible way is using the reference modification.
Dinesh. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I may be going way out on a limb here, but if the comm area definition is changed to
| Code: |
01 dfhcommarea.
05 data pic x occurs 1 to 32767 depending on eibcalen. |
with
| Code: |
| 01 little-field pic x(123). |
and there is a
| Code: |
| MOVE dfhcommarea TO little-field |
there should be no destruction. . .?
Actually, (this from memory as opposed to having just looked it up - i'll pay for that  ), i thought the receiving field determined the length of a character move - If the receiving field was shorter truncation occurred and if the receiving field was longer, the receiving field was padded with spaces.
Even with the original definition (which is a bit of a surprise as my learning included the bit that a level 01 cannot have an occurs), i'm not sure why the receiving field did not determine the length to be the short field 
So, what new "features" am i missing? |
|
| Back to top |
|
|
joshkahn
New User
Joined: 30 Dec 2005
Posts: 8
|
|
|
|
01 DFHCOMMAREA.
05 COMMAREA PIC X
OCCURS 1 TO 32767
DEPENDING ON EIBCALEN.
COPY TWACOPY.
01 DELETE-REC PIC X(100).
Move commarea to little-field. (moves 32K)
Cobol generates a MVCLE command that moves 32K to little-field.
Move commarea (1:length of little-field) to little-field. (works)
Any easier way? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
On my system, this
| Code: |
77 HOWMANY PIC S9(3) VALUE 100.
*
01 LITTLE-FIELD PIC X(50) VALUE ALL 'A'.
01 AFTER-LITTLE-FIELD PIC X(50) VALUE ALL 'Z'.
*
01 ARRAY-01.
05 ARRAYITM PIC X OCCURS 1 TO 100 TIMES DEPENDING ON HOWMANY.
MOVE ARRAYITM TO LITTLE-FIELD.
|
will not compile. This error is presented.
| Quote: |
"ARRAYITM" WAS A TABLE ELEMENT BUT WAS NOT SUBSCRIPTED OR INDEXED. . . |
This
| Code: |
DISPLAY LITTLE-FIELD.
DISPLAY AFTER-LITTLE-FIELD.
MOVE ALL 'D' TO ARRAY-01.
DISPLAY ARRAY-01.
MOVE ARRAY-01 TO LITTLE-FIELD.
DISPLAY LITTLE-FIELD.
DISPLAY AFTER-LITTLE-FIELD.
|
compiles and gives
| Code: |
<...+....1....+....2....+....3....+....4....+....5....+....6....+....7..
=============================== T O P =================================
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ |
I seem to have suffered no overlap (i.e. the ZZZs survived). I still do not understand how this
| Code: |
| Move commarea to little-field. |
successfully compiled Is it possible that it did not compile successfully, but was linked anyway? |
|
| Back to top |
|
|
joshkahn
New User
Joined: 30 Dec 2005
Posts: 8
|
|
|
|
It did compile, generated a MVCLE instruction and moved 32K bytes.
Perhaps there is a cobol compiler parm that controls this? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I'm not sure what parm might control this. . . What addressing mode(s) are you using? The MVCLE is the extended version of the MVCL (Move Long). It allows up to (i believe) 2gig to be moved (like we need that all the time ).
What is generated if you use the "01 DFHCOMMAREA" instead of the "05 COMMAREA"?
Lastly, are there any messages at all in the diagnostics at the end of the compile? Even though it compiled, there may be a warning? |
|
| Back to top |
|
|
|
|
