View previous topic :: View next topic
|
Author |
Message |
Deepika Pai
New User
Joined: 13 May 2010 Posts: 7 Location: India
|
|
|
|
While testing a CICS transaction as part of VS cobol to enterprise Cobol migration, we are getting a 4088 abend with reason code of 63 in the CICS. The module has been compile linked below the line with Amode\rmode of 24\24 and the composite load with 31\Any. Also, the load module is an element which is still VS COBOL and we do not have the source code for this module available with us. This module is also an AMODE\RMODE 24\24 module. Any suggestions\inputs would help. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
U40xx abends are typically Language Environment issues. 4088 rc 63 says in the manual
Quote: |
X'63' (99)
Stack segment owning the next-available-byte (NAB) could not be found or a DSA backchain pointer did not contain a valid 31-bit addressable address. A storage overlay problem has probably occurred. DSA backchain pointers must contain valid addresses that can be accessed as is while in 31-bit addressing mode. For instance, a 24-bit address that was obtained by using the BAL or BALR assembler instruction will contain the ILC, CC, and Program Mask in the uppermost byte of this address, thus making it an invalid address in 31-bit mode. |
|
|
Back to top |
|
|
Deepika Pai
New User
Joined: 13 May 2010 Posts: 7 Location: India
|
|
|
|
We have compile linked the module with Amode\Rmode 24\24 though. So not sure what we would need to correct the 31 bit addressibility issue. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
From my first post, I give you the thing to look for:
Quote: |
A storage overlay problem has probably occurred. |
Worrying about 31-bit versus 24-bit is useless until you have found and fixed the storage overlay problem. |
|
Back to top |
|
|
Earl Haigh
Active User
Joined: 25 Jul 2006 Posts: 475
|
|
|
|
LE 40xx abends are usually caused by COBOL that attempt to access data outside the range of an OCCURS.
Check your cobol programs for internal tables with occurs and then look at the program logic to determine if there is reference to a table element beyond the size of the occurs. |
|
Back to top |
|
|
Deepika Pai
New User
Joined: 13 May 2010 Posts: 7 Location: India
|
|
|
|
Thank you so much for the quick response Earl and Robert!
We changed the program for enterprise cobol migration. The module does not have occurs. But yes the module had service reload which we changed to SET as a part of the migration changes. Also pointers were removed from linkage and moved to Working storage. Could that have caused addressability issues? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Yes, it could. . .
Off the top of my head, i don't recall the "rules", but i do remember (iirc<g>) that some "things" needed to be in the linkage section. If i can find anything more specific later, i'll post it.
Why was any of the code moved to a different section? |
|
Back to top |
|
|
|