Nobody has read my answer before?
You need to add either a constraint with the ON VIOLATION Clause or a SECURED trigger to your file with RCAC for avoiding the data is overridden!
I a constraint with the ON VIOLATION clause or a SECURE trigger is added to your table, even RPG native I/O will not override the value.
When debugging your RPG program and if you are not authorized to see the masked value, you'll only see the masked value.
Here again a sample check constraint:
Alter Table YourSchema.YourColumn
Add Check (YourColumn like 'XXXX-XXXX-XXXX-%') -- compare with the masked value
On Insert Violation Set YourColumn = Default
On Update Violation Preserve YourColumn;
And here a Sample Before Insert/Update Trigger
Create or Replace Trigger YourScchema.Replace_Mask_YourColumn
Before Insert or Update On YourSchema.YourTable
Referencing New Row as N Old Row as O
For Each Row
Mode Db2Row
Secured
When (n.YourColumn like 'XXXX-XXXX-XXXX-%')
Begin
If Inserting Then Set N.YourColumn = Default;
ElseIf Updating Tnen Set N.YourColumn = o.YourColumn;
End If;
End;
If you have a RCAC project the responsible for this project or your database responsible has to plan and add the appropriate Check constraint or trigger.
As soon as implemented the original values are NOT overridden and you do not have to care about ANY program with NATIVE I/O or CPYF!
Just as an aside, when using CPYF is used for copy data or generating a new file. The masked values and only the rows for which the user is authorized are copied. RCAC Rules are not implemented on the new table.
When using CRTDUPOBJ an exact duplicate is generated with the unmasked values and all rows. But also the RCAC rules are copied!
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
„Train people well enough so they can leave, treat them well enough so they don't want to.“ (Richard Branson)
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Peter Dow
Sent: Freitag, 31. August 2018 20:35
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Another FieldProc question
I'll say. However, at least it didn't update it with the masked value, i.e. masking is one-way. Of course as Jon Paris pointed out, if you had a program that reads the record, then updates it without excluding that field, then you'd update it with the masked value. A real landmine.
On 8/31/2018 9:55 AM, Rob Berendt wrote:
ROB sees the whole 234-56-7891, which makes perfect sense, based on
the masking.
What doesn't make sense is that DUMMY1 was allowed to change it.
Rather confused by the conflicting information in that redbook.
Rob Berendt
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
