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
Showing results for 
Search instead for 
Did you mean: 

We are taking out SA38 from Production...Any consequences..

Former Member
0 Kudos

Team,

We have already created transaction codes for every (executable only; i.e. TRDIR-SUBC = 1) zprogram.

Idea is to monitor what zpgrams are being used... and over a period of time we will eliminate non used zprograms (clean up).

We are taking away SA38 access from users. Are there any negative (or positive) effects of this?

Should we take SA38 from all users... Or restrict to dialog users, system users, etc. ...

Any input is highly appreciated and rewarded...

Thanks

1 ACCEPTED SOLUTION

manuel_bassani
Contributor
0 Kudos

Hi,

i think SA38 is not critical for dialog users. We always create transactions for our custom developments (and many user don't even know the existence of SA38 )

As far as i know system users do not use SA38.

So in my opinion you can block SA38 (with authorizations or with SM01)

Regards, Manuel

12 REPLIES 12

suresh_datti
Active Contributor
0 Kudos

Hi,

Nothing negative.. you will only have to remember to keep creating Transactions for all the Programs that need to be executed by the Users.. dont worry abour Developers, they will always figure out the 'back doors'...

Good Luck,

Suresh Datti

RichHeilman
Developer Advocate
Developer Advocate
0 Kudos

I have not seen a problem with this.

Regards,

Rich Heilman

manuel_bassani
Contributor
0 Kudos

Hi,

i think SA38 is not critical for dialog users. We always create transactions for our custom developments (and many user don't even know the existence of SA38 )

As far as i know system users do not use SA38.

So in my opinion you can block SA38 (with authorizations or with SM01)

Regards, Manuel

0 Kudos

I ran 'where-used-list' in se93 for SA38. There are many places (about 15) where 'SA38' is being hard coded in standard SAP code (not in zprograms); for example CALL Transaction 'SA38'. One place is SYST area menu...

We are on 4.7

0 Kudos

There should be absoultely no issue if you take out SA38.. ours is gone from day one .. it has been 4 years..

We are on 47 too

have fun,

Suresh Datti

Message was edited by: Suresh Datti

0 Kudos

Hi,

the presence of SA38 in SYST menu area is normal (like the presence of many other transactions) but it does not mean that users shall use it.

Manuel

0 Kudos

But your intention is to monitor the use of Z transactions, not the SAP transactions anyway. So, even if it is used by SAP transactions, you should be ok, unless those transactions are also required for your end users, which I doubt.

If it is used in area menus, that is not a problem. Your users still will not be able to access it. There are several transactions in every area menu, but not all are accessable to every user. This will be one of them.

0 Kudos

To add to the thoughts, heres what I've usually seen:

We've had SA38 taken away and actually replaced with custom built Area Menus. We hooked up the custom transactions to them (or area menu also can generate a t-code).

Custom built area menus will need to be controlled by roles and assigned by Security, so access will be restricted.

Thanks,

Anand

Former Member
0 Kudos

I don't there is any problem as long as the executable programs have transaction codes associated with them for the online users to use and developers don't need to debug the programs in production for troubleshooting purposes.

In fact, some auditors do recommend taking it out. What I would like to suggest is that you remove its access to the users, but keep it for your developers.

Regards,

Srinivas

Former Member
0 Kudos

There is no problem in retaining the access to SA38..

0 Kudos

You can retain for Developers only.

Former Member
0 Kudos

Positive effects - you'll be able to control access to programs more effectively using authorizations for the transactions.

Rob