We use 4 policy names, POLICY#, in round robin fashion. When we get to the
POLICY4 we go back to POLICY1. We also have a process we use for WLM changes
that would allow us to quickly reactivate the policy the way it was before the
last activation.
Keeping back out options available are always
Right, definitely bad practice. How do they fall back? New name is
the only way to go.
On 12/9/2022 9:16 AM, Mark Jacobs wrote:
At $currentjob whenever an XCF policy is changed and stored in the couple
dataset their standard practice is to replace the current active policy using
the same n
that was the policy when I started at my current gig, I now manage the
policies so I usually cycle from CFMRPOL1 - 2 .etc...
activate the new policy (2), if there' issues I just reactivate policy (1)
Carmen
On 12/9/2022 9:16 AM, Mark Jacobs wrote:
At $currentjob whenever an XCF policy is chan
At $currentjob whenever an XCF policy is changed and stored in the couple
dataset their standard practice is to replace the current active policy using
the same name, CFRMPOL as an example, then activate it. IMHO, this is a bad
practice. I always wrote the updated policy with a new name, then ac
