To Restrict SM37 to view batch results

[Former Member]

Hey Guys,

Is there any possibe way to restrict users to view other users batch results in SM37?

I have gone through the earlier related threads but didn't get any valuabale answer.

Waiting for reply.

Regards,

HK

[Former Member]

What have you tried so far?

Waiting for reply

AA

[Former Member]

Nothing actually,we cannot restrict display access in SM37,so I dont have any idea how to restrict display of other's spool details.

[Former Member]

Take a look at replacing SM37 with SMX and only giving SM37 to users who need to view different jobs and then restrict by job name in S_BTCH_JOB

[Former Member]

> ... restrict by job name in S_BTCH_JOB ...

Won't work. The jobgroup field is "reserved for future use" since release god-knows-what and only knows '*'.

But probably you meant S_SPO_ACT --> for spool one has to read the documentation (no way around it) and trace it to reach the check when a) your ID is different to the creator of the request and b) the request is created by a program (more reliable than humans...) which adds an explicit SPOAUTH value to it.

The best solution (in my opinion) is to process the output immediately and delete requests automatically if no errors messages are returned.

Cheers,

Julius

[Former Member]

Thanks to all of you but I am not convinced with thsi fact.

So we dont have any way other way in SAP.This is really sad.

Can we create some authorization group which could put restriction to view spool file created by others?

Or any solution like that?

[Former Member]

Julius - You are right, I got mixed up with S_BDC_MONI hence the session name faux pas.

Sweety Gill - Moving most users to SMX and SP02 in place of SM37 and SP01 will do the majority of what you are wanting so you just need to ID a process to deal with what is left.

[Former Member]

Its quite impossible to move users to SMX and SP02 in place of SM37 and SP01.It will impact a lot of accesses in production.

I cannot take this process in our support project.

[Former Member]

Maybe I don't understand right

1. You want to remove the access from users seeing other batches and spools.

2. You want some people to see some other peoples batches and spools?

1. SAP delivers a solution for this

2. You need to find a creative solution to this (like another version of SM37 with a custom auth object).

Impossible is nothing but a lack of imagination and application.

[Former Member]

>

> But probably you meant S_SPO_ACT --> for spool one has to read the documentation (no way around it) and trace it to reach the check when a) your ID is different to the creator of the request and b) the request is created by a program (more reliable than humans...) which adds an explicit SPOAUTH value to it.
> Julius

I have used S_SPO_ACT to restrict users from viewing other user's batch jobs. The user's running the batch job needs to specity an authorization group on the spool request area. Only those users will have access to that auth group.

Good Luck.

[Former Member]

> I have used S_SPO_ACT to restrict users from viewing other user's batch jobs. The user's running the batch job needs to specity an authorization group on the spool request area. Only those users will have access to that auth group.

That means we have to get all the users who have access to SM37 and group them together?

[Former Member]

No, you need to find all users who did an ST01 trace on SM37 and still assigned S_BTCH_ADM and delete their user ID's in SU01...

Cheers,

Julius

[Former Member]

Hi Julius,

what is your response did you address the following statement?

"The user's running the batch job needs to specity an authorization group on the spool request area"

Delete them from SU01 ? can you explain ?

[Former Member]

It was a joke, not a very good one though.

Prior the rear of the checks in SM37 the system performs a batch admin check and sets a flag for this, which overrides other weaker authorization objects even although these failed.

Another possibility worth looking into is the config table behind SM37. --> btc_options. It does not have a value help (F4) but is a good search term on OSS. Actually, I remember an option about "normal" users there vs admins.

Anyway, deleting the spool in the running job is always safest (once checks for errors, etc, are complete).

For example: define a spool recipient distribution group and delete ot in the last step.

Cheers,

Julius

[Former Member]

I think if I restrict S_SPO_ACT and delete the value DISP in field SPOAUTH will work.

One cannot display others spool details in SM37 and SP01.

This object is unchecked always if user wants to take any action on his/her request.It is not weaker authorization.You canno display anyone else request without having it.

I am only worried if user needs to display other's request in few cases.

What do you sau guys?

[Former Member]

> I am only worried if user needs to display other's request in few cases.

Try it and you will find out...

In the FAQ sticky thread there is an OSS note link with explains how this works.

In large orgs with lots of granularity required it is a tough call... so avoid the spool as much as you can.

Also for remote stuff it is neanderthal technology to leave all data in the spooler... but in some local cases it has it's uses which are justifiable in my opinion if they are subsequently deleted.

Cheers,

Julius