Collecting data for: Tivoli System Automation for Multiplatforms
General introduction to the getsadata utility
How-to instructions for using getsadata
Additional detail usually requested by IBM Support
Sending getsadata output/data to IBM Support
Downloading the getsadata package
will gather environmental, configuration, log, and trace data specific to TSAMP (Automation component), RSCT (cluster component), and TSAMP's Base Operations Console (if installed).
It can collect system logs as well as product install and runtime logs. It can format and collect the IBM.RecoveryRM, IBM.GlbResRM, IBM.Test, and IBM.StorageRM traces. RSCT's ctsnap utility can also be run and its output collected. The getsadata utility will tar & compress all the data it collects output into a single tarball and provide final filename details and location after it has completed executing.
Important points to note:
1. Execute 'getsadata' with root authority. Running as any other user will likely result in data Support cannot use to help you.
2. Run getsadata on all nodes in the domain where possible, but only after first running it on the node hosting the "master" automation engine (IBM.RecoveryRM), identified by using either of the following commands (executed from any node):
lssrc -ls IBM.RecoveryRM | grep -i master
3. It is important to collect data as soon as possible after a problem is observed in order to collect all log and trace data before data is lost (First In, First Out, fixed size trace files). This doesn't necessarily apply if your environment has trace spooling enabled.
4. It is equally important to run the utility before any manual (user) recovery efforts are attempted. This will ensure an accurate snapshot of the current states which can then be correlated with the logs and traces collected.
For maximum data collection, run the utility using the following syntax (on each server) :
For minimum data collection, so as to just take a quick snapshot of a current situation, run the utility using the following syntax :
If you want to see more detailed information about the commands being run, add the –verbose flag
If you want to use a different output directory instead of /tmp (default), add the –outdir <dir> flag, for example :
./getsadata -all –outdir /var/log
To just collect all log and trace data, then run the utility using the -logs and -traces flags as follows :
./getsadata -traces -logs -noprompt
To just collect just spooled trace data for a defined time period, use the following format :
./getsadata -spoolfrom YYYY-MM-DD[.hh[:mm]] -spoolto YYYY-MM-DD[.hh[:mm]]
To exclude a particular item from the collection, there are -skip* options available. For example, to collect all data "except" for ctsnap, run the utility using the following syntax :
./getsadata -all -skipctsnap
For more usage help, run the utility with the -h or -? flag, for example :
After running the utility on a node, the result will be a single tar file located and named like the following :
You should end up with a tar file named similar to that shown above for each of the servers where you run getsadata. Collect the tar files (one from each node) into a single directory and create a single tar file named using the PMR or Salesforce Case number so that it gets routed correctly when you FTP it to IBM, for example:
tar cvf ppppp.bbb.ccc .tar *-sa_data.tar.gz
tar cvf TS123456789 .tar *-sa_data.tar.gz
2) Provide the name(s) of the affected resource(s). It is highly recommended that you capture the output of 'lssam top', at the time you observed the problem, as this will show Support what you observed and when (date and time is printed at the top of the output). Provide the name of the node where you ran lssam and the userid you used.
3) Provide the node name (hostname) where the problem occurred. If you intend describing events using the terms "primary" and "standby" or "active" and "backup", please let us know which is which in relation to node names, so we can effectively use the diagnostic data collected by getsadata.
4) For DB2 customers, if you intend including snippets of db2diag.log messages, please indicate which node the data is from. Also consider showing snippets from the syslog, that is, the logger messages written by the DB2 automation scripts (syslogs do show the host name, as well as useful date/timestamp information, hence are of great value to Support).
Alternate upload method through your browser: http://www.ecurep.ibm.com/app/upload
Please include some details about the data where appropriate, for example a timeline of events (when the problem occurred and when actions were performed, both before and after the observed problem).
Electronically opening a PMR (SR) eliminates waiting on the phone to provide general information to the HelpDesk center. And providing output data from the execution of getsadata at the time you electronically open a PMR will ensure the data is immediately available to a Support engineer, thus allowing quicker initial diagnoses.
WARNING: Experience has shown that Internet Explorer (IE) can corrupt the tar file during its download process, though this may depend on the version of IE being used ... sorry, no IE version details available.
Ensure you always FTP the tar package using binary mode. Un-tar on the system where it is to be used, preferably in its own sub-directory.
Click on the following icon link to download the latest version (v9.0.0) of the getsadata utility :
More support for:
Tivoli System Automation for Multiplatforms
Software version: 2.2, 2.3, 3.1, 3.2, 3.2.1, 3.2.2, 4.1
Operating system(s): AIX, Linux, Solaris, Windows
Reference #: 1285496
Modified date: 25 April 2019