what process starts a background job

[Former Member]

I have a situation where a background job scheduled to repeat every 5 minutes shows a delay time of 3 hours (in stead of starting at 1am, it started at 4am). Between 1am and 4am, there were empty BTC processes (according to RSBATCH). So it wasn't a case where there were no batch processes available.

I haven't found a way to see how busy the DIA processes were during the same time slice. But I am thinking that maybe something was "delayed" between 1 and 4am.

What process actually starts the background job? Does the system need to have an empty DIA process to process the starting of a background job?

Or does the system use dispatcher process to start a background job? Does dispatcher ever get 100% busy with things such that it cannot start a background job?

Or are the some other processes involved?

Thanks for the help folks

[rupali_karbhari3 · Accepted solution]

Hi Martin,

You need to understand cause of getting Background job delayed for hours.

As you mentioned , this is periodic job with frequency of 5 minutes. It might be reason when eariler instances are incomplete and BTC triggered current batch job copy. Hence there seems to be ovelapping of jobs running concurrently causing delays.

Pls run the background job once and check complesion time. If it is more than 5 minutes , you should chnage period of frequency.

Also check if you have sufficient dialog and Background workprocesses available all the time.

Best Regards,

[Former Member · Accepted solution]

Thanks Rupali

you mention "Also check if you have sufficient dialog and Background workprocesses available all the time."

BTC process = yes they were free

DIA process - I cant figure out how to see how many of the DIA processes were actively used during the 3 hour period. This happened few days ago. And also few days prior to that as well (and causing business disruptions)

Also, why do you mention "sufficient dialog" process? I also suspect that maybe all the DIA were being used during that time period between 1 and 4am. But I havent found any SAP doc or note that links DIA availability to ability of ABAP stack to kickoff a batch job.

[rupali_karbhari3 · Accepted solution]

Hi Martin,

Pls go through SAP Note:

Note 165084 - Why does my job not start?

there are various reasons mentioned about background job getting delayed, one of them:

c) There are insufficient dialog processes for the scheduler.

Time-controlled or event-controlled schedulers require a free dialog process. If an instance is occupied by several RFC calls, for example, the scheduler cannot start. You can use transaction SM61 to check when the time-controlled or event-controlled scheduler last ran.

Best Regards,

[Former Member · Accepted solution]

Ahhh thanks

That's perfect - and most likely reason why there was a delay. And gives me a logical step forward (with reasonable chance of preventing repeat error, I hope).

Is there a way to display back several days to see the activity level of dialog procs? If I can get a log or a trx to show me that all DIA were used during the time in question, that would confirm this.

[rupali_karbhari3 · Accepted solution]

Hi Martin,

How many days back logs you would like to check?

I think SM21,ST22 woulnt help you to trace long back.

From OS level , under /udr/sap/<SID>/DVEBMGS00/work directory , check for dev_w<number>.old file.

This might give you information of perticuler dialog workprocess on perticuler day.

Best Regards,

[Former Member · Accepted solution]

Hi Rupali

yes - dev trace files would contain that info. I did review some of the files, but there are over 40 trace files to look at, and I was trying to avoid that work.

Besides, I am reasonably comfortable with "no free DIA" theory. What I am now looking for is a easy-to-digest proof that I can give to management (the issue has annoyed business hard, and management wants answers).

SM21 and ST22 doesnt give any definitive info on this.

I was sort of looking for dialog process version of RSBATCH transaction. RSBATCH shows by time slices how many batch jobs were processed by each of the batch processes.

[Former Member · Accepted solution]

In addition to what has been pointed out so far, there is one more possible reason to consider.

How many batch work processes have been reserved for class A jobs?

For a start:

http://help.sap.com/erp2005_ehp_04/helpdata/EN/c4/3a7f53505211d189550000e829fbbd/frameset.htm

regards

[rupali_karbhari3 · Accepted solution]

Hi Martin,

I suggest you to verify with ABAPer once , before concluding. It might happen that batch job program is waiting for some input and hence getting delayed.

Since you are unsure that all Dialog processes were full or not.

Anyways , on above topic abut supporting Dialog work process consumption , you can look for data available per day wise in Tcode ST03.

look for wokload analysis overview of Dlaiog "Wait Time" etc to indicate heavy ulilization of dialig process on that perticuler day.

Regards,

[Former Member · Accepted solution]

Thanks Joe

A reserve was looked at. That was not an issue

[Former Member · Accepted solution]

Hi Rupali

ST03 logs dont go that far back. And besides, wait time is a clue but not a "proof" Either way, I think there's enough info to go forward. I'm marking this as solved.

Thanks all

[vincentlim826]

Hi,

Of course you need to have available BTC to run background job.

yes, Dispatcher assign the tasks to BTC wp.

Below SAP Notes are helpful and will answer your queries.

16201 Background program, timeout, SAPMSSY6

24092 Distribution of background jobs on application Server

Regards,

Vincent

[Former Member]

Thanks Vicent

I had a read of both of the notes. While 16201 has some interesting info, I am still unable to figure out why the background job was held up for 3 hours. There were half dozen jobs that were held up for about 3 hours - all of which started at the same time.

This led me to think that something was blocking the start of the jobs.

Obvious point would be lack of available batch process, but as mentioned, there were available batch processes

If dispatcher is used to kick off the batch jobs, is there any scenario where dispatcher would be unable to kick off the batch jobs?

Does the batch job table (is it in memory or in DB during runtime - SAP_BASIS is 700) ever get "stuck" or otherwise become unusable for any length of time (like 3 hours)?

Again, thanks for the help