RES: The 'S' status on the job queue

gerd_renz3

VIP Member
RES: The \'S\' status on the job queue

Justin,

could you please share with us exactly what fix you applied. Any SP, ESU,
SAR available?
I have been seeing this so many times but could never figure it out.

Great question, Sebastian!

Thanks, Gerd

-----Mensagem original-----
De: [email protected] [mailto:eek:[email protected]]Em
nome de JEMILLER
Enviada em: sexta-feira, 6 de julho de 2001 14:08
Para: [email protected]
Assunto: Re: The 'S' status on the job queue


Hi Sebastián,

The S or "In Queue" status means that a job has been noticed by a UBE kernel
process but has not yet been passed to a runbatch or runube process for
execution. The UBE kernels basically sit in a loop scanning the F986110
table looking for jobs in W status. When one of these kernels finds a job
and is ready to start it running is updates the record to S. Once the job
has started executing, the status moves to P.

Normally a job should not sit in S status for very long. There is a bug
that was in a recent Breaking News item where certain UBE's can lock a
servers spec files while they run. This will prevent other UBE's from
moving from S to P status. I have applied this fix to a few clients and it
seems to have cleared up the problem.

Regards,

Justin Miller




Justin Miller
[email protected]

working with B7332 and XE on AS/400, NT, Solaris and AIX
--------------------------
 
Re: RES: The \'S\' status on the job queue

Hi Gerd & Sebastián

The ESU for B7332 is JD4618 (SAR 3696736). The fix is apparently included in XE base. If you are on a previous release and have the problem you could probably modify the code yourself. It involves a single line change in one business function. (I did a WinDiff to identify the change.)

My current client runs 5 simultaneous threads across a couple of queues. Before this fix only about 2 ran together. Now I can get 5 simultaneous jobs all in P status. Note: I have followed the Server Administration guidelines when configuring the number of UBE Message kernels.

From the KG Breaking News OTI-01-0062

Issue
Although multiple UBE queues have been configured on the Enterprise server, jobs do not process simultaneously. Subsequent jobs still wait for a previous job to finish before they start to process.

Resolution
One possible explanation is that the job being processed is creating a lock of the TAM specification tables, thus preventing other jobs from processing. SAR #3696736 explains that Business Functions that use a combination of calls to jdeTAMInit( ) and TAMTerminate( ) can lock TAM files and create the situation described above. The SAR has produced an ESU for release B73.3.2 (JD4618) which fixes the function Get Company and Report Description. The function, contained in the F9800190 source module, is called in 53 different UBEs. Please note that the correction of this function is included in the XE release.

Hope this helps ...


Justin Miller
[email protected]

working with B7332 and XE on AS/400, NT, Solaris and AIX
 
Re: RES: The \'S\' status on the job queue

I'm running 5 queues. My QB7333 has 3 threads. Other 2 queues are for
payroll and other big UBEs like G/L post.

I can have 3 UBEs on P status at one time in my QB7333 queue.

Javid

NT4.0,SQL7.0 XEU2

----- Original Message -----
From: "JEMILLER" <[email protected]>
To: <[email protected]>
Sent: Friday, July 06, 2001 5:39 PM
Subject: Re: RES: The 'S' status on the job queue


in XE base. If you are on a previous release and have the problem you could
probably modify the code yourself. It involves a single line change in one
business function. (I did a WinDiff to identify the change.)
Before this fix only about 2 ran together. Now I can get 5 simultaneous
jobs all in P status. Note: I have followed the Server Administration
guidelines when configuring the number of UBE Message kernels.
server, jobs do not process simultaneously. Subsequent jobs still wait for a
previous job to finish before they start to process.
lock of the TAM specification tables, thus preventing other jobs from
processing. SAR #3696736 explains that Business Functions that use a
combination of calls to jdeTAMInit( ) and TAMTerminate( ) can lock TAM files
and create the situation described above. The SAR has produced an ESU for
release B73.3.2 (JD4618) which fixes the function Get Company and Report
Description. The function, contained in the F9800190 source module, is
called in 53 different UBEs. Please note that the correction of this
function is included in the XE release.
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=
15522
 
Back
Top