Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

SU22 - Standard Proposal for SE16N

Go to solution
former_member246457
Explorer

‎01-25-2016 6:54 PM

0 Kudos

Hi all,

I noticed that SE16N does not have a proposal set for S_TABU_DIS in SU22.

From my point of view this does make sense, since S_TABU_DIS is necessary for SE16N as much as it necessary for SE16.

Is there a valid reason which I might be overlooking?

Cheers,

Peter

1 ACCEPTED SOLUTION

Go to solution
Former Member

‎01-25-2016 9:11 PM

0 Kudos

Several "general table browser" transactions used to have an entry for S_TABU_DIS in table TSTCA (additional start auth check). As a value in the field(s) did not make sense, this had the unfortunately side effect that all the parameter transactions for those generic ones inherited the open field proposal if they had none of their own.

Then when S_TABU_NAM came along as an alternative, the S_TABU_DIS entries in TSTCA had to be removed as S_TABU_DIS is basically optional and TSTCA would otherwise force it.

When you maintain SU24 you sometimes get a message stating that "proposals have been automatically corrected". That is mostly TSTCA adjusting your SU24 data to that which the tcode will force - from days gone by when there was no S_TCODE check.

So it is removed from SE16, SE17, SM30, SM31, SM34, SE16N, etc etc.

Even before this, I used to remove it or maintain a dummy value like @ in SU24 for them so that the inheritance is disabled and the parameter tcodes must have their own values.

Cheers,

Julius

1 REPLY 1

Go to solution
Former Member

‎01-25-2016 9:11 PM

0 Kudos

Several "general table browser" transactions used to have an entry for S_TABU_DIS in table TSTCA (additional start auth check). As a value in the field(s) did not make sense, this had the unfortunately side effect that all the parameter transactions for those generic ones inherited the open field proposal if they had none of their own.

Then when S_TABU_NAM came along as an alternative, the S_TABU_DIS entries in TSTCA had to be removed as S_TABU_DIS is basically optional and TSTCA would otherwise force it.

When you maintain SU24 you sometimes get a message stating that "proposals have been automatically corrected". That is mostly TSTCA adjusting your SU24 data to that which the tcode will force - from days gone by when there was no S_TCODE check.

So it is removed from SE16, SE17, SM30, SM31, SM34, SE16N, etc etc.

Even before this, I used to remove it or maintain a dummy value like @ in SU24 for them so that the inheritance is disabled and the parameter tcodes must have their own values.

Cheers,

Julius