01-28-2008 4:20 PM
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
01-28-2008 4:40 PM
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?
01-28-2008 4:54 PM
01-28-2008 5:07 PM
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?
01-28-2008 5:12 PM
Oops, I'll let Alex go first. Post deleted. same questions.
Edited by: Jurjen Heeck on Jan 28, 2008 6:12 PM
01-28-2008 5:20 PM
01-28-2008 5:40 PM
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 ?
01-28-2008 5:44 PM
"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
01-28-2008 6:13 PM
"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.
01-29-2008 8:36 AM
>
> 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.
01-29-2008 1:36 PM
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
01-30-2008 2:25 PM
Thanks Alex, Juluis!! Spend time on it,learned a lot from all your inputs and iimplemented them. Sucessful in the batch runs.