


The 'Status' value isn't directly and totally related to the PasswordVerifications value though they can affect each other. A sufficient number of failed verifications can change the 'Status' to *DISABLED if the system is configured for it, but a profile can be disabled in other ways. If a profile's 'Status' is explicitly changed from *DISABLED to *ENABLED, the PasswordVerifications value will also be reset to zero.
But those values are "state" values, not audit values. They show current state not an audit trail.
If you need to track audit information, you should be processing audit journal entries.
Tom


There is no file that stores the value unless you create one with DSPUSRPRF. The field is supposed to contain a value that is either zero or greater than zero. The field value comes from the *USRPRF object, out of its password verification failures attribute. The attribute is reset to zero as soon as a password is verified for the profile. What would you expect it to contain? — Tom
Following is taken directly from the help text for the value in question after pressing F1 on that line of information on an interactive disply of the DSPUSRPRF command.
The number of password verifications that were not valid for the
specified user since the previous successful password verification.
Passwords are verified by sign-on operations, various servers such
as File Transfer Protocol (FTP), and API calls such as Get Profile
Handle (QSYGETPH).
When the password is successfully verified, this field is set to 0.
Well, the bottom is the value I need to explain. I query out the file created using DSPUSRPRF and one user attempt to sign to the system 13 times. This is a cumulative number. How the system tracks the number? Was this done the same day? and what is odd the account status remain *Enabled.
Password verifications not valid . . . . . : 13
Status . . . . . . . . . . . . . . . . . . : *ENABLED