What is the point of maximum runtime limit in foreground jobs?

[Former Member]

If the idea is to prevent the heavy workload on application server and make resources available for other processes then why it is possible to run the same job in background? As fas as I know, running a job in foreground or background doesn't effect how the resources are used, it is just different work processes (DIA as opposed to BGD). Then there should be a time limit for background jobs as well.

[Former Member]

I think you're missing an important point here: Controlling usage of resource does not mean that you have to apply the same measure everywhere...

From a technical perspective dialog and background processes are not the same. A dialog process usually serves multiple users (depending on the application you usually have longer inactive times, e.g. where user does data entry) with roll-out/roll-in, whereas a background process only handles one job at a time.

So dialog work processes provide resources for normal users and are subject to a maximum processing time to avoid having few users consuming all the resources (knowingly or unknowingly). Now in theory you could apply also some quotas to background processes, but in SAP this is realized via the authorization concept.

I.e. only users who are trusted to understand the impacts of running jobs in the system are allowed to schedule them. I haven't yet encountered a production system where user could freely schedule jobs. Often job scheduling is realized via some approval process, e.g. check out the nice blog from Martin Lauer about [job interception|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14715] [original link is broken] [original link is broken] [original link is broken];.

So I'd challenge your statement I can occupy same amount of resources with a background job, because you only can do that if your system administrators/security folks have chosen to trust you to do that...

Cheers, harald

[markus_doehr2]

> As fas as I know, running a job in foreground or background doesn't effect how the resources are used, it is just different work processes (DIA as opposed to BGD).

This is not completely true.

The memory allocation sequence for background workprocesses is is different to dialog processes:

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/49/325d57e93934ffe10000000a421937/frameset.htm

The reason for that is the fact, that there is no user context switching taking place in the background job as opposed to dialog processes that switch all the time. This enables you to configure specific memory ranges for background jobs that won't impact the data in the shared memory and so displacing data that is used in dialog processing.

Markus

[Former Member]

Dear Ahmat,

Assume you have don't have any time limit set for foreground jobs and you have 5 dialog work processes, now you have 7 users logged in and 5 of them are running their jobs in foreground and each job will take huge time to complete.

Now the remianing two user even though logged into the system, will not be able to do anything, since no dialog work process is free.

Now if a any other user wants to login into this system, he will not be able to do so since no dialog work processes are free, till any onedialog process gets free others users will not be able to login, there are many other reasons for why we have time limits on foreground jobs.

Regards,

Siv

[JPReyes]

As far as I know there is not time limit for a background process, it all depends on the code and the scope of the query.

For dialog processes you can use the rdisp/max_wprun_time parameter to set the time limit

Regards

Juan

[Former Member]

There is no time-limit for background jobs. But my question is different; if in terms of workload there is no difference between running a job in background or foreground then why there is not a limit for background jobs. I can occupy same amount of resources with a background job.

[Former Member]

The reason is that, if you want and need it, you can dedicate app servers only for batch jobs.

If these servers are overloaded it will have minimal consequences for the dedicated dialog app servers.

Remember also that jobs run on dedicated disp+work processes.

The dialog time out is to ensure that dialog processes stay available for interactive users.

Regards,

Olivier

[Former Member]

Because different background jobs will have different runtime. A simple example would be lets say on an average your system creates a weekly 5000 spool files and the job to delete these spool takes 10mins. For some reason 7000 spool files are created now this will take 15 mins and if there is a heavy system load when the job is running it might take 20 mins or more . So what limit will you define ?

There are many more examples which the people on the forum can give .One of the features of background process is to run programs without time limitation.

Hope this helps.

Thanks,

Naveed