The Check Object Damage command checks all of the objects in one or
all libraries for damage.
The check occurs by saving each object to a save file in QTEMP.
A typical command is entered as:
CHKOBJDMG LIB(xxxxx)
A report is output to the spooled file OBJDMG. Exceptions are noted:
** If the object is already marked as damaged, an exception line
is printed.
** If the object cannot be successfully saved, an exception is
printed. The most typical error found will be that the object
is locked and cannot be saved. To determine the actual cause
that the object could not be saved, the job log must be
reviewed. The CPD3761 message indicates the locked condition.
If damage is detected by the save command, the object will now
be marked as damaged. Another execution of CHKOBJDMG will
show the object as damaged in the printed listing. A
diagnostic in the job log will note the damage condition.
Successfully executing the CHKOBJDMG command does not ensure that any
undetected damage exists. See the Restrictions section.
The objects are saved one at a time to a save file in QTEMP. There
must be enough room in the save file to hold the largest object you
will be checking. If you have large data base objects, you may not
have enough room to save them to the save file. If so, specify
CHKPF(*NO) to avoid checking these objects.
The checking that occurs by CHKOBJDMG only ensures that all of the
pages of an object exist to be saved. This is a sanity test and does
not ensure that the bytes will perform a valid function.
Data base files take up the most amount of storage on a typical
system and can have damage within the data portion of the object.
The CHKOBJDMG command will detect certain damage, but it will not
detect damage in the data portion of the object. To do a better
validation of data base files, you should consider the use of the
VALDBF tool (includes the VALMNYDBF command).
VALMNYDBF will cause all physical members in a file, a library or all
user libraries to be processed. The processing includes reading all
of the records, checking for valid numeric data (if there are any
externally described numeric fields) and checking fields based on any
DDS validity checking specifications (e.g. RANGE).
If you suspect damage on your system, a reasonable test would be to
use CHKOBJDMG with CHKPF(*NO) and VALMNYDBF for all user libraries.
Note that both of these functions are very long running. If you
suspect damage in a library, both commands could be used against a
specific library.
Libraries and objects not saved
-------------------------------
The following libraries cannot be specified. If LIB(*ALL) is
specified, they are bypassed.
QSYS
QDOCx
QSPL
The following object types cannot be saved by SAVOBJ. If found in a
library, they are bypassed:
*DOC
*FLR
*PRDLOD
*PRDDFN
Command parameters *CMD
------------------
LIB The library to be checked. *ALL may be specified to
check all libraries. See the discussion of
libraries and objects not saved. You must have *USE
authority to the TAADSPADP authorization list to
specify *ALL.
CHKPF A *YES/*NO value for whether data base files should
be checked by saving them. *YES does not ensure
that the file contains valid data. See the VALDBF
TAA tool to check the file.
If *YES is specified, you must have sufficient
storage space on your system to save the largest
file in the library.
Restrictions
------------
Checking for damage by performing a save does not check for all
potential damage conditions. It performs a sanity check that all
objects can be saved.
It is possible for the system to save undetected damage. For
example:
** If a program object has been damaged so that the instruction
stream cannot be executed (e.g. invalid machine operations),
this will not be detected unless the instructions are
executed.
** If a data base object contains data that is incorrect based on
the DDS description of the data (e.g. numeric fields do not
contain valid digits), the error will not be detected until
the field is used in a numeric operation. The TAA command
VALMNYDBF will find this type of error.
** In front of every data base record is a byte used by the
system to determine if the record has been deleted. If this
byte contains an invalid bit combination, the damage condition
will not be reported until the record is read by a data
management function. The save function picks up blocks of
data and does not check the leading byte. The VALMNYDBF
command will find this type of damage.
** Logical file objects are checked for damage, but not the
access paths. Logical file access paths are only saved with
the based on physical file if specifically requested on the
save command (they are not saved in the tool).
See also the discussion of libraries and objects not saved.
Prerequisites
-------------
The following TAA Tools must be on your system:
DSPOBJDA DSPOBJD with adopt (part of DSPADP tool)
EDTVAR Edit variable
RTVSPCAUT Retrieve special authority
RTVSYSVAL3 Retrieve system value 3
SNDCOMPMSG Send completion message
SNDESCMSG Send escape message
SNDSTSMSG Send status message
Implementation
--------------
None, the tool is ready to use.
Objects used by the tool
------------------------
Object Type Attribute Src member Src file
------ ---- --------- ---------- ----------
CHKOBJDMG *CMD TAALIBF QATTCMD
TAALIBFC *PGM CLP TAALIBFC QATTCL
|