# Uflag Values 1 – 65 – 97

Someone asked me about Uflag value in table USR02 and of course I knew the most common ones but he asked me about values I had never seen like 1 – 33- 97 (so regular values +1).

In the help of the system we only can see this, it was fast and easy to understand that 96 came from 32 + 64 and so on. But I had no idea about the +1 !

 User status Reason 0 User not locked 32 (Hex 20) Locked by CUA central administrator 64 (Hex 40) Locked by administrator 128 (Hex 80) Locked after failed logon 192 Locked by administrator + Locked after failed logon 96 Locked by CUA central administrator + Locked after failed logon 160 Locked by CUA central administrator + Locked after failed logon

I googled it for 30 minutes but didn’t find a clear answer, so I asked my colleagues who didn’t know neither.

I finally asked my boss, who worked for SAP BC Team and has a good knowledge about SAP.

Here is the explanation about the 1 value !

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. So logically, if the job is correctly done, the results is always equal to the figures from the table above.

It can happen that the administrator does the unlock before SAP BC, so the calculation is : +64 locked by admin +1 locked by BC -64 unlocked by admin which gives 1

Another example : user locked by CUA + administrator + BC Team : 32 + 64 + 1 ==> 97

For a reason or another the -1 work is not performed so the values are addioned by 1.

This rule can be applied to all values.

Nicolas.

### Assigned Tags

You must be Logged on to comment or reply to a post.

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.

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

Cheers,

Julius

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.

Hi Julius,

not sure what exactly you mean by this. But I don't think that adding 1 to this field will cause system to think that it's unlocked. I don't have any proof. Usually, in C you check for a specific field by performing bitwise AND operation with default mask for that bit and check if result is zero or not. So the garbage bits get ignored. The only issue would be if you added values corresponding to bit values such as 32. But the lowest value used by SAP is 32 that corresponds to 6th bit. So you have 5 bits that can be used.

I don't want to say with this comment that it's a good idea to modify this field directly.

Cheers

Hi Martin,

The users you would be wanting to lock will have a uflag = 0. So adding +1 as a "marker" to everyone will have no bitflag value and the update is meaningless for those who already had a higher bit mask and should have been left in peace.

So it has no affect on the users and their user account and password lock status. It just creates pulp in the database...

These types of programs are often not protected sufficiently, so a bit flag of 32 (locked by central CUA admin) could also be unlocked by running the program in unlock mode 32 times -> bypassing CUA config and authorizations and the auditability to reconstruct who unlocked the user ID.

Not a good idea...

Cheers,

Julius

Correction: actually you would only need to run it once in unlock mode if locked centrally by CUA admin, because 31 = 0 in the UFLAG bitmask world!

Cheers,

Julius

Yes, you are right. But a clever programmer would check if the first bit is set to 1 before decrementing value of this field.

Cheers

The problem is that contrary to the expectation incrementing UFLAG = 1 does not do anything in the first place, so we can exclude the existence of a clever programmer here... ðŸ˜‰

@ Nicolas: can you please do a where-used-list check from SE11 on table USR02 and post the Z-code (that is assuming it is done from ABAP and not the DB)? We are curious...

Cheers,

Julius

You won't believe, how often I have seen these 'modified' values already in different customer systems.... Until now I was not able to identify the 'publisher of that modification code', as I suppose, that somebody runs around and provides this UFLAG-modification scenario as proper solution... (I hope, this is no SAP or SAP-partner coding...)

b.rgds, Bernhard

Hello Julius,

When I tried to download the tool there was a response page telling me "Please fill in all fields" even I did. (I promise!!!)

Could you please verify that? Would be great to use that tool for systems with missing transaction EWZ5.

Best regards

Sacha

hmm... we will fix the download request form soon, but you can also mail me (see my profile details) and I will mail the free tool to you.

Cheers,

Julius

Former Member
Blog Post Author

Hello Julius,

Thanks for your message, but as I wrote, our team doesn't update the flags, it's another team who does, so we are not to blamed.

I work in a big company and that team has a way of working we cannot change...

Nicolas.

Hi Nicolas,

Regards,

Felipe Fonseca