1) When (if) we transition from:
PERMIT(profile1) DSN(sales.data.set.name) ACCESS(ALL) DSKEY(sales.keylabel.name) PERMIT(profile2) DSN(sales.data.set.addr) ACC(ALL) DSKEY(sales.keylabel.name) and other various similar rules
ALTADD(salesdpt) DSN(sales.) DSKEY(sales.keylabel.name)
What happens to all those permits? There could be 2 or 200?
The permits would have to be revoked and permitted without the DSKEY. When a dataset is opened, DFSMS issues an EXTRACT call. CA Top Secret first searches the permits and, if not found, CA Top Secret searches the ownership.
2) Key Rotation - When the current key needs to be replaced with DSKEY(sales.keylabel.newname) do I?
Revoke and PERMIT all those rules with the new label (if still using the permit option)?'
Will ALTADD(salesdpt) DSKEY(sales.keylabel.newname) work?
Yes Can the doc be updated to clarify that using ALTADD for replacing a key label with a new key label is the correct process to change keys for an application?
Yes 3) There is only one mention of CSFKEYS in this whole document. There is a significant amount of information missing about support for VSAMSMS and it's need to have access to the CSFKEYS resources to assist in VSAM RLS dataset processing when implementing Pervasive Encryption?
While we work to have more information accounted for in the doc, here is some information from IBM that you might find useful related to this:https://www.ibm.com/support/pages/apar/OA58159Talk to you soon!