Job / Report execution time restrictions

[thomas_schmitt3]

Hi everyone,

is one of the following options possible ? If yes how ?

1) Set a restriction so that a certain user is only allowed to start reports or jobs at a specified time of day.

2) Set a restriction so that a certain job or report can only be started at a specified time of day.

Regards,

Thomas

[Former Member]

any specific reasons, why? what is the objective?

[thomas_schmitt3]

There are certain users who need to be able to run certain reports from time to time (no fix schedule).

Problem ist that no matter how often we tell them not to run those reports during daytime they won't listen to us and continue running those reports during daytime causing our system to crash because those reports lock important tables ...

[Former Member]

One way of doing it is by removing their own access to run these transactions or their reports in the mode which you are concerned about, and assign the authorizations for it to an emergency user.

In the application where they can request this emergency user, you can then configure and check the time of day or even system load if you want to, before permitting them to switch to the emergency user.

If you want to keep the original user ID name and only add the additional access temporarily on request between certain times, then you can use the reference user concept for this. What will be tricky is to work out how and when to remove the additional access again, but it can be done.

There is to my knowledge no standard way of doing this in the system.

Next best would be if you are certain that the report is not used anywhere else in any other mode, then you can hardcode a sy-uzeit check into it and raise a custom message which tells them to RTFM, or check the system load and raise a more polite warning...

Another way which could however be hobbled over by a semi-skilled person would be to lock and unlock the transaction code for the report and check the transactions status in the report before it is submitted. But that is all-or-nothing, and if the user finds your lock / unlock report then you will need to consider some things there as well to protect it from being run or the lock job from being stopped... Much too complicated.

Cheers,

Julius

[martin_voros]

Another solution is to remove authorizations to run these transactions and write a simple launcher which will launch the corresponding programs in allowed time intervals. I assume that each report has assigned transaction and users don't have access to SA38/SE38.

Cheers

[arpan_paik]

Problem ist that no matter how often we tell them not to run those reports during daytime they won't listen to us and continue running those reports during daytime causing our system to crash

Hard to work with people without discipline.

Straight away remove the access or write to their boss with log can be better

By the way emergency user concept already given is good....as control lies on your hand.

If still any of the above seems not working then show all these data to basis guys and tell then to increase system capacity. Bosses might start thinking to straight out their users once $ put breath on their neck.

Arpan

[Former Member]

A problem I see with such "launch pads" for report type transactions behind it is that a determined user would probably be able to break out of it - either by being encouraged to find the ways to get around the "launch pad" or by pestering you into giving them SA38 for "some" reasons or by pestering someone else with access to SUB%.

I would either do it regardless of where the report is being submitted from, or move their basic pay infotype record one space right each time they do it

The option of reconsidering the performance tuning of the system, or even checking sy-batch and class C (low priority) in the report are valid as well.

Enjoy the weekend,

Julius

[thomas_schmitt3]

Thanks a lot for the input so far !

However I doubt there's going to be much room for performance tuning because there's simply way too much data being processed and this is going to take time no matter how much effort you put into tuning the system.

[Former Member]

> Total Questions: 11 (8 unresolved)

Did you even read the other answers / options? Posts such as this most recent one is not going to attract helpfull answers either...

If you have such a massive performance problem with your reports and the amount of data they process that it cannot be solves by CPU, workprocessors and dedicated application servers, then you need to reconsider the performance aspects in the coding of the reports.

Just as a quick plausibility check, display the code of one of them in SE38 and then use the binoculars to search for the following string:

SELECT * FROM

... and let us know how many times it is found and which table(s) it is hitting?

Cheers and please follow up on your unresolved threads,

Julius