« Tempus Fugit, Don't It? | Main | Programming Highs and Tire Lows »

July 01, 2014


Christian Massé

There is also an other problem:

if you still use RPG for native I/O on a file with a MASK, the RPG receive masked data (XXXX-XXX-XXX-1057) and when updating the record, that's this masked value (XXXX-XXX-XXX-1057) that will be put back in the record (even if you use %FIELDS() bif to protect this column, i made a test)

So impossible to use a MASK on a file when there is RPG "around", except using a trigger to correct the column.

John Erps

No i don't think you worry too much. Better too much than too little, especially this kind of stuff. I read about RCAC, which is a necessary feature IMO, but i didn't really delve into it and didn't know about the masking approach. Setting a mask on a column should be done very carefully, thinking about the impact of it and the effect it has when processing data. For example, like you said, when doing calculations. If the credit limit of a client is based on his salary, and the salary is always 999,999,999.99 you may have a huge problem. Masking is a nice and easy way to implement it, without needing to change the software, but only applied very carefully. But it shouldn't be the only option. So yes, i believe there should be an API to explicitly check that a value is not a "real" value but an imaginary one.

Kent Milligan

Not sure what's going on with %Fields function. However, there is new DB2 support so that the application doesn't have to use the %Fields function to prevent accidental updates with masked values.

A check constraint can be created with the new ON UPDATE clause to prevent masked values from overwriting the card number value.

CONSTRAINT masked_card_check
CHECK( SUBSTR( card_num , 1 , 13 ) <> 'XXXX-XXX-XXX-' )

No error is signalled to the application, the masked value in the buffer is ignored and the original card number value is preserved.

The comments to this entry are closed.