Not all rows are getting masked when using HASHLOV

Products

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

Issue/Introduction

Some records are being skipped while masking using HASLOV. In the masking configuration, we are using Parm2 for HASHLOV.

Also, when Unique Columns contain NULL values, those rows are also skipped, and not masked.

Environment

FDM 4.10.536.0 and greater

Resolution

With HASHLOV it's possible that the masked value could be the same as the original value, depending on the contents of the seed list used. With the release of FDM 4.10.536.0, Parm5 was introduced, which could help avoid unmasked values, but not when Parm2 is used at the same time. In other words, when setting Parm2 and Parm5, FDM behaves as if Parm5 = N.

Looking at the TDM Masking Functions and Parameters documentation, for HASLOV:

HASHLOV

Hash current value to consistently pick a value from the seed list or table in Parm1.

 

Applies to Field Type:vCharacter, Numeric

 

Parm1 (Mandatory): Seedlist name (from GTSRC_REFERENCE_LOV1.RL_REF_ID).

 

Parm2 (Optional): Integer between 1 and 30, default is 1. This identifies which column of data (RL_REF_VALUE to RL_REF_VALUE30) is returned.

 

Parm3 (Optional): Field name that contains the value to be hashed. Default: The field to be masked.

 

Example: SSN_COL in table SSN_TAB is hashed to give the row to return from GTSRC_REFERENCE_LOV1 where RL_REF_ID = "ADDRESSES".

Table: SSN_TAB

Column: ADDR_LINE1

Function: HASHLOV

Parm1: ADDRESSES

Parm2: 1

Parm3: 1 SSN_COL

Parm4: N/A 

 

Parm 5 (Optional): Avoid unmasked values. By default, the value is Y. Always return a different value than the unmasked value. If set to N, it returns the masked value as it is.

 

The recommendation is to run the masking job using Parm5 without using Parm2.

Additionally, in the scenario, where columns values are left unmasked where unique key has NULL values, the values of unique columns are used to identify the row which should be masked. If any of these values are NULL then the match is not found and the row won't be updated. This is functioning as expected.

 

To avoid this, use a WHERE condition and/or use a different set of unique columns. However, if you must use your own set of unique columns then verify that the values are truly unique, and non-NULL, otherwise you risk either having unmasked rows, or rows which will be masked several times (duplicated rows).