SHC-OSD is a dynamically reloadable subsystem which is decoupled from BS2000.
The tasks generated by SHC-OSD have the job name SHCUSERT.
The POSIX shared memory segment generated by SHC-OSD cannot be uniquely identified by its ipcs key: it uses the key 0 (PRIVATE).
The following documents are required for diagnostic purposes when problems occur in the SHC-OSD environment:
SHC-OSD executive and error traces and tables which can be found in POSIX in the following files, see "Creating diagnostic documentation using MODIFY-SHC-PROCESSING":
/var/shcosd/log/dumptrac-<yyyymmdd-hhmm>.txt
/var/shcosd/log/dumptabl-<yyyymmdd-hhmm>.txtCONSLOG file
Trace listing of the SHC-OSD command
Logging files of SHC-OSD from the
/var/shcosd/logdirectory (see "Logging files of SHC-OSD")For Symmetrix/VMAX3:
Logging files and settings of the SYMAPI server, see "SYMAPI server logging files". Information on this is provided in the Release Notes of the product "Solutions Enabler" (SYMAPI).
Logging files and settings of the SYMAPI client, see "SYMAPI client logging files".
Logging files of StorMan (see "Diagnostic aids") and possibly logging files of the SMI-S Provider (ETERNUS DX/AF)
Dump of the
SERSLOGfile (in particular if problems occur when starting the subsystem):
Serious errors or errors which cannot be stored in their own error trace will be entered in theSERSLOGfile. The same identification,NDE2000(“Internal error”), is always used here. The areas specified (one or two) are variable and come from the error trace entry.The REP file
SYSREP.SHC-OSD.<ver>which is used and the loader status of BS2000 and of the NKVD subsystemIf required, system dump
Creating diagnostic documentation using MODIFY-SHC-PROCESSING
The /MODIFY-SHC-PROCESSING SAVE-TRACES=*YES, SAVE-TABLES=*YES command writes SHC-OSD diagnostic data (traces and tables) from the executing system to the two files dumptrac--<yyyymmdd-hhmm>.txt and dumptabl-<yyyymmdd-hhmm>.txt in the POSIX directory /var/shcosd/log.
As these may be very large, they should be saved externally and then deleted in POSIX.
Logging files of SHC-OSD
The logging entries of SHC-OSD are written to a separate logging file. The logging file is created anew each day.
The file name is: /var/shcosd/log/shcosd-<yyyymmdd>.log.
Logging of SHC-OSD is performed in a separate task (fork) of the SHC-OSD user task (SHCUSERT). The user task is not blocked by SHC-OSD logging.
SHC-OSD logging files can grow to a considerable size (up to 1 MB per day). When the associated file system is full, this is reported by POSIX.
Obsolete SHC-OSD logging files are automatically deleted. The number of days before a logging file is deleted can be set in the SHC-OSD parameter file, see section "Configuration of SHC-OSD".
SYMAPI server logging files
SYMAPI server logging files are created only on the SYMAPI server. The respective settings are set primarily on the SYMAPI server.
When additional information is required for the diagnosis, you can also use the /MODIFY-SHC-PROCESSING TRACE=*PARAMETERS(SYMAPI-DEBUG=*ON/*OFF) command to enable and disable SYMAPI debugging on the SYMAPI server.
The command works remotely on the SYMAPI server when the SYMAPI server is configured accordingly, see "Configuring SYMAPI to operate SHC-OSD (Symmetrix/VMAX3)"). The diagnostic documentation created is stored on the SYMAPI server.
Large volumes of data are generated in the SYMAPI server's file system in this case. Debugging should only be switched on upon request and temporarily. It is essential to disable the option after a problem has been reproduced.
SYMAPI client logging files
The SYMAPI client logging settings can be changed with the /MODIFY-SHC-PROCESSING TRACE=*PARAMETERS(SYMAPI-DEBUG=*ON/*OFF) command.
If SYMAPI client logging information is needed early in the process, you can start the SHC-OSD subsystem with /START-SUBSYSTEM SUBSYSTEM-NAME=SHC-OSD,SUBSYSTEM-PARAM= 'DEBUG=ON'.
This generates large volumes of data in the POSIX file system. Debugging should only be switched on upon request and temporarily. It is essential to disable the option after a problem has been reproduced.
StorMan logging files
To diagnose errors, it is necessary to save the StorMan logging files and the repository, see the "StorMan" manual [15].