Mainframe TDM: Clarification on GTXMSK Restartability and DB2 COMMIT/ROLLBACK Behavior

Products

• CA Test Data Manager (Data Finder / Grid Tools)

Issue/Introduction

Customers using Mainframe TDM (GTXMSK) for DB2 masking often require clarification on how the utility handles job failures, specifically regarding transaction commits, rollbacks, and the ability to restart a job from the point of failure.

Symptoms

• Uncertainty whether rows committed before a job failure are retained.
• Concerns regarding "double masking" (masking already-masked data) if a job is rerun from the beginning.
• Lack of documented parameters for a "restart column" or "checkpoint" mechanism in Mainframe TDM.

Environment

• Product: CA Test Data Manager (Mainframe TDM)
• Component: GTXMSK
• Database: DB2 for z/OS

Resolution

1. COMMIT and ROLLBACK Behavior

GTXMSK performs "in-place" masking. The COMMIT parameter in the job JCL determines the frequency of database commits.

• Committed Rows: If a job fails, all rows committed prior to the failure are permanent in the DB2 table. These cannot be automatically rolled back by the utility.
• Uncommitted Rows: Only the current unit of work (rows processed since the last successful commit) will be rolled back by DB2 upon an abnormal termination (abend) of the GTXMSK task.

2. Restartability Limitations

Unlike TDM Portal or Fast Data Masker (FDM), the Mainframe GTXMSK utility does not currently feature a native restartability mechanism.

• There is no internal tracking or "restart column" to identify where the previous execution stopped.
• Re-running the job will cause GTXMSK to scan the table from the beginning based on the SELECT criteria in the masking map.

3. Preventing "Double Masking"

If the masking function is not idempotent (e.g., an encryption or character-replacement function that changes the same value differently each time it is run), re-running the job may corrupt data consistency. To mitigate this:

• Filtering: Add a WHERE clause to the masking rules to exclude rows that meet a certain criteria (e.g., WHERE MASK_STATUS <> 'Y').
• Table Restoration: For large-scale failures, it is recommended to restore the table from a backup or image copy before re-running the full masking execution.
• Idempotency: Utilize masking functions that produce a consistent output for the same input, regardless of how many times the job is run.

Additional Information

For a review of the parameters used by GTXMSK refer to 'GTMSK Parameters".