C0D
Explanation
An unexpected error occurred. For example , a system component experienced an unexpected program check or perhaps an I/O device returned data that was not expected. This abend may be used for entry into a recovery routine that will capture additional documentation and then attempt retry. In other cases, the C0D abend will be percolated to an application recovery routine or another system component recovery routine.
Several components utilize C0D for these unexpected error situations and therefore it becomes necessary to utilize additional information to determine the specific component to determine the exact nature of this unexpected error. Continue reading for additional diagnostic techniques to help identify the nature of your specific instance of this C0D abend.
The system may provide a hexadecimal reason code to describe the error.
- Code
- Explanation
010000xx
- Internal reason codes for System SSL started task (GSKSRVR).
- 0025xxxx
- Internal reason codes for Basic HyperSwap® socket support.
- 2A00010x or 2A00020x
- After a page fixing request that specified a task control block (TCB) address of zero, the system received a corresponding page freeing request with a specific TCB address. The system could not locate the necessary control blocks to process the request.
- 40000001
- This program may not be invoked as a jobstep program or has an environmental requirement that
has not been met.
- 5E000101
- While processing a page fixing request, the system encountered a fixed page that was not backed with central storage. To satisfy the request, the page must be backed.
The reason code, if any, and the location at which the C0D ABEND was issued, are shown in an entry of type RCVY ABT in the system trace table.
For an indexed sequential access method (ISAM) request, the system found an excess number of error input output blocks (IOB). The probable cause of the problem is that an application neglected to free the dynamic buffers associated with a READ macro.
The following reason codes are used by the input/output supervisor HyperSwap function (IOSH):
- IOSHSAPI reason codes
- 80000002
- Attach macro request failure.
- 80000003
- Error attaching subtask.
- 80000004
- ETCRE macro request failure.
- 80000005
- CSVQUERY macro request failure.
- 80000006
- IEANTDL macro request failure.
- 80000007
- IEANTRT macro request failure.
- 80000008
- IEANTCR macro request failure.
- 80000009
- Error removing SSID name from master SSID_Array.
- 8000000A
- RESMGR macro ADD request failure.
- 8000000B
- RESMGR macro DELETE request failure.
- 8000000C
- ENFREQ macro LISTEN request failure.
- 8000000D
- ENFREQ DELETE request failure.
- 8000000F
- IDENTIFY macro request failure.
- 80000010
- Maximum number of subtask restart attempts reached.
- IOSHSSUB reason codes
- 80010001
- ESTAEX macro request failure.
- 80010002
- NUCLKUP macro request failure.
- IOSHSENF reason codes
- 80020001
- UCBPIN macro request failure.
- 80010002
- NUCLKUP token count error occurred.
- IOSHSRDR reason code
- 80030001
- IRXEXCOM routine call failure.
System action
The system may write a logrec data set error record, may write a dump, and may write messages about the problem. The system issues an abend to the current task.
Operator response
SLIP SET,COMP=C0D,ACTION=SVCD,ENDSystem programmer response
- If a dump or a logrec data set error record was not written with the abend, ask the operator to set a SLIP trap to obtain an SVC dump.
- If you cannot identify a responsible component from the logrec record symptoms such as CSECT
NAME and COMPID, then use additional information from logrec data set records, dumps, or both to
identify the component that is the source of the ABEND. See the chapters on "Recording Logrec Error
Records" and "System Trace" in
z/OS MVS Diagnosis: Tools and Service Aids for details on how to
interpret logrec records and System Trace entries. The failing PSW address, in most cases, reflects
the component that issued the ABEND macro. To ensure that the PSW address corresponds to an ABEND
macro invocation, refer to the failing instruction text in the logrec record or dump. The failing
instruction should have been "0A0D".
There are some cases where the CALLRTM TYPE=ABTERM macro is used and causes the error PSW instruction address to reference a system program or user program that might be in a wait state. Hence, the failing instruction text might be "0A01" or some other instruction. This might be due to the asynchronous nature of the recovery associated with a CALLRTM call. For this case, you will need a dump that contains SYSTEM TRACE.
- Search the System Trace for an entry of the type RCVY ABT corresponding to the C0D ABEND, and
note the PSW address. Once you have determined the PSW address for the program responsible for
invoking the ABEND or CALLRTM macro, use the IPCS WHERE command to find the module name.
- If the module is not an IBM module, continue diagnosis with the module.
- If the module is an IBM module, search problem reporting data bases for a fix for the problem. If no fix exists, contact the IBM Support Center. Provide the messages, the logrec data set record, the SYSOUT output for the job, and the dump.
Programmer response
For an ISAM request error, fix the program and run the job again. For a problem in obtaining storage, fix the storage request and run the job again.
For reason code 40000001, ensure that you
invoked the proper program and that its environmental requirements have been
met.
Source
- Real storage manager (RSM)
- Auxiliary storage manager (ASM)
- Contents supervision (CSV)
- Supervisor control (SUP)
- Program Call/authorization (PC/AUTH)
- Input/output supervisor (IOS)
- Access methods (e.g. BSAM, QSAM)
- System SSL started task
(GSKSRVR)