Batches with 'S' status

Batches with \'S\' status

Hello everybody,
We are submitting different jobs to the server to many queues (i.e QB7334) and we have noticed that some goes to 'P' status and than to 'D', as expected, but some of them wait in 'S' status until the ones that are processing 'P' go to 'D'. The sum of 'P' and 'S' processess is iqual to the queue limit. Do you guys have any idea for what's happening that they don't go from 'S' to 'P' instantaneously? It's taking minutes to do so. Thanks a lot. (UNIX 11.i Oracle 9.2.0 SP 21 OneOff L1 ERP8)

RE: Batches with \'S\' status

Check your queue delay in your server jde.ini or in your runoneworld.sh
there are settings for each queue which has the time delay before it polls
the job master table. The other thing you will find is that even if you have
10 queues it doesn't mean you can always process 10 jobs simultaneously on
aix. How busy your server is can impact queue performance.

RE: Batches with \'S\' status

A client of mine had a similar situation with some frequently run jobs.

Using the SAW and reviewing the timing of logs we figured out that there was
an exclusive resource lock being placed on the spec files. The logs showed
that the jobs were waiting for specs, SAW showed us resource locks that
spanned the duration of a UBEs run. This was supposed to be changed in SP20.
Remarkably one or two ubes were able to prevent some other UBE's from
running.

Our solution was to run queuues for the problem jobs on NT application
servers. NT did not exhibit the same locking issue that our HP Unix system
had.

It could also be that you have a long wait time in the .ini.

Dave

David D. Helsley, Inc.
[email protected]
(317) 879-4483 (Client)
(814) 450-8073 (Cell)

Re: Batches with \'S\' status

A client of mine had a similar situation with some frequently run jobs.

Using the SAW and reviewing the timing of logs we figured out that there was an exclusive resource lock being placed on the spec files. The logs showed that the jobs were waiting for specs, SAW showed us resource locks that spanned the duration of a UBEs run. This was supposed to be changed in SP20. Remarkably one or two ubes were able to prevent some other UBE's from running.

Our solution was to run queuues for the problem jobs on NT application servers. NT did not exhibit the same locking issue that our HP Unix system had.

It could also be that you have a long wait time in the .ini. But, since you say they wait on 'P' to complete before going to 'P' it's probably a lock issue.