The problem can be identified by executing 'sewhoami' from the <Access Control Home>bin directory. In case the output is 'root', then it's a potential problem with the Login Application definition/rule within PIM for the specific login program that is being used.
In most of the cases where and in-correct user name/id is reported after a login sequence, it is the wrong definition of the LOGINAPPL record for a specific login program that is being used. Wrong definition does not point to the name of the LOGINAPPL record but to the login path that is used.
To know the correct path of the binary to be mentioned in the 'login path' for the LOGINAPPL, generating a trace while performing a login and logoff using the same login application will help.
The other likely cause for misinterpretation/misunderstanding of the user identity by PIM could be a wrong 'login sequence'. The current login sequence followed can be looked upon in the trace file, pls. lookup the Reference Guide for more information regarding the login sequence. Manipulating the login sequence in the correct order would also help in overcoming the problem.
In case of third party login applications are being used, PIM does not define a LOGINAPPL for this third party login application and performing a login using the third party login application can also cause the same problem of a user being recognized as ROOT user. Appropriate LOGINAPPL's for third party login application needs to be defined manually.