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

S0C4/AKEA Abend in CICS


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Tue Jun 24, 2008 10:02 pm
Reply with quote

Hi All,

I am getting a S0C4/AKEA abend in CICS. On checking the compiler listing the abend seems to be at the following line of code -

Code:
03538   013500                                                               
03539         *EXEC CICS READ                                               
03540         *          DATASET   (CPOFILE-CPCUS)                           
03541         *          RIDFLD    (CR-NUMBER)                               
03542         *          INTO      (CUSTOMER-RECORD)                         
03543         *          LENGTH    (WS-LENGTH)                               
03544         *          END-EXEC.                                           
03545   013600      MOVE '..0....Ø.03434   ' TO DFHEIV0                     
03546              CALL 'DFHEI1' USING DFHEIV0  CPOFILE-CPCUS CUSTOMER-RECORD --> Abend line
03547              WS-LENGTH CR-NUMBER.


This is what I can see in the MVS DUMPMaster facility
Code:

 CICS Abend code = ASRA      PSW at time of abend = 079D0000 000FA8EA           
                                                                               
 MVS Abend code = S0C4                                                         
                                                                               
 Register contents at time of abend :                                           
 0-7   00143B1C 00000000 500FA8C4 000FA59C 00140050 0014FFC8 001517D8 001527D8 
 8-15  00152BD0 000FAC02 000F9020 000F9020 000FA580 001529C8 40404040 0000F918 
                                                                               
 Failing instruction at 000FA8E4 is at offset 000018E4 in program OAOPNAA2     
                and at offset 000018C4 from program entry point 000F9020       
                                                                               
 Failing instruction is D20160FEE058 - MVC   0254(002,R6),0088(RE)             
                                                                               
 Operand 1 at 001518D6 length 0002 - 0000                                       


Can you pls suggest why an ASRA abend happen where we are doing an EXEC CICS READ ? Does this have something to do with CICS program compilation ?

Best regards,
Amit.
Back to top
View user's profile Send private message
Earl Haigh

Active User


Joined: 25 Jul 2006
Posts: 475

PostPosted: Wed Jun 25, 2008 12:37 am
Reply with quote

1 are the fields CPOFILE-CPCUS CR-NUMBER CUSTOMER-RECORD
WS-LENGTH all defined in working storage ?

2 check ws-length field is 2 byte halfword area

3 verify ws-length contains a correct length value

4 use CEDF or some other debug software to debug the program,
to make sure you are in fact abending on the CICS READ


Ask your CICS systems programmer, this should be an easy one
to determine where the problem is.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jun 25, 2008 12:38 am
Reply with quote

Is the definition of CUSTOMER-RECORD in WORKING-STORAGE or LINKAGE?

When populating WS-LENGTH (which must be a binary-halfword), load this field by moving the LENGTH OF CUSTOMER-RECORD to it.

If CUSTOMER-RECORD is defined to LINKAGE, then substitute (in the API) "INTO (CUSTOMER-RECORD)" with "SET (ADDRESS OF CUSTOMER-RECORD)".

Looks like PaySys/CMS stuff.... icon_wink.gif

Regards,

Bill
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Wed Jun 25, 2008 6:21 pm
Reply with quote

Customer record is defined in Working Storage, and WS-LENGTH is binary halfword.

WS-LENGTH field is being populated using a pointer addressing mechanism. On hard coding WS-LENGTH field, the program goes fine, which indicates that there could be a potential problem with addressing.

Best regards,
Amit.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jun 25, 2008 9:07 pm
Reply with quote

By chance, has there been any custom-code done to the CPOFILE copybook, which throws off your addressing to the binary-halfword length associated with CPCUS and other files? The reason I say this is that FILLER entries in CPOFILE contain record-length and key-length values of X'0000', which may explain the reason for the binary-halfword WS-LENGTH being set to ZERO.

The reason for using X'0000' instead of H'0' was due to alignment issues as the DSECT does NOT use the SYNC attribute, in other words, they are treated as unaligned binary-halfwords. Let's hope nobody got "creative" and used a H'0' definition. icon_wink.gif

Depending on your PaySys version release, CPOFILE could either be a User Data Table or an In-Core Static Assembler Table.

Either way, the entries need to match the copybook/DSECT.

Regards,

Bill
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Thu Jun 26, 2008 1:43 pm
Reply with quote

