Logo: TUG TORONTO USERS GROUP for Midrange Systems
TUG
e -server magazine

November 1997: Volume 13, Number 2


Find Damaged Objects Before They Find You

By Debbie Gallagher

amaged objects are those that have some required part missing, or that have somehow become invalid. Objects are sometimes damaged during power failures or abnormal terminations. Object damage is not very common, but an object is not usable, as long as it remains damaged. The way to find all types of object damage is to run the RCLSTG (Reclaim Storage) command on your AS/400. Because it can take a long time to run, many shops do not schedule a RCLSTG very often. As a result, damaged objects are frequently not found until someone tries to use them. By that time, recovery may be difficult, and your business operations may be interrupted. However, the system sometimes discovers damaged objects during the regular course of operations, and has some information already available on them. The RCLSTG command may find more damaged objects, but if the system has knowledge already that an object is damaged, you will want to know too, so that you can recover the object as soon as possible.

The QUSRTOOL Method

If you are a QUSRTOOL fan, you can use the CHKOBJDMG (Check Object Damage) and the VALDBF (Validate Data Base File) commands to search for object damage. I have not used these specific tools myself, but there are AS/400 shops that rely on them. For more information on these tools, dig out Jim Sloan's article "AS/400 Damage Control" in your back issue (or CD) of News/400 from January 1993. In addition, the documentation with the tools explains how to create them.

The Job Log Method

During backup, if the system detects a damaged object, a message is sent to the job log. Not everyone remembers to read the job log after backups, but it is a good practice, and can yield valuable information. The save operation will not detect every type of damage, but will at least recognize some. Using this method, you will only find damaged objects in libraries that are being saved. If you have a stable environment with some libraries that are rarely saved, your discovery of object damage may be delayed.

The DASD Reporting Methods

If you already collect information on every object in order to report on DASD usage, it is simple to extract the object damage information at the same time. There are two methods for collecting information about every object:

If you don't already have a file with object information and you'd like to use one of these methods, read my article from the January 1996 TUG Newsmagazine, "Where Did All The DASD Go?" (If you missed it, check out the TUG web site at www.tug.on.ca).

DASD Method - Create a Query

Use the Select Records feature of Query/400 to print a report of the damaged objects on your system. If you have used DSPOBJD for collecting object information, the Select Records part of your query will look like:


	ODOBDM	 NE  0

If you have used DISKTASKS to collect storage information, the details of the data collection are in file QAEZDISK in library QUSRSYS. The object status field, DISTIN indicates any known object damage. The Query record selection in this case would look like:


	DISTIN  EQ  2

Recovering a Damaged Object

There really aren't a lot of options for recovery. If the damaged object is a physical file, you may be able to recover some or all of the data by using CPYF to a new file. If any data is missing, it will have to be corrected manually. As far as I know, the only other options are to:

Regular Checkups

Even though the most thorough method for finding damaged objects is the use of RCLSTG, you can identify those that the system already knows about by monitoring regularly. Use any or all of the methods outlined here, and try to find damaged objects before they find you! T < G