z/OS Change Tracker functionality

Protecting critical libraries and automatic creation of member versions

The z/OS Change Tracker started task (STC) monitors data sets for changes. When a change is introduced to a protected member, the started task takes a backup. As a result, you can reliably recover from unwanted changes if necessary. Member backups are stored in the data file, and an associated comment describing the incident is recorded in the control file. These VSAM files, along with the archive data file and archive control file, are collectively referred to as the repository.

The started task is critical for the functioning of z/OS Change Tracker. To ensure the correct functioning and integrity of the repository, always shut down the started task in the recommended fashion. See z/OS Change Tracker maintenance and housekeeping tasks for more information.

Using the CSAVE feature backs up members at the time the change is committed. Automatically generated comments allow for simple version identification in case a future recovery is required. Archived backups are made according to the schedule set by the user. Both Archived and Live backups are available online for viewing, comparing and recovery purposes using the ISPF interface.

Auditing and checking software integrity

There are two approaches available for auditing software and checking the integrity of the software environments. These approaches can be used concurrently to achieve your goals.

Approach 1:

Protect your critical libraries using the Protect a Resource function, and then audit the changes recorded real-time by the started task. This approach enables you to audit critical libraries by identifying who made the change, what action was involved (ADD, UPDATE, DELETE, RENAME, or ZAP), when the change was made, and which program was responsible for the change.

Approach 2:

Use tokenization to establish reference tokens representing the contents of data set members in your software environments. A token is a unique 8-byte binary representation of a data set member or non-PDS data set and can be stored in the z/OS Change Tracker repository or in a sequential data set. Periodically re-tokenize the data sets in your software environments and compare the new tokens with the old to identify and report any changed members.

Integrity verification for a sizeable local environment

To perform Integrity Verification for a large environment such as the libraries in a production site, tokenize the data sets of interest in that environment. This process establishes a 4-byte hex number that represents the content of each tokenized library member. One token is generated for each member of a partitioned data set (PDS, PDSE source and load), and one token is produced for an entire physical sequential or a direct access file.

The same TOKENIZE function with the MODS option specified can be used to detect if the environment has changed. The MODS parameter identifies any changed members or files since the tokens were initially generated. Lack of change (RC=0) indicates that the environment has remained intact, and hence the integrity is assured.

Integrity verification between two environments (local or remote)

To perform integrity verification between two environments, for example to verify if production software and disaster recovery software are identical, the approach is similar. For any two environments, z/OS Change Tracker quickly identifies data sets which have differences, such as mismatched members, or members with different contents. To perform integrity verification between two remote environments such as production and disaster recovery, tokenize the entire production volumes storing the tokens into an external flat file, and transfer this token representation file to the target environment.

On the target environment, tokenize the similar environment to create a second token representation file. Compare the two token representation files using the COMPARE command. The compare report identifies and reports mismatched data sets. For matching data set names, the mismatched member names, as well as the matching member names with different contents are identified and reported.

Using the tokenization process to synchronize the DR system with the production system regularly will ensure the latest level of software. The process can be performed as often as necessary.

Protecting software assets

z/OS Change Tracker protects critical data sets and library members from unauthorized change. You can protect software assets at the data set level, or at the member level (once critical libraries are protected with LOCK=YES). In the case of member level protection of protected libraries, member updates are allowed only if Checkout standards are used. The combination of data set level protection and member level protection provides the data center with complete and continuous protection.

Member level protection:

When the Administrator locks a data set using the LOCK=YES parameter, none of the members of that library can be changed unless the Checkout standards are used. This feature provides organizations with the assurance that their critical libraries and members are protected from the risks associated with unauthorized change and downtime. In order to allow update access to the specific members in that library, those members can be explicitly checked out by the Administrator. The checkout process makes one or more members available to the Administrator. Once the changes to the member have been implemented, the member is checked in by the Administrator. As an added safety feature, every time a checked out member is updated, the z/OS Change Tracker Started Task, monitoring the protected resources, automatically records the incident and backs up the member.

Utilities

z/OS Change Tracker provides a robust set of utilities. The user may require high-level comparison facilities for comparing pairs of PDS or PDSEs to determine similarities or differences at the member-level. Users may also wish to reconcile one or more pairs of partitioned data sets, to ensure that their member configurations are exactly alike.

Users can examine byte-level differences for members of libraries which are identified as being different by the z/OS Change Tracker internal tokenization operation (the DIFF members). To report the byte-level differences, once the z/OS Change Tracker tokenization has filtered out those members with identical contents (SAME members), the SuperC compare utility is invoked for DIFF members only. This way users can obtain a concise report of only the members which have some differences in their contents eliminating the need to spend time on the ones which are identical in their content.

Additionally, z/OS Change Tracker performs processing of the IBM z/OS File System (zFS) and z/OS UNIX. z/OS UNIX directories may be tokenized recursively by the z/OS Change Tracker tokenization process. The same z/OS UNIX environments can be re-tokenized at a later time, thus the z/OS UNIX files with different contents will be identified and reported as being DIFF. Same process works to identify and report the DIFF between two remote environments.