Re: AS/400 UserID.

On 14 May 2013 10:13, John Mathew wrote:

Where does AS/400 User Id and password will be stored, I mean in
which Physical file

Can we view the physical file?

The architecture is /object based/ and the *USRPRF object is the symbolic name for the object-type that defines the "User ID" for which a password is an associated attribute. The User Profile (*USRPRF) objects are stored in the Machine Context as object type x08 and subtype x01; this information is exposed\visible from a request to DMPOBJ of an OBJTYPE(*USRPRF). The /objects/ in the architecture are not just rows in some TABLE, nor is a row automatically deposited into some physical database file [aka TABLE] to track each user profile [although that could be implemented; by the OS if customers requested that, or as effected by the system owner\admin if desired]. Some attributes of a created or changed user profile are available in the audit records, if auditing is active, then that physical data can be reviewed [and thus can be queried, even if indirectly per being in a journal receiver instead of a database file].

Whatever attributes are available to be retrieved about a user profile can be presented as physical data from a database physical file [which had been populated previously], or the data could be provided more dynamically via a logical definition of a TABLE using a User Defined Table Function [which was previously registered to the SQL, and thus can be queried by the SQL SELECT]. For the password, only the encrypted password can be obtained; maintained as binary data, this value can be applied to the same user profile object on another system, to keep the passwords synchronized.
_i Retrieve User Information (QSYRUSRI) API i_
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qsyrusri.htm
_i Retrieve Encrypted User Password (QSYRUPWD) API i_
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qsyrupwd.htm
_i Set Encrypted User Password (QSYSUPWD) i_
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qsysupwd.htm

On some systems that I had managed long, long ago, a database file with a unique key [before PRIMARY KEY constraints were available] was used as the implementation for one portion of the overall system change management. The password was a null-capable column and was NULL for all users profiles except those which were defined to have PASSWORD(*NONE). I never finished with the encrypted password being stored as well. Anyhow, that file could be used to compare and contrast with the results of the output database file from DSPUSRPRF *ALL TYPE(*BASIC).