Optim Data Privacy Providers
11.3.0
|
ODPP currently supports input data in single-byte character sets (SBCS), Unicode (UTF16/UTF32), and multi-byte character sets (MBCS). The code pages supported are the same as those supported by the Optim solution. At the moment, the list of the code pages and Unicode encodings supported by the Optim solution is split between the following two resources:
http://www-01.ibm.com/support/docview.wss?&uid=swg27021866
and
For ease of use, future releases of this information will be combined into a single URL location.
The following are limitations within the current ODPP implementation:
Lookup Service Provider:
The ODPP Lookup service on Linux, UNIX and Windows supports only DB2-LUW v9.1 and beyond. The ODPP Lookup service on z/OS supports only DB2 z/OS v8.1 and beyond.
Lookup limitation with double and float data type (RTC 40354)
For Real and Double data type columns, in a DB2 replacement table, ODPP supports only fields with Float and Double ODPP data types respectively. Using any other data type for such columns might result in the following:
others
The ODPP_METHOD_DEFAULT option is the only format that is currently supported for the “sMethod” argument in the Provider_Service() API.
The following are known issues, as identified by the RTC work item number, with the current ODPP implementation:
36233
For the National Identifier (NID) service provider, for the French NID, when the Department masking rule (i.e.. ODPP_FR_PARTS_MASK_DEPT) is used, ODPP produces an invalid French NID. This happens only when the Department masking rule is used. If the Department masking rule is used along with the Commune masking rule (i.e. ODPP_FR_PARTS_MASK_COMMUNE), then the results are correct. When all other masking rules are used, the results are correct
39591
For the Affinity (COL) service provider, when using the Double (e.g. ODPPDATATYPE_DOUBLE), the results are different between UNIX, Linux and Windows. The differences with Double is expected as the implementation of this data type is somewhat different on between UNIX, Linux and Windows.
The problem occurs with double when they are converted to a string for processing in ODPP. As an example, using the number 13, when it is converted in Windows it becomes 13.0000 and on AIX it becomes 1.3000000E01.
40354
For the Lookup (LKP) service provider, when a Double (e.g. ODPPDATATYPE_DOUBLE) data type is used and the source column value is more than 1-digit in length, the provider fails.
40445
For the Hash (HASH) service provider, when using the Double (e.g. ODPPDATATYPE_DOUBLE) data type the results are different between UNIX, Linux and Windows. The differences with Double is expected as the implementation of this data type is somewhat different on between UNIX, Linux and Windows.
The problem occurs with double when they are converted to a string for processing in ODPP. As an example, using the number 13, when it is converted in Windows it becomes 13.0000 and on AIX it becomes 1.3000000E01.