CL Command Reference - CHKOBJITG
CL Command List > CHKOBJITG Reference
Description:
The Check Object Integrity (CHKOBJITG) command checks the objects owned by the specified user profile, the objects that match the specified path name, or all objects on the system to determine if any objects have integrity violations. An integrity violation occurs if:
. a command has been tampered with.
. an object has a digital signature that is not valid.
. an object has an incorrect domain attribute for its object type.
. a program or module object has been tampered with.
. a library¡¯s attributes have been tampered with.
. an object failed a file system scan
If an integrity violation has occurred, the object name, library name (or pathname), object type, object owner, and type of failure are logged to a database file.
The type of violations that can occur are:
. ALTERED - The object has been tampered with.
. BADSIG - The object has a digital signature that is not valid.
. DMN - The domain is not correct for the object type.
. PGMMOD - The runnable object has been tampered with.
. BADLIBUPDA - The library protection attribute is set incorrectly.
. SCANFSFAIL - The object has been scanned by a scan-related exit program, and at the time of that last scan request, the object failed the scan.
Also logged to the database file, but not integrity violations, are objects that do not have a digital signature but can be signed, objects that could not be checked, and objects whose format requires changes to be used on this machine implementation (IMPI to RISC conversion).
The type of violations that can occur are:
. NOSIG - The object can be signed but does not have a digital signature.
. NOTCHECKED - The object cannot be checked, it is in debug mode, saved with storage freed, or compressed.
. NOTTRANS - The object has not been converted to RISC format.
Note: Objects that are compressed, damaged, saved with storage freed, or in debug mode may not be checked.
Note: IBM commands duplicated from a release prior to V5R2 will be logged as ALTERED violations. These commands should be deleted and re-created using the CRTDUPOBJ (Create Duplicate Object) command each time a new release is loaded.
Restrictions: To check object integrity, you must have audit (*AUDIT) special authority.
Note: The CHKOBJITG command may run a long time if:
. the user profile specified for the USRPRF parameter owns many objects.
. *ALL is specified for the USRPRF parameter.
. *SYSTEM is specified for the OBJ parameter.
. many objects match the path name pattern specified for the OBJ parameter.
Examples:
Example 1: Check Objects Owned by One User Profile
CHKOBJITG USRPRF(JOEPGMR) OUTFILE(SECCHECK)
OUTMBR(*FIRST *REPLACE)
CHKDMN(*YES) CHKPGMMOD(*YES)
CHKSIG(*YES) CHKLIB(*YES)
This command checks all objects owned by user JOEPGMR for integrity violations. Objects with an incorrect domain, program and module objects that have been tampered with, objects with digital signatures that are not valid, and libraries whose attributes have been tampered with will cause integrity violation records to be logged in database file SECCHECK. Database file SECCHECK is first cleared of any existing records.
Example 2: Check Objects Owned by Multiple User Profiles
CHKOBJITG USRPRF(ABC*) OUTFILE(ABCCHECK)
OUTMBR(*FIRST *REPLACE) CHKDMN(*YES)
CHKPGMMOD(*YES) CHKSIG(*NONE) CHKLIB(*YES)
This command checks all objects owned by user profiles that start with ABC for integrity violations. Objects with an incorrect domain, program and module objects that have been tampered with, and libraries whose attributes have been tampered with will cause integrity violation records to be logged to database file ABCCHECK. Database file ABCCHECK will first be cleared of any existing records.
Example 3: Check Objects in One Library
CHKOBJITG OBJ(¡¯/QSYS.LIB/LIB2.LIB/ABC*.*) OUTFILE(SECCHECK2)
OUTMBR(*FIRST *REPLACE)
CHKDMN(*YES) CHKPGMMOD(*YES)
CHKSIG(*ALL) CHKLIB(*NO)
This command checks objects in library LIB2 that have names beginning with ABC that are of any object type for integrity violations. Objects with an incorrect domain, program and module objects that have been tampered with, and objects with not valid or missing digital signatures will cause integrity violation records to be logged to database file SECCHECK2. Database file SECCHECK2 will first be cleared of any existing records.
Example 4: Check Object in a Directory
CHKOBJITG OBJ(¡¯/PartOrder/Forms.jar¡¯) OUTFILE(SECCHECK3)
OUTMBR(*FIRST *REPLACE)
CHKDMN(*NO) CHKPGMMOD(*NO)
CHKSIG(*ALL) CHKLIB(*NO)
This command checks file Forms.jar in directory PartOrder for integrity violations. If the file has a digital signature that is not valid or is capable of being signed and has no signature, an integrity violation record will be logged to database file SECCHECK3. Database file SECCHECK3 will first be cleared of any existing records.
Note: Any Java programs associated with this stream file will be checked for valid signatures as well.
Example 5: Check Object in a Directory
CHKOBJITG OBJ(¡¯/Parts/*¡¯) OUTFILE(SECCHECK4)
CHKDMN(*NO) CHKPGMMOD(*NO) CHKSIG(*NONE)
CHKLIB(*NO) SCANFS(*YES)
This command scans all files in directory Parts for integrity violations. If a file fails the scan by the scan-related exit program, an integrity violation record will be logged to database file SECCHECK4.