Open System Services Management and Operations Guide (G06.30+, H06.08+, J06.03+)
the OSS name server process (both primary and backup) or a disk volume containing a fast-create
fileset.
Note that even with the fast-create option enabled, FSCK is needed only in cases of multiple failures
and is run automatically by the OSS Monitor in most of these cases.
NOTE: Before you use the DIAGNOSE FILESET command, make sure that the fileset you are
about to check is stopped (unmounted). The OSS Monitor displays an error message if you attempt
to diagnose a fileset that is not stopped. See “Messages” (page 335), for information about OSS
Monitor messages.
The DIAGNOSE FILESET command can take a long time to finish. You should therefore execute
the command during a time when having a fileset unmounted for a long period does not disrupt
normal user activity.
While a fileset is being diagnosed, that fileset is put into the DIAGNOSING state. When the
diagnosis operation is finished, the fileset reverts to the STOPPED state and you can mount it with
the SCF START FILESET command.
If the FSCK utility fails, the fileset is put into the UNKNOWN state instead of the STOPPED state.
If the DIAGNOSE FILESET command is issued with the OPTION STOP option and the fileset being
diagnosed has a problem that has not been corrected, a subsequent mount of the fileset might fail.
FSCK Log File
The FSCK utility writes its output to a Guardian log file. Example 10 (page 161) shows two examples
of FSCK log files.
The FSCK log file is created with the access permissions for the user ID of the OSS Monitor process
when that process was started.
You can specify a Guardian filename for the log file using the REPORT option of the ADD FILESET
command, ALTER FILESET command, or DIAGNOSE FILESET command. If you do not specify a
filename for the log file, the log file is sent to the spooler location specified for the REPORT attribute
of the SUBSYS object. If no value is specified in the ZOSSPARM file or if the specified spooler
locations are unavailable, the log file is put in the same volume and subvolume as the OSS Monitor
code file, OSSMON (normally a $SYSnn subvolume).
The Guardian file identifier of the default log file consists of the characters ZX0 followed by the
rightmost portion of the device identifier of the fileset. (The device identifier of a fileset is a unique,
sequentially assigned set of letters and digits used in system internals.) For example:
• For the root fileset named ROOT (with device identifier 000000), the file ID of the default log
file is ZX000000.
• For the temporary fileset named TEMP (with device identifier 00007Z), the file ID of the default
log file is ZX00007Z.
The device identifier is also a field of the INFO FILESET command display.
A default log file has file code 180 in the Guardian file system and is suitable for use as an OSS
text file with an OSS text editor such as vi. Therefore you can read a default log file with an OSS
text editor.
You can also read a log file with a Guardian text editor after converting the file to an EDIT file
(Guardian file code 101) with the Guardian CTOEDIT utility. However, the EDIT form of a log file
can contain a maximum of 99,999 lines of entries using a line number increment of 1. To avoid
exceeding the limit on EDIT files, you should either periodically delete the log file after it has been
analyzed or use a spooler location for the log file. When a file-code-180 log file exceeds the
maximum size of an EDIT file, the log file should not be converted but should be read using only
an OSS shell utility such as vi.
160 Managing Filesets