@Kevin: D3 7.3.6NT (yes, old, sue me, client won't upgrade)

@Tony: Yes, I'd seen the source in dm,bp, but having code doesn't help
when it doesn't really document the control file structure (in this
case, BACKGROUNDS). For example, the meaning/purpose of the "STATUS"
attribute <24> is completely undocumented and opaque, even with the
code in hand.

@Dale - thanks! I changed 24 to "Q" and got three of the four jobs
fired off, and they seem to be set to run automatically each night
now. Thanks much.

But the fourth job is the problem. As soon as it gets hit by
(presumably) the scheduler, STATUS/<24> changes to "R" (what does this
mean??) and STARTABLE/<26> changes to "N" (job disabled). There is NO
output in BACKGROUNDS.OUTPUT and NO record in BACKGROUNDS.REPORT to
explain this - it just silently changes and never seems to start
again.

Is there any way to debug this? I can go to the account and run it
manually, just fine. It's just simple basic program that takes no
input. Ideas to debug it and find out why the background scheduler
hates it?

thanks all!

On 2010-05-27 22:15:36 -0400, Mike Preece <michael (AT) preece (DOT) net> said:

It's probably not right, but maybe you can be fixed.

--
Kevin Powick

On May 27, 9:50*pm, David Ruggiero <thatseattle... (AT) gmail (DOT) com> wrote:

The original code for the jobs phantom processor was available...
Donno if it still is.

Here is what I remember...

attr 24 = Q and 26 = T Means that the job is queued and timed to
start

When the background process finds a job that is past due to run, it
changes 24 to I (eye) (interactive) and I'm not sure if anything
happens to 26. Then the backgrounds processor 'Z'eds off the job and
starts the program BGRUN with a smack of parameters from the
Background item.

The BGRUN program changes <24> to 'R' (running) and 26 to 'N' (not
startable).

When the process has been completed, BGRUN re-queues the job for the
next time as defined by the parameters in the BACKGROUNDS control
item. (maybe the master background processor did this)

Take a look for the source code!!! It was included with D3/Linux 7.2

A few things can mess up the works

1. The job that you want to run on a periodic basis could log off the
port and therefore BGRUN cannot complete the re-queue process.

2. For some reason more than one master phantom process starts and
therefore you get multiple processes trying to launch processes.
Things get messed up in the lock table and lotsa stuff gets hung up.

What I did was I created a background process to monitor the
background jobs and report any problems via e-mail. I had an item
call 'backgrounds_that_must_run' that held the keys to the background
jobs (backups, email processor, etc.) that needed to keep running with
a Value-mark and the time allotted for the job to complete. (The same
sort of list that would be created by a SSELECT when using a sort by-
exp MV's are used.) Usually the email stated that all was okay, but
on occasion I would get notified that something got hung up, and a
small intervention got the job running again.

If I didn't get the email then either the background process master
program was hung, multiple master programs were running, or the email
processing program had multiple instances running. You do have to
consider the lack of a report as a problem.

On May 28, 2:25*pm, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
Fixed = Working

"...> The BGRUN program changes <24> to 'R' (running) and 26 to
'N' (not startable)."
"> 1. The job that you want to run on a periodic basis could log off
the port and therefore BGRUN cannot complete the re-queue process."

BINGO! Beverage of Dale's choice coming to him.

The procedure was chaining "OFF" at the end, so the BACKGROUNDs item
was still in a running state, perpetually.

Don't know why - and more to the point, don't know how it worked as a
phantom job successfully for many years.
But taking out the logoff fixed it ( = working .

thanks much, Dale.

--Pickteam

On May 30, 2:16*pm, David Ruggiero <thatseattle... (AT) gmail (DOT) com> wrote:

Hmmm.... It's going to get hot here soon...

A finely crafted wheat beer would quench the thirst nicely!

Glad I could help.

Dale