topic Re: SU53 understanding in Application Development and Automation Discussions

SU53 understanding

Former Member — Mon, 28 Jan 2008 16:20:27 GMT

Broad outline ofthe user Problem:

1. I am unable to submitt barchjobs which I was able to do it earlier:

I asked for a SU53 screen shot:here is the su53 output;

object; S_program ABAP program Checks

Object class: BC_C Basis Development Environment

Now we have a table Fld value

User Action ABAP/4 Program

BTCSUBMIT

Authorization group ABAP/4 program

ZMHX

Available authorizations for the object in Master Record:

Object; S_program ABAP: Program run Checks

Authorization ;T-DV45021600 Exsists in Buffer

Profiel :T-DV450216

Role : Z_XXXXX_SE38

table Fld value

User Action ABAP/4 Program

EDIT , SUBMIT, VARIANT

Authorization group ABAP/4 Program

Authorization ;T-DV45025600 Exsists in Buffer

Profiel :T-DV450256

Role : Z_XXXXX_SA38

table Fld value

User Action ABAP/4 Program

SUBMIT

Authorization group ABAP/4 Program

..............................................................................

Above was the SU53 screen Shot..can soem one shed some light?

Thanks

Re: SU53 understanding

Former Member — Mon, 28 Jan 2008 16:40:41 GMT

Hi George,

The SU53 is telling us that it is looking for

S_PROGRAM

Action: BTCSUBMIT

Auth Group: ZMHX

The ability to submit in background is not present in any of the roles that have been assigned to the user.

Does that clarify things?

Re: SU53 understanding

Former Member — Mon, 28 Jan 2008 16:54:16 GMT

Alex,

But this user has running background jobs !!

Re: SU53 understanding

Former Member — Mon, 28 Jan 2008 17:07:34 GMT

OK, first check. Could the user really submit background jobs before? (wouldn't be the first time or last time that they were trying to get extra access).

Did the programs that were submitted in the background have auth groups against them?

Has this users access changed recently? Different roles/different content of roles?

Have the programs that they used to submit in BG got auth groups against them?

Re: SU53 understanding

jurjen_heeck — Mon, 28 Jan 2008 17:12:05 GMT

Oops, I'll let Alex go first. Post deleted. same questions.

Edited by: Jurjen Heeck on Jan 28, 2008 6:12 PM

Re: SU53 understanding

Former Member — Mon, 28 Jan 2008 17:20:34 GMT

After you squire

Re: SU53 understanding

Former Member — Mon, 28 Jan 2008 17:40:42 GMT

1. In the "profile" tab the profile is T-DV450850

On the compare thru SUIM the profile gets a number T-DV45085003 why is this difference ?

Re: SU53 understanding

Former Member — Mon, 28 Jan 2008 17:44:29 GMT

"Did the programs that were submitted in the background have auth groups against them?"

How Do I determine this ?

Here is what I did ?

I did compare the user against another and the user is lacking the object BTCSUBMIT

but this object is shown to be present in the profile 45085003 which is 450850 in the profile tab of the user

Edited by: george G on Jan 28, 2008 6:56 PM

Re: SU53 understanding

Former Member — Mon, 28 Jan 2008 18:13:23 GMT

"Did the programs that were submitted in the background have auth groups against them?"

How Do I determine this ?

We can find if a program has authorization group against them using se38 and selecting attributes of the program. The authorization group contains the auth group assigned to the program.

We can also find it from the table TRDIR.

Re: SU53 understanding

Former Member — Tue, 29 Jan 2008 08:36:20 GMT

> 1. In the "profile" tab the profile is T-DV450850

> On the compare thru SUIM the profile gets a number T-DV45085003 why is this difference ?

Hi George,

The profile contains Authorisations which are numbered sequentially with the profile number (T-DV450850). Each Authorisation is an object and a set of values.

Hence the 3rd set of auth values would be T-DV450850003

Profiles can only contain 150 auth sets, hence large roles often have >1 profile generated for them.

Re: SU53 understanding

Former Member — Tue, 29 Jan 2008 13:36:32 GMT

Hi George,

Just for the record: SU53 shows the last failed authority-check prior to SU53 executing.

In this case, my interpreation is that you are not authorized to schedule a report with this or any other authorization group into a job-step or via SE38 => Program => Execute => Background or several other transactions, as the system simulates the check at the time of scheduling the report. However you can run it in the foreground (P_ACTION = SUBMIT) and scheduled jobs with this program already "scheduled" are unhindered as they are run via their variants (P_ACTION = VARIANT).

P_ACTION = EDIT is obsolete, so I doubt that you need it.

Of course, you have P_GROUP = *... so there might be a way around that...

Cheers,

Julius

Re: SU53 understanding

Former Member — Wed, 30 Jan 2008 14:25:46 GMT

Thanks Alex, Juluis!! Spend time on it,learned a lot from all your inputs and iimplemented them. Sucessful in the batch runs.