Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Destructive overlap when moving DFHcommarea to group area

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
joshkahn

New User


Joined: 30 Dec 2005
Posts: 8

PostPosted: Tue Mar 27, 2007 9:13 pm    Post subject: Destructive overlap when moving DFHcommarea to group area
Reply with quote

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
View user's profile Send private message

William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3158
Location: Tucson AZ

PostPosted: Tue Mar 27, 2007 10:43 pm    Post subject:
Reply with quote

what is the value in eibcalen?
what does the move statement look like?
Back to top
View user's profile Send private message
dineshness

New User


Joined: 25 Dec 2006
Posts: 63
Location: Perambalur

PostPosted: Tue Mar 27, 2007 11:04 pm    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Tue Mar 27, 2007 11:56 pm    Post subject:
Reply with quote

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 icon_smile.gif ), 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 icon_confused.gif

So, what new "features" am i missing?
Back to top
View user's profile Send private message
joshkahn

New User


Joined: 30 Dec 2005
Posts: 8

PostPosted: Wed Mar 28, 2007 12:21 am    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Mar 28, 2007 1:34 am    Post subject:
Reply with quote

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 icon_confused.gif Is it possible that it did not compile successfully, but was linked anyway?
Back to top
View user's profile Send private message
joshkahn

New User


Joined: 30 Dec 2005
Posts: 8

PostPosted: Wed Mar 28, 2007 9:08 pm    Post subject:
Reply with quote

It did compile, generated a MVCLE instruction and moved 32K bytes.

Perhaps there is a cobol compiler parm that controls this?
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Mar 28, 2007 9:40 pm    Post subject:
Reply with quote

Hello,

I'm not sure what parm might control this. . . icon_confused.gif 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 icon_smile.gif ).

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Syncsort Help to group fields sudhakarraju SYNCSORT 6 Thu Dec 29, 2016 1:38 am
No new posts abend sort based on count records in ... anatol DFSORT/ICETOOL 5 Mon Oct 17, 2016 10:10 pm
No new posts Moving a PD to PD spoorni DFSORT/ICETOOL 8 Fri Oct 07, 2016 9:52 pm
No new posts Get Record count in summary record fo... Atul Banke DFSORT/ICETOOL 21 Fri Sep 23, 2016 4:17 pm
No new posts Moving character data to smallint in db2 rikdeb DB2 5 Thu Jul 14, 2016 12:38 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us