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.
The 3010 area status is documented in the CA IDMS Messages and Codes manual as an ABND3010, which may not be immediately obvious. The manual describes this as follows:
ABND3010 3010 Reason: An attempt to read from the database or disk journal file has failed.
Typically, this error occurs as a result of one of the following:
-A physical I/O error.
-An attempt to read a relative block number (RBN) that is outside the specified RBN range.
-A failed attempt to initialize the file.
-An initialized file that does not conform to the file block range specified in the schema or to the page size specified in the DMCL.
-With VSAM, insufficient space in the storage pool (DC/UCF) or partition (local mode) for required VSAM control blocks.
What this often means in terms of causes is one of the following:
- A problem on the physical drive;
- 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:
- the DMCL was changed recently; or
- the file was formatted, loaded or reloaded with a different DMCL, which contains a different definition for this file; or
- 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.
- 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 us to issue the 3010.
- FORMAT by AREA was run for a new dataset. A new dataset must be prepared by a FORMAT FILE before we can write to it.
- Also, CA 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 your 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 you determine 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 at your site, 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.