Suggested AutoStatus Implementation

The following is a suggested implementation if you are a first-time user of AutoCollect.

First, perform the following research and testing at your site.

Determine which MUFs are selected for AutoStatus processing.
Determine which MUFs are Source MUFs
Verify that the Source MUF(s) have the Dynamic System Tables activated.
Determine which MUF(s) are the Repository MUF
Note: If you are a first-time user, we suggest that you select one MUF and use it as both the Source and Repository MUF.
Verify that the repository MUF(s) have the AutoStatus Snapshot database installed in the CXX (DBID 1018). A simple CXX report should be able to validate their presence and also provide the current allocation sizes.
If the database is not present, check the Version 12 installation process for the steps to install the database. If you cannot determine why the database was not installed, contact CA Support.
If the dataset sizes are not large enough or if you have not allocated and initialized the two datasets for the database, follow the instructions earlier in this guide to allocate and initialize the AutoStatus database.
Before starting data collection, run a DBUTLTY LOAD FORMAT=NONE to verify that the database is empty and ready to receive AutoStatus data.

We strongly recommend that the user implement the AutoStatus databases as 1018 (Snapshot). If the user chooses to use another DBID for this database, the various AutoStatus functions of DBUTLTY will need to include the DBID on every AutoStatus function execution.

The user must next create a set of DBUTLTY jobs as follows to execute and test the various AutoStatus functions.

Execute OPTION=SNAPSHOT several times.
(For sites with SQL) Follow the examples for using DBSQLPR to print a report of the data in a Snapshot rowset.
Execute OPTION=SNAPSHOT utilizing the various exclude commands.
Execute OPTION=SNAPSHOT utilizing the ability to gather statistics from multiple MUFs.
Execute OPTION=SNAPSHOT utilizing the repeat option to create a long-running job.
Use the console commands to alter the Snapshot options
Use the AS_OPTIONS console commands to verify the changes
(For sites with SQL) Follow the examples for using DBSQLPR to print a report of the data in a Snapshot rowset.

Once the initial testing phase has been completed, the user should then begin to plan the AutoStatus snapshot collection process. Key to this process will be the repeat time values for how often a status Snapshot should be taken while the Source MUF is normally executing.

As we have seen in the various examples in Collecting AutoStatus Snapshot Rowsets chapter, the timing of the MUF startup and shutdown will affect when we do over status Snapshot collection points.

The process below provides a simple implementation for collection status Snapshots every 10 minutes.

Select a set of MUFs that you would like to monitor active task status.
Determine a reasonable interval for the status snapshots:
- For typical implementations this could be every 600 seconds.
- If the repeat value is smaller than one minute you may create significant amount of data rows.
- If the repeat value is too high you may not get the level of granularity that you need.
Collect 24 hours worth of status snapshots.
Use DBSQLPR to do various searches on the data.
- Look for any tasks that have a long duration:
  - Typically for RAAT systems this would be DURATION of 2 seconds or greater.
  - Typically for SAAT or SQL systems this would be DURATION of 5 seconds or greater.
  - Use the S_MUF_DATETIME value from the “selected row” to re-query the status snapshots to print all task rows from the selected status snapshots. Review the information to determine what caused the request to be delayed.
- Look for any tasks that have a high I/O consumption:
  - Typically for RAAT systems this would be PHYSICAL_EXCPS of 2 I/Os or greater.
  - Typically for RAAT systems this would be PHYSICAL_EXCPS of 3 I/Os or greater.
  - Use the S_MUF_DATETIME value from the “selected row” to re-query the status snapshots to print all task rows from the selected status snapshots. Review the information to determine what caused the high IO.
- Look for any tasks that have a high buffer utilization:
  - Typically for RAAT systems this would be BUFFER_REFERENCES of 50 or more.
  - Typically for RAAT systems this would be BUFFER_REFERENCES of 150 or greater.
  - Use the S_MUF_DATETIME value from the “selected row” to re-query the status snapshots to print all task rows from the selected status snapshots. Review the information to determine what caused the high buffer references.
Save the status snapshots for a reasonable period of time. The information can be utilized if a user reports a MUF disturbance. If a time is provided, you can review the status information from around the problem period to see if there was problem with MUF.
Delete AutoStatus rows as needed. You can use DBSRPPR to delete older status rowsets.