USOBT_C corrupt??

Question: I will try to explain my problem as best I can.

In Dev 900 (Security development client) I am having a strange situation when I add a transaction to a role but only in a small number of occurences.

Open role > add transaction to menu > go to authorization tab (profile) to tweek the oject values. I am finding 2 situations to be strange.

1. As opposed to appending and object with additional values from USOBT_C in certain cases it's changing the original value.
Example -
S_ARCHIVE - Activity 03
Application Area - BC
Archiving object - Workitem

When I add a transaction that would call this object from USOBT_C - it should add an additional authorization as opposed to changing the original. Instead, it's overwriting the existing authorization with an activity 01

This is where it gets really strange to me which is situation #2 -Tthe transaction I'm adding to the role doesn't even call S_ARCHIVE in the USOBT table. I'm adding SE16 and everbody knows that calls only S_TABU_DIS and S_GUI.

So - Why is the table overwriting an existing authorization as oppsed to appending as it always does? Secondly - why is a transaction changing objects in a profile when the transaction has absolutely no relationship to said object in USOBT_C or for that fact, in the ABAP code although the code has no impact at this point?

Final observation - I have only noticed this happening in a few instances. In most cases, transaction/table/profile/authorization relationship works as expected.

Hope my example makes sense and I greatly appreciate any guidance.

For reference we are on Enterprise 4.7.

Answer:
Use the overiview Icon for the object being overwritten. When you add a tcode SAP sets the "read old merge new" ( which you sould be using on every entry to a standard rolel and when it does this it evaluates EVERY tcode not the one you added. You may find the object being changed is in accordance to the configuration of SU24 for an unrelated tcode...

I would say, working as designed...with one exception, there is a kernel patch and upgrade that will cause PFCG to destroy all your roles. You must go tothe next patch.

Answer:
Thanks John,

Any idea on the specific kernel patch. The reason I ask is that I did notice the last support pack Basis put is is when this problem began. In our training environment which is not on that support pack, I can't duplicate this problem which did lead me to believe that may have an impact.

Thanks for the comments.

Answer:
I beleive there was a posting here a month or so back that has the specifics. I'm not where I can look it up... But when I get a change I will.

Answer:
I remember a posting from some one who bantered on about having your prod system on a higher patch level than your training system.

Maybe the problem is indeed training related?

Jaba

Answer:
Thanks Jaba but in our case, it's not a training issue. The training box (separate instance) is the only place we do not have the issue and that may be because it's on an older patch level. Our production landscape - Dev>QA>PRD is on a higher patch level. Right after Basis installed the support pack is when we noticed the issue. Prior to the current support pack, our production landscape was on the same kernl patch as what the training box is on now and it worked fine then.

That's why I'm interested in learning of the kernl patch John mentioned that could cause PFCG to do strange things.

thanks for the responses.

Answer:
HogFan . i beleive with Basis support 48 the condition shows up. see OSS Note 679050 for details.
_________________