The documentation for RCAC (Row and Column Access Control) does a much
better job of explaining their technique. Basically it says if you do an
update and you do not have authority it just ignores your attempt to
update it and does not flag it back as an error. This way you can mask
the SSN and not have to change all your existing RPG applications to
handle an error on a write or update.
https://www.redbooks.ibm.com/redpapers/pdfs/redp5110.pdf
Row and Column Access Control Support in IBM DB2 for i
<snip>
3.5 SELECT, INSERT, and UPDATE behavior with RCAC
RCAC provides a database-centric approach to determining which rows can be
accessed and
what column values can be seen by a specific user. Given that the control
is handled by DB2
internally, every data manipulation statement is under the influence of
RCAC, with no
exceptions. When accessing the table, the SELECT statements, searched
UPDATE statements,
and searched DELETE statements implicitly and transparently contain the
row permission and
the column mask rule text. This means that the data set can be logically
restricted and
reduced on a user by user basis.
Furthermore, DB2 prevents an INSERT statement from inserting a row or an
UPDATE statement
from modifying a row such that the current user cannot be permitted to
access it. You cannot
create a situation in which the data you inserted or changed is no longer
accessible to you.
For more information and considerations about data movement in an RCAC
environment, see
Chapter 6, “Additional considerations” on page 85.
Note: DB2 does not provide any indication back to the user that the data
set requested
was restricted or reduced by RCAC. This is by design, as it helps minimize
any changes to
the applications accessing the data.
</snip>
Field procs need this kind of documentation.
Searching the redbook site for "field proc", "field procs" or "field
procedures" always returns zero hits.
Rob Berendt
midrange.com
