Change tracking

There are two methods of change identification and automated member backup in z/OS Change Tracker.

Method 1: The z/OS Change Tracker started task identifies updates to members of protected data sets as they occur, and creates versions of the updated members after each update operation. Assuming the data set is protected and the started task is running on the LPAR, the updated members are captured and backed up automatically.
Method 2: The Surveillance function identifies the changed members and creates versions.

If a data center relies on using batch functions to introduce changes to their protected resources, they can use the second method to record their changes and to back up the changed members. z/OS Change Tracker allows you to eliminate the impact of batch operation on the started task. You can use the commands DEACTIVATESTC or OPTION=HALTOBJECT to temporarily stop the function of the started task.

Example 1: Running IEBCOPY while the started task has become deactivated

In this example, the started task has been deactivated in the first step of a job. While the started task is inactive, all the IEBCOPY steps are performed. In the last step of the job, the SURV function is run to identify the changed members, to record them, and to back them up. Finally, the started task is reactivated again.

//step0
DEACTIVATESTC
//step1 IEBCOPY
//step2 IEBCOPY
. . .
//step99
SHOW=PROTECTIONS
SHOW=LIST
SURV=(LIST,TTR=YES)
REACTIVATESTC
//*

Example 2: Running IDCAMS while the started task has become deactivated

In this example, the started task has been deactivated in the first step of an IDCAMS job. While the started task is inactive, all the

IDCAMS
DELETE

steps are performed. The SURV function is run to record the deleted members. Finally, the started task is reactivated again.

Note: Because the started task role is temporarily eliminated, it is not necessary to run the IDCAMS on the target libraries with DISP=OLD.

//step0
DEACTIVATESTC
//step1 IDCAMS DELETE using DISP=OLD
//step2 IDCAMS DELETE using DISP=OLD
. . .
//step99
SHOW=PROTECTIONS
SHOW=LIST
SURV=(LIST,TTR=YES)
REACTIVATESTC
//*

Example 3: Expanding the size of a protected library

In this example, the procedure to expand the library is explained. It is assumed that the library A is a protected library with LOCK=YES.

Stop the started task.
Copy library A to an expanded library B.
Rename library A to C, and then B to A.
Run the RESYNC function while the started task is still deactivated.
```
//CYGIN DD *
RESYNC=(DSN=library-a)
//*
```
COPY additional members to the newly allocated library A.

Run the SURV to find the copied members.

//CYGIN DD *
SURV=(DSN=library-a,TTR=YES)
//*

Start the started task.

Note: Because the started task has been restarted, even though the VOLSER of the newly allocated library A may be different from the original library A, the command TRIGGERREFRESH is not required. When the started task builds its “protection list” it will find the correct VOLSER of the library A.

Note: Because the started task was stopped, the LOCK attribute has no impact. Thus, it is not needed to change the protection attribute of the library from LOCK=YES to LOCK=NO and reverse.

Example 4: Reallocating a protected library on a different volume

If a protected resource is relocated to a different volume, this data set relocation must be conveyed to z/OS Change Tracker. There are two cases to consider:

If the relocation was done while the started task was down, no action is required. When the started task restarts, the correct volume will be found.
If the relocation was done while the started task was active, the following command must be executed. Otherwise, tracking of this object will stop until the started task is recycled.
```
//CYGIN DD *
 TRIGGERREFRESH
//*
```

Example 5: Procedure to force creation of member backups

If a member-level backup of a library is missed, you may run the following procedure to find the changed members and back them up.

Stop the started task or run the DEACTIVATESTC command.
Run the SURV function on the protected resource.
```
//CYGIN DD *
 SURV=(DSN=library,TTR=YES)
//*
```

Confirm that the backups are generated.

//CYGIN DD *
 SHOW=BACKUPS=(MEM=*, DSN=your-library)
//*

Start the started task or run the REACTIVATESTC command.

Example 6: Avoiding QSLOT error message being issued by the started task

Occasionally, if a protected PDSE was a target of a very large IEBCOPY operation, an internal condition was detected by the started task indicating that the QSLOT memory has no room. Although the IEBCOPY job runs successfully and all the members are successfully copied, the started task had stopped working.

To prevent this error, specify OPTION MASSCOPY in the CYGPARMS member. If this option is specified, when a mass copy or mass delete is detected, z/OS Change Tracker will temporarily HALT the operation of its started task for this target data set. As a result of the halt, member backups are not generated in real-time and activity recording is not performed; these activities are delayed to a later time when the SURV function is run. The temporary halt will be removed and the normal tracking will be resumed when the IEBCOPY or the IDCAMS jobs ends.

If this condition is detected, stop the started task, run the SURV command for all data sets in the protection list, and restart the started task. If the QSLOT error is encountered during a batch function, use the DEACTIVATESTC command, run the function, run SURV for the object, and then run REACTIVATESTC.

Example 7: Can multiple started tasks run on a system?

Because z/OS Change Tracker uses the SVC table to anchor its own intercepts, only one started task can run on a system at one time. However, for testing purposes you can stop the current started task that refers to the CYGPARMS member and start another one that reads CYGPARMT instead. The CYGPARMT member might refer to a TEST control file and data file, whereas the CYGPARMS refers to the PROD control file and data file.

Example 8: Using `DEACTIVATESTC` and `REACTIVATESTC` when deleting a large number of members

When deleting a large number of members from a library, usually when deleting more than 100 members, it is recommended to use the commands DEACTIVATESTC before starting the operation. The following is an example:

//step0
 DEACTIVATESTC
//step1 IDCAMS DELETE using DISP=OLD
//step2 IDCAMS DELETE using DISP=OLD
. . .
//step99
SHOW=PROTECTIONS
SHOW=LIST
SURV=(LIST,TTR=YES)
REACTIVATESTC
//*