batch job

[Former Member]

All,

I read the Post of John Lewis regarding the batch job.I wonder even we can schedule the batch job using sa38 but if this is the case then we dont need to assign any roles to the system users like how we do for SM36??Basically system users are set for Batch job,RFC etc.With out the interference of the system user can we do batch job in SA38/SE38??

[Former Member]

Hi Kevin,

A batch job requires a user to run. You can schedule it to run under another ID or your own. Both need the relevant auths for the job to run.

Users often schedule batch jobs under their own ID. Their ID is expired and that batch job can't run any longer. Check for batch jobs being run by a user should be performed as part of the user expiry process.

[Former Member]

But If you try with SA38,there is no such option to enter the user:So I considered my self that, with out the system users ,batch jobs can be scheduled using SA38...

[Former Member]

in SA/SE38 you can schedule something to run in the background, use SM36 to use more extensive functions

do it in SA/SE38 & it will use your auths - if you don't have them the job will fail.

Edited by: Alex Ayers on Jan 31, 2008 7:33 PM

[Former Member]

I got you.So if you want to assign for your own ID(dialog user),go for SA38 but batch job will fail at the time of your ID expiration.Thats the reason sm36 is effective than the early(because of system user-no password expiration)??

Here the authorization for system user means to access sm36,se38? or for eg:pfcg_time_dependency is scheduled as batch job.At this point system user needs PFCG access??

[Former Member]

>

> I got you.So if you want to assign for your own ID(dialog user),go for SA38 but batch job will fail at the time of your ID expiration.Thats the reason sm36 is effective than the early(because of system user-no password expiration)??

>

> Here the authorization for system user means to access sm36,se38? or for eg:pfcg_time_dependency is scheduled as batch job.At this point system user needs PFCG access??

Hi Kevin,

If you want to schedule it with your own ID you can use SA/SE38 or SM36, but you are right that if your ID is locked or expired then the job will fail.

If you use SM36 then you can ensure that it is run by a user which is unlikely to be locked and also has plenty of authorisations to process the task. For PFUD/time dependency then the user will require the same auths that you would need. There are some very, very infrequent exceptions to this though.

[Former Member]

Thanks man

[Former Member]

Is there any way we can identify the tcodes based on the program name??Eg: can find program name for a tcode using se93 how about vice versa??

[jurjen_heeck]

try table tstc

Oh, SE93 also helps, explore the buttons on the search screen......

Edited by: Jurjen Heeck on Jan 31, 2008 10:20 PM

[Former Member]

Wondering is there any similar way for the reports?(Eg: pfcg_time_dependency)

[Former Member]

try table tstc

tx for user compare is PFUD

[jurjen_heeck]

Yep.

Tricky thing is that PFUD does not trigger PFCG_TIME_DEPENDENCY but RHAUTUPD_NEW.

That's why a search in TSTC or in SE93 will not return a tranaction for PFCG_TIME_DEPENDENCY

[Former Member]

OK, but there is no basic procedure to pull the tcode for the report..So only by common sense we need to find the corresponding tcode for the report?(like PFUD=pfcg_time_dependency)

Because for the programs sap* ,if you type in tstc,it works ,where as not for pfcg*

[Former Member]

I noticed that I while ago with RHAUTUPD_NEW nested inside PFCG_TIME_DEPENDENCY

Not sure why though?

[jurjen_heeck]

>

> OK, but there is no basic procedure to pull the tcode for the report..So only by common sense we need to find the corresponding tcode for the report?(like PFUD=pfcg_time_dependency)

>

> Because for the programs sap* ,if you type in tstc,it works ,where as not for pfcg*

Well, there is the basic procedure (search SE93 or table TSTC) but transaction PFUD does not start report PFCG_TIME_DEPENDENCY. They do the same but there's obviously no direct technical connection between the two other than that they (the transaction and the report) trigger the same program, so there's no use looking for that.

If there's a connection between a transaction and a report it is in table TSTC.

Edited by: Jurjen Heeck on Jan 31, 2008 11:13 PM

[Former Member]

The common practise for creating a system users is based on number of batch jobs to be scheduled?? or create just a single system user and assign it for any no: of batch jobs but for that single system users give SAP_ALL access??

The reason why I said SAP_ALL is ,we are not sure what type of access to give or what tcode to assign it to the system user for batch job(As TSTC is not pulling the corresponding tcode for the report)

[jurjen_heeck]

Kevin,

I'd start with SAP_ALL for the batch user(s). After all, production must go on, that's what the system was bought and installed for....

You could consider running traces along with the batch jobs to see the actional needs, but beware of mounthly and yearly jobs you might miss. Also most background jobs have an interactive counterpart, with a transaction. If you know that you can get an idea of auths and objects.

On the other hand, restricting the batchuser is (or should be) part of the overall authorization design so you might want to speak to the system and/process owner(s) to find out how important they think this is. Point out the risk from both sides, misuse v.s. crashing processes due to authorization errors.

Once again, there is no rule of thumb, unfortunately.

Jurjen

[Former Member]

>

> The reason why I said SAP_ALL is ,we are not sure what type of access to give or what tcode to assign it to the system user for batch job(As TSTC is not pulling the corresponding tcode for the report)

That on its own is no reason to give someone SAP_ALL

Try to either look at the object (in this case report) from SE80 and open the "object hierarchy view" (or something similar (an icon which looks like a hierarch of 3 blocks which are linked) and check the tcodes there, or do a where used-list search on it, and if not found (as transaction code) then search again further in the hit list.

If all else fails, rather create your own transaction code (see transaction SE93) than hand out SAP_ALL.

This is typically considered a safer way of presenting security for the end users...

Cheers,

Julius

[Former Member]

Hello Kevin,

Sorry, I neglected your original question after reading the threads which "evolved" from it.

One way of doing this (considering that the system user might not need any transaction code (S_TCODE) authority at all...)... is to create a symbolic transaction code for the role (with a name which is the same as the role name space conventions for system users...), via which the authorizations can be pulled into the role...

Just a thought,

Julius