View previous topic :: View next topic
|
Author |
Message |
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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 |
|
|
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. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
Back to top |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
Back to top |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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 |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
Back to top |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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. |
|
Back to top |
|
|
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. |
|
Back to top |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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 |
|
|
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 ? |
|
Back to top |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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 |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
Also
Code: |
025900 03 WS-LENGTH PIC S9(4) COMP
026000 VALUE ZERO.
|
Best regards,
Amit. |
|
Back to top |
|
|
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 |
|
Back to top |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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 |
|
|
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. |
|
Back to top |
|
|
Manas Sinha
New User
Joined: 29 Apr 2008 Posts: 20 Location: United Kingdom
|
|
|
|
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 |
|
|
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 |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
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 |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
Back to top |
|
|
|