FORMATENCRYPT1 Mainframe Z/OS FAILED TO MASK FIELD TPGEM.DSC_COMM_GARA by exceeding the internal limit of 30 sub-components

Products

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

Issue/Introduction

We need Broadcom’s help to resolve this issue we are having with the masking with our table TPGEM with FORMATENCRYPT1 function.

I have transferred a total of eight files, an input file, copybook, pun, mapcsv, define and three output files to help facilitate the investigation.

In the input file you will find four records, the first two are causing us the problem as the FormatEncrypt1 function is unable to mask the field DSC_COMM_GARA.

I also added in the last two records which the function FormatEncrypt1 correctly masks the field DSC_COMM_GARA for both.

Environment

Release : 4.9.1

Component : CA Test Data Manager - Others

Resolution

I uploaded all the client's files and ran an experimental job - the record/string masked successfully.

 

The client did not include runtime options, so the remainder of this investigation relies on guesswork. It is thought that they employed FORMATENCRYPT1DELIMITER=(SPACE -) or some version thereof, as this is option has been seen in previous jobs. I re-ran using this option and observed the same overflow result.

 

Checking the input file, DSC_COMM_GARA within the first record contains 32 embedded spaces and 2 embedded dashes. Use of FORMATENCRYPT1DELIMITER=(SPACE -) separates this into 34 individual elements for masking, exceeding the internal limit of 30 sub-components.

 

My suspicion is that the client did not foresee the consequences of employing a SPACE delimiter on a field containing text elements naturally broken by many spaces.

 

Example string segment:

 

5 Gigunnwg gw kvrhhk Bxxa, gbcèow 969  9 Bvtjmdzv ti yllcau Sfzr-Bzvygpgnebkym,

 

Just this small portion would have created 13 separate sub-components for masking, and it  seems unlikely that this is the intent.

 

Please advise.

 

You did well to assume that we used FORMATENCRYPT1DELIMITER=(SPACE -), you will find the complete list of our runtime options here below :

 

LANGUAGE=EN
QUOTESTYLE=DOUBLE
MAPTYPE=FILE
AUDIT=ROW500
PAGELIMIT=9999
COMMIT=1000
PROGRESSCOUNT=10000
CASEINSENSITIVEFORMATENCRYPT=Y
FORMATENCRYPTEXTENDEDCHARS=Y
FORMATENCRYPT1IGNORESPECIALCHARS=Y
FORMATENCRYPT1EXCLUDESPECIALCHARS=N
FORMATENCRYPT1DELIMITER=(SPACE -)
HASHTYPE=JAVA

 

On our end we will test the masking of the same record on Windows and then compare it to the Mainframe.

It was confirmed to us by a colleague on the Windows end, they have the same exact issue as the Mainframe.

After several tests and internal discussions within our team, we’ve decided in these particular cases to mask with FORMATMASK

which for us is the most logical solution.  

That being said, we thankyou for your support and explanations.