View previous topic :: View next topic
|
Author |
Message |
lind sh
New User
Joined: 04 Feb 2015 Posts: 32 Location: Tajikestan
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
I suspect that you're not getting exactly 8000 bytes in WS-DIS-UOWT-TABLE; that could certainly cause issues. |
|
Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006 Posts: 1353 Location: Israel
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
lind sh
New User
Joined: 04 Feb 2015 Posts: 32 Location: Tajikestan
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
lind sh
New User
Joined: 04 Feb 2015 Posts: 32 Location: Tajikestan
|
|
|
|
Thanks Robert. |
|
Back to top |
|
|
lind sh
New User
Joined: 04 Feb 2015 Posts: 32 Location: Tajikestan
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
|