Background Queues

[Chris Kelleher]

Trying to use the background queues to do some overnight processing and
having a little problem with stability. Even though the queues show that
they are active they always do not start processing.
The procedure is shutdown the databases and queues, make copies of
databases, startup backup the databases and queues and then start the
overnight processing. 50/50 chance for the overnight stuff will process.
There have been times where it has taken 8-10 attempts of stopping and then
starting the queues before the will start processing.

 

[Chris Kelleher]

Do you have some sleeps built in to your script to give queues enough time to end before shutting down the databases?

Heide Sims
Small Parts, Inc. / MPI

 

[Chris Kelleher]

Hi all: We are running Syteline 3.5b02a and looking into implementing the
Syteline background queues as a potential way to speed-up our weekly MRP
runs.

We are running on a Unix DB server & use Citrix to run our client code.

Questions: 1. What code does a background queue running on Unix use? I
have heard something about the "tty" directory, but I am getting conflicting
answers from Symix support on this. Will the queue use the Unix code, the
Citrix code, or the Unix "tty" code?

2. Have you guys/gals found the background queues to be reliable? (I am
already aware of the need to shutdown the queue before shutting down the DB
servers)

3. Have you found any performance gains by running jobs in the background
queue?

4. I was running a job in the background queue status "R" and then got a
"file system full" message and the queue died. There were no file systems
on the Unix server full at the time, unless a temporary file was being
created that filled the file system up and then was removed. Can anyone
shed some light on this? What temporary files do the Background queue use?

Any suggestions would be greatly appreciated.

Trudy tmoghadd@mcicoach.com

 

[Chris Kelleher]

> Questions: 1. What code does a background queue running on Unix use? I
> have heard something about the "tty" directory, but I am getting
> conflicting
> answers from Symix support on this. Will the queue use the Unix code, the
> Citrix code, or the Unix "tty" code?
[Pat say's] If you are running the background queue on
Unix, it should be using the tty code, on NT it will run
the standard windows code. Having said that, in many situations,
I have found it possible to run the Windows code on Unix,
simply because of Progress R-Code compatibility. I would
have expected an error about incompatible displays, but I
didn't receive it,

> 4. I was running a job in the background queue status "R" and then got a
> "file system full" message and the queue died. There were no file systems
> on the Unix server full at the time, unless a temporary file was being
> created that filled the file system up and then was removed. Can anyone
> shed some light on this? What temporary files do the Background queue
> use?
[Pat say's] If you are running on Unix, and you
have not started the session with the -t option, then
your temporary files will be created without an entry
into a directory, so you would not actually be able
to see the files. Try adding this parameter to your
session parameter. The files that it could be referring
to are your srt file (where obviously sorting occurs, but
also where r-code is stored after it is read), lbi, local
before image, stores work table, undo variable, and sub-transaction
statuses - sort of like the bi, or DBI files, which are temp
tables. Another file that goes here is the trp, schema trap,
but only during dictionary updates.

 

[Chris Kelleher]

For some reason I missed the original, but here is my 2 cents

The background queues ( we run them in UNIX HP 11.0 ), in our experience,
have a expected life time of a about 2 weeks before they "mysteriously" stop
working. As far as MRP stuff we get a lot of hung up mrp-gen runs. Most of
the time it comes from a Citrix session that crashed and left a user
"holding" an item that the mrp-gen wants.

We run joblow, itemlow, itemlead, mrp-gen, rebal-jo, rebal-co, rebal-ir,
rebal-po in various cycles every night. Would be happy to discuss off-line
if you wish.

The biggest problem we have seen is that "sometimes" the jobs run out of
order like job #3 starts before job #2 and while job #1 is still
running..... but for the most part it works okay.