Making a program not debuggable

[julianbrand]

Hi Community,

I've searched for a long time, but nothing found in the Community or Google.

I want to make sure, that a program can't be executed on our productive System.

I'd like to say:

if 'P13' eq sy-sysid.

leave program.

endif.

But there are some developers who can change variables (e.g. sy-sysid) in die produktiv system.

Is there any way to say sy-sysid is constant ?

Regards

Julian

[former_member201275]

They shouldn't have authority to change this variable in Production!

Nevetheless you can code your own authority-object to limit who may run the program. I would discuss this first with security team as they could probably help you, and then also google on how to code authority object in abap.

[former_member201275]

argh... forgot to attach link to my previous reply. Here you go: http://scn.sap.com/thread/706673

[Former Member]

Hi Julian,

Can I maybe broaden out your question, if you don't want a program to be executable in your production system, why put it there in the first place?

On the assumption you have a program that would need to run in Test environments but could do real damage in production, don't transport it.  Create the program as a local object in each system you would want to use it.

It feels like there could be ways to solve this problem other than trying to control the execution in Production.

Regards,

Nick

[SuhaSaha]

Hi Nick,

I have the same questions/thoughts as you do.

In the program attributes we can set the "Status" as "Test". Does this somehow effect the execution of the program in a productive environment? Any ideas?

I did not find any helpful info on the internet

BR,

Suhas

[Former Member]

Hi Suhas,

I don't have access to a Production system these days so I can't state this definitively, but there are lots of SAP standard programs with status 'Test'.

These could be correctly classified, but does include thing like for example RSSCD200 (a Change docs report), so I've a feeling we'd have seen the impact of this functionality before now.

Good line of thinking though.

Regards,

Nick

[julianbrand]

Hi,

thanks for your response. Our devolpers (including me) need the debugging- authority in production.

And thats the reason why we can't code any authority object. You can set subrc from 4 to 0 and

it goes through,

I already thought about no transport. But if we need the program in Quality- System

it's not in there and every systemcopy would overwrite the program.

Regards,

Julian

[Tomas_Buryanek]

Helo,

I understand what do you need, but why would any developer run that program on production and changed variables (bypass system check) in debugger?

If it would be intentionally - you would have to disable debugging in whole system to prevent intentional bypassing. Or set standard S_DEVELOP (DEBUG Activity 02 - ) auth. object for specific developer roles...

[Former Member]

Hi Julian,

I see the problem caused by system copy in this case, you've clearly put some thought into this!

My only idea would be to put the system check into a macro and call this as the first line of the program (the INITIAIZATION, assuming there's a selection screen).  The macro can't be debugged and if it's the first execute line of the program there's no opportunity to change the value of the system field before the check.

Regards,

Nick

[former_member1716]

Hi Julian,

You can use the same code you have mentioned above, ideally the users wont have any access to your program and as a developer you will be having the provision to debug which is right.

i would request you to declare the production system name(P13 i suppose) in a variable as a constant instead of declaring it directly. Because even in debugging you wont be able to change the constant value.

Also am not sure what all your issues exactly, can you brief on it?

regards,

Satish

[former_member192897]

You can very well control this using Basis authorization for Debugging activities. Check with Basis team and they will help you out..

[kiran_k8]

Julian,

First thing first.Debugging in Production is not at all recommended.Even if for some reason if it is allowed as an exception for a specific case,Security team can provide you the authorisation to Debug in such a way that you can Debug but you will not be able to change any values in the debugging mode for ex sy-subrc 4 to 0  etc.

IMHO,debugging in Production should not at all be allowed under any circumstances.

K.Kiran.

[former_member205488]

Hello!

You colud include the whole code fragment which shouldn't been debugged into an ABAP macros:  DEFINE...END-OF-DEFINITION.

But in this case you will not be able to debug it in DEV and QAS systems as well.

[julianbrand]

Yes, that's it.

But you can't read sy-sysid (can be debugged in Load-of-Program oder before macro starts.

Instead I used an function module. Here's the code. You can do anything. Program is not debuggable.

define test.

data: lt_test type table of /sdf/keyandvalue,
      ls_test like line of lt_test.

call function '/SDF/SYSTEM_INFO'
   tables
     system_info = lt_test.

   loop at lt_test into ls_test where key = 'DBNAME'.

  if ls_test-value eq 'T13'.
     leave program.
   endif.


   endloop.


end-of-definition.

load-of-program.
test.

Great. Many thanks.

Regards,

Julian