We were recently asked about the impact on existing RPG programs of the new Row and Column Access Control (RCAC) DB2 support in V7.2. For those who haven't yet heard about RCAC, the simplest explanation is that it allows you to control access to data by row (aka record) and by column (aka field). The column control masks specific data from people who don't need (or shouldn't be able) to see it. Think seeing masked data for salary, credit card numbers, etc. The row control simply omits access to the entire row for unauthorized users, much as a select/omit LF with specific user authorizations could do--only it's probably a bit easier to implement.
We haven't fully thought through some of the implications of row control yet. Clearly there is a difference between "These are all the rows that satisfy your query" and "These are all the rows that satisfy your query that you are allowed to see." But how much that matters and its impact on our application design we need to muse on for a while. There appears to be no feedback to tell you that your result set was constrained so we can foresee some interesting debug problems when a user reports that they only received X rows and your tests show Y but I guess we'll get used to it.
Column control is a little different in that you will receive a value--just not the real one. Because you can supply masking values for columns that have limited access rights, this is not much of a problem in handling character fields. We're all used to seeing things like XXXX-XXX-XXX-1057 for a credit card number in an email or report. Character columns can normally be masked with characters that could never otherwise occur in them, and if you wished, these could be standardized for all columns in the shop. As a result testing for a masked column is not that difficult a feature to add to an existing program that processes the table.
Dealing with numeric columns, however, could be a bit more of a problem. While most columns will have some limit (e.g., this column can never contain zero, another can never exceed 50,000, another can never be negative, etc.) they will rarely fit into a single pattern and so a standardized approach won't be possible. In some cases we might need to mask to a negative value, in others to all 9s, etc.
One thing is for sure, you cannot simply apply RCAC to an existing table and program combination and just "let it fly"--particularly if math is involved on the column in question. You need to think through the impact on your code and possibly make adjustments in the logic to accommodate the new situation.
We find ourselves thinking it would be nice if the database returned a status of some kind with each row/set to indicate that some data is "missing" due to RCAC considerations. After all, we've been increasingly using null capable columns to handle situations where a special value in a column just doesn't work. Having to go back to using special values makes it feel as if we have taken two steps forward and one step back, at least from a programmer's perspective.
While this new support is both important and useful, we do feel that the lack of any standardized way to readily detect "lost" data may be problematic. But maybe we just worry too much. What do you think?