Sorry to say this, but what you are doing there is rather silly actually, not only because updating SAP tables without respecting change documents and application logic can in worst-case lead to cancelled support for the problems it causes. See SAP note 7… 🙂
In this case the system only respects the bit masks which it knows and these are summed into the uflag field. Any values which it does not know any cannot calculate the masks for are ignored and considered to be 0 -> unlocked.
When SAP BC team locks the users to do their job (maintenance, upgrade or whathever), they use a program to add 1 in the Uflag. So when they have to unlock the users they know which ones they locked and which ones were already locked by admin or other reasons. So when they have finished their job, they launch another program to do -1 to Uflag. Update usr02 set uflag = ' where bname in xbname. Elseif xlock = 'x'. Update usr02 set uflag = ' 64' where bname in xbname. user not lock (include yours, just in case) and bname 'sap.' and bname 'ddic'. If sbname = 'x'. Perform bnamertn. Perform classrtn.
Sap Uflag 224
Sap Uflag 128
As this regularly creates big messes (particularly updating single fields of USR02!) I offer a freeware tool which uses BAPIs to lock and unlock users and remember which ones you changed and protect certains admins from locking themselves -> http://xiting.ch/en/produkte_user_locking_tool.php
Sap Usr02 Uflag Values
Cheers,
Sap Uflag Table
Julius