S0C4/AKEA Abend in CICS

Manas Sinha · Posted: Tue Jun 24, 2008 10:02 pm

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 -

Earl Haigh · Active User Joined: 25 Jul 2006 Posts: 475

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.

Bill O'Boyle · Posted: Wed Jun 25, 2008 12:38 am

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....

Regards,

Bill

Manas Sinha · Posted: Wed Jun 25, 2008 6:21 pm

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.

Bill O'Boyle · Posted: Wed Jun 25, 2008 9:07 pm

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.

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

Manas Sinha · Posted: Thu Jun 26, 2008 1:43 pm

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.

Manas Sinha · Posted: Thu Jun 26, 2008 2:09 pm

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.

Bill O'Boyle · Posted: Thu Jun 26, 2008 6:01 pm

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

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

Manas Sinha · Posted: Thu Jun 26, 2008 6:28 pm

The CICS DFHRPL concatenation is pointing to the Production libraries

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.

Earl Haigh · Active User Joined: 25 Jul 2006 Posts: 475

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.

Manas Sinha · Posted: Mon Aug 11, 2008 8:00 pm

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 -

Earl Haigh · Active User Joined: 25 Jul 2006 Posts: 475

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 ?

Manas Sinha · Posted: Mon Aug 11, 2008 8:25 pm

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.

Manas Sinha · Posted: Mon Aug 11, 2008 8:28 pm

Also

Earl Haigh · Active User Joined: 25 Jul 2006 Posts: 475

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

Manas Sinha · Posted: Mon Aug 11, 2008 9:55 pm

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 -

Earl Haigh · Active User Joined: 25 Jul 2006 Posts: 475

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.

Manas Sinha · Posted: Tue Aug 12, 2008 3:15 pm

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.

Earl Haigh · Active User Joined: 25 Jul 2006 Posts: 475

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

dick scherrer · Posted: Tue Aug 12, 2008 8:50 pm

Hello,

Bill O'Boyle · Posted: Tue Aug 12, 2008 10:04 pm

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".

Regards,

Bill