1.12 Summary File

As CS Capture gathers data about your Calendar Server environment, it also creates a Summary file. The Summary file is included in the capture archive that you send to Sun. It allows an engineer to assess your server setup and quickly obtain a picture of your server environment. The following information is included in the Summary file:

Version Detected:

Shows the Calendar Server version and version of JES installed.

Installation Path:

Shows where the Calendar server is installed.

Platform:

Shows the platform the Calendar Server has been installed on, including the OS version and the hardware it is running on.

Capture started at:

Shows when the capture was started.

Host Memory Size:

Displays the amount of physical memory in the machine.

Total Online Processors:

Displays the number of online processors in the machine.

Machine Last Reboot:

Shows when the machine was last booted.

Installed Calendar Patches:

Shows the Calendar Server patches installed on the machine.

Installed or last patched on:

Shows when the Calendar Server has last had a patch applied.

Server Setup:

Informs you of any processes that are not running but should be. For example:

CSHTTPD running 1 out of 2 processes!
CSADMIND process not running!

This section also displays information on how the server is configured. Configurations are as follows:

This is a Standalone  server.
This is a Frontend server.
This is a Backend server.
This is a Frontend and Backend server.

This section also tells you if CLD or LDAP Caching is enabled and if the server has been configured to support hosted domains.

Production Database Size:

Shows the physical size of the Calendar Server's production database on disk. This section also has information about the database capture. It indicates whether the -db or -nodb options were used. (For more information, see 1.9 Database Options.) It also displays the following message if the Calendar Server processes were running when CS Capture grabbed the database:

Comments:
Calendar  Server  Services  running  during  capture!
The may cause  CS Capture to  capture  and inaccurate  copy of the db

If you would like Sun to diagnose a database problem, it can be better to run CS Capture with the Calendar Server shut down. This is more relevant if you have a database over 500 MB. With a large database, the data is more likely to change while CS Capture is copying the database to the capture directory. This could result in a corrupt (or more corrupt) database being sent to Sun.

However, if you are more concerned with a crashing, hanging, or performance problems, shutting down the processes before running CS Capture may prevent the problem from being detected or gathered by the CS Capture program.

Core file/files found from <proc> at:

The above line may be displayed in the Summary file if pkg_app has found a core file from one of the Calendar Server's processes; where proc will be the name of the process. The Summary file indicates the time the process core was dumped, the full path name of the core file, and whether pkg_app was run against the core file. For example:

Core file/files  found from cshttpd at:
 Dumped at: 14 May 13:01 : /opt/SUNWics5/cal/lib/core
 (Ran pkg_app on: cshttpd)

Ran INVASIVE operations on: <proc> [PID <pid>]!

If you run CS Capture in invasive mode (see 1.10 Running cscapture in Invasive Mode), the Summary file displays the processes on which invasive information was captured.

Capture Finished at:

Shows when the capture finished.