Trying to think out of the box to resolve a situation that I am having with the migration from TSS to RACF, and to use Command Verifier to help in the effort.
TSS has 2 SUSPEND attributes called ASUSPEND and PSUSPEND. ASUSPEND is when an administrator suspends the User ID, and PSUSPEND is when the USER ID is suspended for excessive password violations. With RACF we can not tell why the User ID was REVOKED. Was it due to excessive password violations or due to some administrative function. Our helpdesk does not want to RESUME a User ID if it was REVOKED due to some administrative process (i.e. on leave, termination).
It was suggested by IBM to create a new field in CSDATA that would allow us to place an indicator if the User ID was revoked for some administrative process. I am fine with that approach, but my concern is keeping the field maintained. How can I ensure that the field is added and removed consistently and not rely on a person to properly maintain that field.
Is there a way in command verifier that if it detects a ALU userid REVOKE coming from certain administrators that it could also add ADMREVOK(YES) to he User ID as well. Same with a ALU userid RESUME to remove the ADMREVOK field. Thoughts? Concerns?
Another thought would be if Command Verifier could detect the counter for invalid passwords reaching the threshold to may be set PSWDREV(Y). Right now the counter resets to zero when the User ID is revoked.
------------------------------
Linnea Sullivan
------------------------------