Table of Contents
Introduction:
I came across various Mainframe ABENDs during my mainframe programming. Below are some of the abend types in Mainframe Jobs.
- Different types of Abends in Mainframes:
- User abends
- System abends
- Errors in Mainframes:
- JCL errors
How to investigate and resolve them?
JCL Error occurs because of Syntax problems or dataset disposition issues whereas abend occurs
because of some functional problems.
a) User abends:
User abends means abend code will start with “U”. For Eg: U4038 with reason code, based on the reason code of the user abend we will get more information to find the root cause of the problem. All DB2 and IMS abends will include in the User abend section.
b) System abends:
System abends means abend code will start with “S”. For Eg: S0C4 with reason code, based on the reason code of the system abend we will get more information to find the root cause of the problem.
Errors in Mainframes:
Errors deal mostly with the JCLs which generally occurs due to syntax errors. For example, when system expecting some dataset name, which was not created then we can get the JCL error. JCL error returns the return codes of RC 08, RC 12, and RC 16. Out of these ABENDs, 80% of JCL errors can be avoided by using TYPRUN=SCAN option or JCL/EJCK based on the settings in your mainframe shop.
How to start the investigation to resolve the abend
By considering a basic example, we explained the detailed procedure of investigation and resolution of the problem.
Example:
Abend : Contention problem with U0777 REASON=00000000
Description : Based on the ABEND number with reason code we understand that it is User
ABEND and failed at respective step.
- First check, what that step is doing and check what does the reason
- Code for that user ABEND mean?
- In this case with reason code 0 and reason code is U0777 means it a one type
- Contention issue where two jobs are trying to access the same table.
- This contention information can be found in system log & db2 command options
- Based on the log information the jobs/user using that table can be found.
Action Taken: Once we know about the table which is being used, we can see the table space information in DB2 Admin panel as below.
Syntax: -DIS DB(XXXXX) SPACENAM(YYYYY) CLAIMERS
XXXXX Database Name
YYYYY Table Space Name
How to Resolve S0C4 and S0C7 Abends
Most of the challenging abends during initial IBM Mainframe Programming days are S0C4 and S0C7 ABENDs. These are most often occurred issues in Mainframe Jobs or JCLs. Below are some useful tips to help you approach these type of Abends.
System ABEND: S0C4
Description:
S0C4 or SOC4 ABEND is caused by virtual address translation error which is hardware specific or a storage protection violation.
How to take Action:
You need to correct the program logic error that’s generating the invalid address or storage reference.
When you’re analyzing the dump, should remember that the PSW saved when an S0C4 ABEND occurred may be pointing at the failing instruction. Or it may be pointing at the next instruction after the failing instruction. So it’s worth to check both the places.
There may be various factors causing this ABEND, some of them are listed below:
- In COBOL, the invalid address can be referenced due to a subscript error or a invalid parameter being passed
- During a group move, one of the receiving record’s variable length defined incorrectly
- It may be due to moving variable length record that was larger than target field size
- I could be due to read or write a file which was not open
- Might have used DD DUMMY with logic that moves high values to FD
- Might have called within COBOL SORT I/O procedure
- It can be using “GOBACK” in the SORT output procedure
System ABEND: S0C7
Description:
This ABEND is a data exception and can only occur when decimal (packed) instructions are used.
1) The sign or digit codes of one or more bytes manipulated by the packed or CONVERT TO BINARY instructions is invalid for packed decimal use. Packed decimal digits must be in the range 0 through 9, with only the sign digit being a digit in the range A through F.
2) Fields in decimal (packed) arithmetic overlap incorrectly.
3) A packed decimal multiplicand has too many high-order significant digits.
Possible causes for this ABEND include:
- Subscript error, referenced beyond table
- COBOL: working storage not initialized
- Bad data, should check data for errors
- Garbage in a field being tested or displayed
- Move zeroes to group level is display, had sublevels that were not
- Period missing after imperative statements within ATEND clause
- Binary field in an arithmetic operation is not large enough to accept result
How to Take Action:
You have to correct the format of the data being manipulated by the packed decimal instructions in the program and rerun or restart the job. I hope this was helpful to figure out the issue.
