3010 abend

Products

• IDMS
• IDMS - Database

Issue/Introduction

An area status may show up as a 3010, often in the log with a message

DC205019 V51 T36329 IOSTATUS=3010.

Ways to debug and resolve this are described here.

Environment

Release: All supported releases.

Resolution

The 3010 abend code is documented in the IDMS Messages and Codes manual as an ABND3010, which may not be immediately obvious.

What this often means in terms of causes is one of the following:

1. A problem on the physical drive;
2. A problem with the DMCL, so that the page size or the page range in the DMCL are not the same as the physical file. This could happen if:
   1. the DMCL was changed recently; or
   2. the file was formatted, loaded or reloaded with a different DMCL, which contains a different definition for this file; or
   3. the file was copied to this CV from a different CV, but the definition for this file was different in the DMCL for the other CV than in this one.
3. Occasionally, some temporary problem (a problem within the I/O subsystem, a problem with cache, the DASD device itself or in the channel) causes an "uncorrectable I/O error" message to be returned to IDMS, which will cause it to issue the 3010.
4. FORMAT by AREA was run for a new dataset. A new dataset must be prepared by a FORMAT FILE before IDMS can write to it.
5. Also, IDMS does not support files that span multiple physical volumes. If an area is too large to reside on a single volume, it must be mapped to multiple files, each residing on a single physical volume. Failure to do this can also cause this abend. 

To resolve this, the above possibilities should be researched. Also, if a file has the 3010 or 3011 error status, you can issue a DCMT VARY FILE nnnnnnnnn ACTIVE. This resets the STAT to 0000. If the 3010 is the result of some temporary error, then this will resolve the problem and subsequent access to the file will work without error. If it is a problem with the DMCL, or with the physical drive, then the next I/O attempt after this DCMT command will result in another 3010.

In terms of the impact on the system, the 3010 should not prevent a successful shutdown for the CV. It is likely that online applications and batch programs through CV won't be able to access this file successfully. However, if the problem with CV is in the DMCL then local-mode batch jobs may run without a problem, if the local-mode jobs use a different DMCL which has the correct description for this file.

If it is found that the online DMCL indeed does not match the file, the next step would to be correct the definition. If the DMCL definition is not the problem, then if this is a physical I/O problem often cycling the CV will resolve the problem.

If the DMCL is not the problem, and this seems to be a temporary error that corrects itself, the only other resolution would be to involve the storage group, and relay to them the information from the error messages. They could keep track of the various messages, and may build a history of the errors that might shed light on any I/O problem. This would be the data from the SYNAD exit's message, the "Z3A12D51,IDMSCV51,A24F,D, etc" and the file's name and RBN. The end of the synad's message contains the data contained in the DCB and IOB.