Masking certain fields may initially seem to be a simple task. However, a detailed consideration will soon reveal a number of obstacles, like relationships between fields, diverse data types, different storage types like VSAM, IMS and DB2. A masking project can easily get out of hand. There are programs to write, to test, and to maintain, there are copying and execution rights to grant for databases, PSBs, clusters, loaders, etc. Normally there is a need for coordination between the masking rules deployed with DB2, IMS and VSAM. And while we are at data modification for the purpose of data privacy/protection, what about the other data changes that are required for test beds? Most often data must be modified because the structure changes, the new program versions to be tested have additional fields, or the fields became longer, or received another data type. Not only this, the provision of an appropriate test environment may require specific changes of field contents: dates, numbers, text strings. From a technical perspective, oriented on efficiency and performance, it does not make sense to process the data twice. All required modifications should be accomplished during the data copy.

A masking process consists normally of a number of steps. Deployment of programs to copy and modify databases, data sets and tables, JCL is needed for copy steps, unload steps, load steps, modification steps, etc. Production and test environments are rarely on the same systems, JCL has to reflect the systems (LPARs), and subsystems involved DB2, IMS as well as environmental parms for JES, accounting etc.

A repository for intermediate storage must be provided and appropriate load options must be implemented to allow flexible renewal of the data test: Refresh and add or update by key. This calls for further complex programming and the initial simple scrambling code advances to more sophisticated programs with a number of parameters and options.

All rows, segments, records of a data base are rarely needed, test cases usually require subsets of data records, subsets that fit together. This implies the subsets need to be relational consistent and complete. Selection of data rows and records for test beds, is obviously closely related to the process of data field modification.

Efficient masking is anything but easy. IMS environments pose a special challenge, unloaded and masked data might lead to sequence errors when loaded. Organizations that deploy alternative platforms for development (Micro Focus) have the need for further conversion.

DSECT offers a comprehensive solution for z/OS in the field of test data provision; data selection, extraction, collection, transformation and load. It integrates isolated scrambling routines into a unified, convenient and manageable process, simplifies data selection with standard sql Select, shows best performance with large amounts of data and is perfectly adapted to complex environments of large z/OS installations.