IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

How to move a long alphanumeric data items to another.


IBM Mainframe Forums -> COBOL Programming
Post new topic   This topic is locked: you cannot edit posts or make replies.
View previous topic :: View next topic  
Author Message
lind sh

New User


Joined: 04 Feb 2015
Posts: 32
Location: Tajikestan

PostPosted: Mon Dec 05, 2016 7:51 pm
Reply with quote

Dear friends
I want to move an alphanumeric field with the length of 8000 to another one.
but my CICS take abend ASRA. When I define my variable with the length of 5000 , there is no problem.
My code definition if following:
Code:


       WORKING-STORAGE SECTION.                         
       01 WS-DIS-UOWT-TABLE.                       
           05 WS-DIS-UOWT-ROWS OCCURS 100 TIMES.   
               10 WS-DIS-UOWT-REC-COL PIC X(80).   

       LINKAGE SECTION.
       01  DFHCOMMAREA.
               03 R-WS-DIS-UOWT-TABLE    PIC X(8000).

       PROCEDURE DIVISION.                   
      *#-------------------------------------
       A0000-MAIN-SECT-0000  SECTION.       

           MOVE WS-DIS-UOWT-TABLE TO R-WS-DIS-UOWT-TABLE.
           EXEC CICS RETURN  END-EXEC.   

       A0000-MAIN-SECT-0000-EXIT.           
           EXIT.                             



Content of WS-DIS-UOWT-TABLE was filled by another section and now I want to move it to the R-WS-DIS-UOWT-TABLE of commearea.
Is there any thing false here?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Mon Dec 05, 2016 8:02 pm
Reply with quote

I suspect that you're not getting exactly 8000 bytes in WS-DIS-UOWT-TABLE; that could certainly cause issues.
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1353
Location: Israel

PostPosted: Mon Dec 05, 2016 8:11 pm
Reply with quote

Check the calling program: it most certainly did not provide an 8000 bytes area, and CICS is just preventing a storage violation.
(Assuming transaction isolation is active)
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Dec 06, 2016 1:37 am
Reply with quote

Quote:
Is there any thing false here?
Looking at your post again, definitely there's falseness! For starters, you did not say if this program is being invoked by a terminal transaction code, as an interval started background transaction, from a CICS LINK or XCTL, or as a COBOL CALL statement. The reason the type of invocation makes a difference is that variables defined in the LINKAGE SECTION do not have memory allocated in the program -- the memory must come from some other source. For CICS programs, the usual source is the calling program's WORKING-STORAGE via the DFHCOMMAREA passed by the EXEC CICS LINK or XCTL (or by the memory passed by the USING on the CALL COBOL verb) but the memory could also be obtained via EXEC CICS GETMAIN.

If the source is from the calling program, what size was the passed DFHCOMMAREA? If the DFHCOMMAREA passed by the calling program is at least 5000 bytes but less than 8000 bytes, then the behavior you described would occur -- a 5000-byte MOVE would work fine (since the LINKAGE SECTION data has at least 5000 bytes) but an 8000-byte MOVE would fail (since the LINKAGE SECTION variable is less than 8000 bytes long). As Marso mentioned, CICS has specific checks to ensure programs do not attempt to use more memory than they have allocated.

Note that COBOL subprograms have PROCEDURE DIVISION USING <linkage variable(s)> to indicate that the LINKAGE SECTION variables are defined from the calling program -- CICS inserts the USING if you don't code for it.
Back to top
View user's profile Send private message
lind sh

New User


Joined: 04 Feb 2015
Posts: 32
Location: Tajikestan

PostPosted: Tue Dec 06, 2016 3:23 am
Reply with quote

Dear Robert
There is same problem even if I define R-WS-DIS-UOWT-TABLE in WORKING STORAGE SECTION of this program. So I think this problem is not related to LINKAGE SECTION.
I want to know Is there any limitation in MOVE verb or not.
Is there any other techniques to move large amount of alphanumeric data to anohere one?
Best regards.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Dec 06, 2016 4:19 am
Reply with quote

The limits of the compiler are described in Appendix B of the Enterprise COBOL Language Reference manual. The 6.1 version of this manual says MOVE has no limit.

Your problem is related to LINKAGE SECTION, DFHCOMMAREA, or something in CICS -- it has nothing to do with the MOVE statement.
Quote:
Is there any other techniques to move large amount of alphanumeric data to anohere one?
In COBOL, this is done with the MOVE statement. Do not attempt to find some way around your problem by avoiding the MOVE statement -- figure out what the REAL problem is and address it.
Back to top
View user's profile Send private message
lind sh

New User


Joined: 04 Feb 2015
Posts: 32
Location: Tajikestan

PostPosted: Tue Dec 06, 2016 11:22 am
Reply with quote

Thanks Robert. icon_wink.gif
Back to top
View user's profile Send private message
lind sh

New User


Joined: 04 Feb 2015
Posts: 32
Location: Tajikestan

PostPosted: Wed Dec 07, 2016 2:31 am
Reply with quote

Dear Robert
There is same problem even if I define R-WS-DIS-UOWT-TABLE in WORKING STORAGE SECTION of this program. So I think this problem is not related to LINKAGE SECTION.
I want to know Is there any limitation in MOVE verb or not.
Is there any other techniques to move large amount of alphanumeric data to anohere one?
Best regards.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Wed Dec 07, 2016 2:46 am
Reply with quote

1. There is NO limitation on the MOVE statement -- I have used a MOVE on a 10-million byte variable in a batch program before.

2. The MOVE verb is used to move data from one variable to another in COBOL. There are no other techniques because MOVE works -- period.

3. You have posted pretty much nothing about what the calling program is passing as data; if it is not passing at least 8000 bytes in the DFHCOMMAREA you could wind up with LINKAGE SECTION problems whether or not you think you do.

4. Your WS-DIS-UOWT-ROWS has a limit of 100 elements in the table. If you exceed that limit (and NOTHING you have posted indicates that you are not exceeding the limit in your code), then you will have potential storage violations unrelated to the LINKAGE SECTION.

5. You are starting to go around and around -- you have decided what the problem is, without any facts to support your theory, and you are ignoring what you are being told. This topic is being locked to prevent any further waste of our time on something you don't want to accept - namely, that the MOVE statement in COBOL works fine and will not, under any circumstances, cause your problem.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   This topic is locked: you cannot edit posts or make replies. View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Data set Rec-Cnt and Byte-Cnt Testing & Performance 2
No new posts SCOPE PENDING option -check data DB2 2
No new posts Check data with Exception Table DB2 0
No new posts JCL EXEC PARM data in C Java & MQSeries 2
This topic is locked: you cannot edit posts or make replies. Automation need help in sorting the data DFSORT/ICETOOL 38
Search our Forums:

Back to Top