Thanks Bill for your advice.

I checked the CPOFILE DSECT and COBOL copybook for the same and found that there were some entries in the COBOL copybook which were missing in CPOFILE.

However, the entry for the file in question (CPCUS) has not been changed, only some files have been added.

Could this still be the source of the error ?

Best regards,
Amit.
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Thu Jun 26, 2008 2:09 pm
Reply with quote

Sorry Bill.

The DSECT and Assembler table are in synch with each other, I was looking at the wrong version of the code.

However, some of the file table entries are not present in CICS. By any chance, could that be the source of the error ?

Best regards,
Amit.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Jun 26, 2008 6:01 pm
Reply with quote

IIRC, CPOFILx was the In-Core Assembler File-Table for CardPac? (Circa 1980's). icon_question.gif

Verify that your CICS Loadlib RPL concatenation for the target region is pointing to the Loadlib where the version of CPOFILx can be found which you're expecting to use.

Otherwise, I'm fresh out of ideas....

Regards,

Bill
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Thu Jun 26, 2008 6:28 pm
Reply with quote

The CICS DFHRPL concatenation is pointing to the Production libraries icon_cry.gif

And even more astounding fact is that the same thing works in the Production environment.

Though I hate to say it, I am also running out of ideas now.

Best regards,
Amit.
Back to top
View user's profile Send private message
Earl Haigh

Active User


Joined: 25 Jul 2006
Posts: 475

PostPosted: Thu Jun 26, 2008 11:15 pm
Reply with quote

You need to talk with your CICS systems programmer,

If in fact, it is same code that works in Production,
is StorageProtect turned on in your Test region?

You obviously have a storage addressing problem.
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Mon Aug 11, 2008 8:00 pm
Reply with quote

Hi All,

Thought the issue had gone into oblivion, but it has reared its ugly head once again.

From the last post by Earl, I did check whether Storage Protect was turned on, and the test region overrides did suggest the same -

Code:

B03CICA1 STGPROT=YES 
B03CICA1 STGRCVY=YES 


This configuration is exactly the same as in Production.
Any ideas ?

Best regards,
Amit.
Back to top
View user's profile Send private message
Earl Haigh

Active User


Joined: 25 Jul 2006
Posts: 475

PostPosted: Mon Aug 11, 2008 8:17 pm
Reply with quote

AMIT,


Is there any storage violation messages in the CICS region sysouts?

I reviewed your earlier post, that shows abend occurred:

MVC 0254(002,R6),0088(RE

the 002 length in the assembler instruction makes me suspicious
it has something to do with the WS-LENGTH in your
exec cics read statement.

is the ws-length field defined on halfword boundary ?
ie..

WS-LENGTH PIC s9(4) COMP
or
WS-LENGTH PIC S9(4) COMP-SYNC


did you move the length of the record to WS-LENGTH before
executing the read statement ?


Can you read the same file using the CECI transaction ?
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Mon Aug 11, 2008 8:25 pm
Reply with quote

Hi Earl,

Sorry if I had missed that in my earlier posts, but as you said, the problem is with the WS-LENGTH field which is being moved using CPOFILE-CPCUS-LENGTH variable.

Code:

013300     MOVE      CPOFILE-CPCUS-LENGTH     TO  WS-LENGTH.           
013400     MOVE     'AD06'                    TO  OAOPNAA2-RETURN-CODE.
013500                                                                 
013600     EXEC CICS READ                                               
013700               DATASET   (CPOFILE-CPCUS)                         
013800               RIDFLD    (CR-NUMBER)                             
013900               INTO      (CUSTOMER-RECORD)                       
014000               LENGTH    (WS-LENGTH)                             
014100               END-EXEC.                                         


The CPOFILE-CPCUS-LENGTH variable comes from an Assembler DSECT which gets loaded in the calling program.

Code:

*                                                                     
CPCUS    DC    CL8'CPCUS3  ' CUSTOMER MASTER FILE             CCNB249
CPCUSLEN DC    X'0249'       0585 IS LENGTH OF CPCUS                 
CPCUSMIN DC    X'0117'       0279 IS MINIMUM LENGTH OF CPCUS         
CPCUSFIL DC    CL8'        ' RESERVED FOR FUTURE USE                 


The problem is that the Length field for this file is not being picked up correctly and hence gives an ASRA abend in the MOVE STATEMENT preceding the EXEC CICS.

Best regards,
Amit.[/quote]
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Mon Aug 11, 2008 8:28 pm
Reply with quote

Also

Code:


 025900     03  WS-LENGTH           PIC S9(4)       COMP             
 026000                                             VALUE ZERO.     
 


Best regards,
Amit.
Back to top
View user's profile Send private message
Earl Haigh

Active User


Joined: 25 Jul 2006
Posts: 475

PostPosted: Mon Aug 11, 2008 9:35 pm
Reply with quote

how is the assembler dsect defined in the cobol program ?
You probably have a storage alignment problem.

have you tried hard coding the length just to see if it works?

move 249 to ws-length
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Mon Aug 11, 2008 9:55 pm
Reply with quote

Hi Earl,

I have tried hard coding the length in the program and it works !

Also, the Assembler DSECT is loaded in the calling program as per below -

Code:


016600     EXEC CICS LOAD                               
016700               PROGRAM (WS-CPOFILE-NAME)           
016800               ENTRY   (CPOFILE-POINTER)           
016900               END-EXEC.                           



Best regards,
Amit.
Back to top
View user's profile Send private message
Earl Haigh

Active User


Joined: 25 Jul 2006
Posts: 475

PostPosted: Mon Aug 11, 2008 10:36 pm
Reply with quote

Amit,


Is CPOFILE-CPCUS-LENGTH defined in a copybook that is related
to the CPOFILE-POINTER address ?

please show a copy of your linkage section descriptions.
Back to top
View user's profile Send private message
Manas Sinha

New User


Joined: 29 Apr 2008
Posts: 20
Location: United Kingdom

PostPosted: Tue Aug 12, 2008 3:15 pm
Reply with quote

Hi Earl,

I raised this with our system programmers and they have confirmed that Storage protection is turned on in test region but turned off in Production region.

I have raised a change to turn off the parameter in test region as well and then bounce CICS.

Hopefully this should solve the problem.

Thanks for pointing me in the right direction.

Best regards,
Amit.
Back to top
View user's profile Send private message
Earl Haigh

Active User


Joined: 25 Jul 2006
Posts: 475

PostPosted: Tue Aug 12, 2008 5:55 pm
Reply with quote

Manas,

turning storage protection off in test is not a good idea. It may get you around the abend in test, but it does NOT CORRECT the problem.

if storage protection is turned off in production, you have the potential
to bring down the entire CICS region when you move code to
production that you know is causing storage overlays.

please show a copy of your linkage section descriptions for
fields related to CPOFILE-POINTER

thanks,
Earl
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Tue Aug 12, 2008 8:50 pm
Reply with quote

Hello,

Quote:
I have raised a change to turn off the parameter in test region as well and then bounce CICS.

Hopefully this should solve the problem.
Apologies for being harsh, but this is not a solution. There is something completely wrong with acknowledging that code fails and that the environment be changed to allow the failing code to be used. Nonsense. . .

The reason the environment is set as it is attempts to protect the Production environment by catching poorly implemented code while it is still in testing.

For my $.02 - fix the code. . .

Possibly there is something i misunderstand icon_confused.gif
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Tue Aug 12, 2008 10:04 pm
Reply with quote

I believe someone had mentioned to use CEDF?

Have you tried it?

Under CEDF and just before issuing the "READ" (IE: ABOUT TO EXECUTE COMMAND), take a screen snapshot of the fields, pressing <PF2> when the field is not displayable, such as the binary-halfword length.

I still believe you have a mismatch between the In-Core File-Table and its associated Copybook/DSECT.

One question; When the Table was Assembled, was the Assembler option "ALIGN" used?

The default is "NOALIGN" and this is the reason why binary-fields in this table are represented as unaligned "HEX" constants.

Use of the H and F aligned directives in lieu of unaligned-hex will raise some "opportunities". icon_wink.gif

Regards,

Bill
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS

 


Similar Topics
Topic Forum Replies
No new posts ABEND 0717 during starting IMS IMS DB/DC 0
No new posts MacKinney Batch to CICS upgrade causi... CICS 7
No new posts Associating a USERID with a CICS-Libe... CICS 0
No new posts omegamon for cics -UNSUPPORTED ENVIRO... CICS 2
No new posts Help needed in automation cics transa... CLIST & REXX 1
Search our Forums:

Back to Top