Working with the DFSMSrmm Status feature

This topic describes key concepts and capabilities of the DFSMSrmm Status feature.

OMEGAMON® for Storage on z/OS®, Version 4.2.0, provides a DFSMSrmm monitoring and analysis function to help you manage the critical DFSMSrmm subsystem. The DFSMSrmm Status workspace provides a high-level overview of DFSMSrmm statistics and links to related workspaces that track data for common aspects of DFSMSrmm management and administration.

Benefits

This topic describes the benefits of the DFSMSrmm Status feature.

The DFSMSrmm Status feature analyzes and reports on entries in the DFSMSrmm Control Data Set (CDS) regarding all data sets on all tape volumes that DFSMSrmm is managing. This feature allows you to perform the following operations:

View comprehensive summary reports regarding general trends or specific low-level details:
- Locations Owners
- Accounting codes
- Creating Jobs or Programs
- Vital Record Specifications (VRS)
- Volumes and Datasets
Identify exception conditions regarding DFSMSrmm CDS space and backup, scratch tape counts, configuration state, and so on.
Select tape volumes, data sets, owners, or VRSs from a workspace view and initiate Storage Toolkit action commands against them.
Obtain an installation-wide view of DFSMSrmm CDS space utilization, exceptional conditions, and summary statistics.
Quickly identify resources that require attention, such as Pending Action or Pending Move volumes, and initiate that action using the Storage Toolkit.
Avoid the use of the standard DFSMSrmm reporting utility program that requires user customization.

Optimization

This topic describes how to optimize performance of the DFSMSrmm Status feature.

You should configure the DFSMSrmm Status feature to optimize performance. Otherwise, the amount of data that you collect can consume excessive system resources. For example, you can optimize configuration of the following behaviors:

Collection interval
Inclusion of dataset-level attribute data

Also see RMM Collection Control dialog box and also Optimizing data collection for the DFSMSrmm Status feature.

Note: Data collected for the DFSMSrmm Status feature is maintained in an in-memory data space for high-performance access. The data is not saved to disk, except for those Summary tables that have been configured for historical collection. For this reason, after you restart the Tivoli Enterprise Monitoring Server address space, the data space must be rebuilt by initiation of a collection cycle, either manually or at a scheduled time.

Attribute derivation and definition

This topic clarifies the concepts and values associated with specific attributes of the DFSMSrmm Status feature.

Only volumes with a type of PHYSICAL and a status of MASTER or USER are included in when calculating the following statistics:
- Capacity
- Utilization
- Compression
Compression, which is meant to represent the percentage reduction of data written from the host that is actually recorded on the tape volume, is calculated as follows:
```
1-((Volume Capacity*Volume % Full)/(App Data written to volume))
```
The following attributes include PHYSICAL, LOGICAL, and STACKED volume types:
- Total volumes
- Total datasets
- Average volume use count
- Average datasets per volume
- Percent of volumes read/written previous day
The following dates are shown as NONEXPIRING in the Days To/Days From attributes that are calculated by OMEGAMON:
- 99000
- 99365
- 99366
- 98000
- 98365
The Days Until Expiration attribute displays a positive value to represent a date in the future, while a negative the number represents the days since expiration. Similarly, a positive Days for Retention value signifies the remaining number of days that the dataset or volume is retained, while a negative value indicates the number of days since the retention date.
History can be enabled for the DFSMSrmm Summary, Configuration, and CDS tables only. CDS and Configuration data is collected at the interval specified in the History Collection Configuration dialog box of the Tivoli Enterprise Portal. Summary attributes are written to the history files only once during any collection cycle, because the summary data does not change until the next collection cycle is run.
- Locations Owners
- Accounting codes
- Creating Jobs or Programs
- Vital Record Specifications (VRS)
- Volumes and Datasets

Scenarios for using the DFSMSrmm feature

This topic describes typical scenarios for the DFSMSrmm feature.

The DFSMSrmm feature enables scenarios for powerful tape environment monitoring and management, such as the following:

Using the existing OMEGAMON Tape Devices workspace (under the navigation tree Tape Group node), you can link to the new DFSMSrmm Volume Details workspace to see all DFSMSrmm attributes for a mounted and in-use tape volume.
When an individual leaves the organization, you can use the Owner Summary workspace and link to the Owner Realtime Volumes workspace to see all volumes owned by that individual. Using the Storage Toolkit Change Volume command you could then change the owner name to a current employee.

Table 1. Using the Tivoli Enterprise Portal to manage DFSMSrmm tape volumes and data sets
Phase One: Become aware of a problem and decide how to respond	Create a copy of the product-provided situation KS3_RMM_Scratch_Tape_Warning, and set the low and high scratch volume counts to values appropriate for your installation. Start the situation.
Phase Two: Identify targets and take corrective action	When the situation is triggered, navigate to the DFSMSrmm Pending Actions workspace, and use the Storage Toolkit Confirm Actions for all Volumes command for any volumes that are in pending scratch state. You could also use the Storage Toolkit Add Volume command to add new volumes to DFSMSrmm.

Optimizing data collection for the DFSMSrmm Status feature

This topic describes ways to optimize data collection for the DFSMSrmm Status feature.

Follow these guidelines to optimize use of the DFSMSrmm Status feature:

In a multi-system, shared hard-disk-drive environment where the DFSMSrmm subsystem is running on multiple systems and sharing a single CDS, only enable OMEGAMON DFSMSrmm collection on one of the connected systems, ideally a non-production system. This behavior avoids collection of the same DFSMSrmm information on multiple systems, and places the work for collection on the system that is most lightly loaded.
Use product-provided queries and workspaces rather than user-created, because they have been crafted and tuned for maximum performance. User-defined queries can incur significant overhead when a very large number of data sets or volumes must to be examined to resolve the predicates.
User-created situations written against the DFSMSrmm Summary table should not have their Sampling Interval smaller than the DFSMSrmm collection cycle, because attributes are not updated more often than that.

Command-line option

This topic describes the command-line option for the DFSMSrmm Status feature.

If you have the authority to issue z/OS operator commands, you can use the command-line interface to manage data collection for the DFSMSrmm Status feature as follows:

 F temsname,S3RM command_function

where temsname is the name of the Tivoli Enterprise Monitoring Server started task and command_function is one of the following:

START or COLLECT: Immediately start a collection cycle.
STATUS: Display the current status of a running DFSMSrmm collection cycle.
HALT or STOP: Immediately stop a collection cycle. Attributes and reports for every volume and data set are processed up to the point that the STOP command was issued are available for viewing from the Tivoli Enterprise Portal.
TERM: Terminate all processing for the DFSMSrmm Status feature.

You find messages and output from any of these commands in the RKLVLOG output from the Tivoli Enterprise Monitoring Server

Custom queries

This topic provides tips and suggestions regarding queries that you create for the DFSMSrmm Status feature.

You must use uppercase characters for the character string values in your queries, such as data set name or volume serial number, otherwise the data is not displayed in the Tivoli Enterprise Portal. A single DFSMSrmm table query can return a maximum of 4000 rows. This behavior prevents storage shortages and potential abends in the Tivoli Enterprise Monitoring Server. A query (for example using the predicate JOB=$*) might match an extremely large number of data set detail rows. This processing load can negatively affect all other IBM® Tivoli Monitoring applications.