Hoping I can get a little feedback on this. We’re running 24x7 as a service. It crashes from time to time. I’m looking through the logs right now to see if I can figure out what may be causing it. In the mean time I’m trying to set things up so we don’t get a support call every few nights.

I need to know if I can use the periodic restarts setting while in service mode?

Also, some of the time there are jobs that were running when the crash happened. When we get a call we run from the command line each missed job like this 24x7 /job 123. Usually this would be the one running when the service crashed and then anything else missed during the downtime.

In service mode, is there anyway we can set 24X7 to just run the jobs missed on its own when it restarts? I was looking at the Reset job queue on startup option but I wasn’t sure if this would help.

Thanks for any feedback you can provide. I appreciate it.

The rest job queue option controls whether to start previously queued jobs that haven't been executed before last restart. If a job is not queued at the time of restart it is not affected by the option.

Here is what you should do to ensure stable running
1. Disable job status display option if it is enabled (this is a must have)
2. Set all jobs to run detached and synchronous. Use multiple job queues to parallelize job streams. Normally 4 to 8 job queues is enough for any system.
3. Create a maintenance job that periodically archives job logs and the job database. If needed you can use this information later (perhaps load logs into a database) to #####yze job performance and anomalies and fix them.

: Hoping I can get a little feedback on this. We’re running 24x7 as a service.
: It crashes from time to time. I’m looking through the logs right now to
: see if I can figure out what may be causing it. In the mean time I’m
: trying to set things up so we don’t get a support call every few nights.

: I need to know if I can use the periodic restarts setting while in service
: mode?

: Also, some of the time there are jobs that were running when the crash
: happened. When we get a call we run from the command line each missed job
: like this 24x7 /job 123. Usually this would be the one running when the
: service crashed and then anything else missed during the downtime.

: In service mode, is there anyway we can set 24X7 to just run the jobs missed
: on its own when it restarts? I was looking at the Reset job queue on
: startup option but I wasn’t sure if this would help.

: Thanks for any feedback you can provide. I appreciate it.

: The rest job queue option controls whether to start previously queued jobs
: that haven't been executed before last restart. If a job is not queued at
: the time of restart it is not affected by the option.

Okay. Thanks for the info.

: Here is what you should do to ensure stable running
: 1. Disable job status display option if it is enabled (this is a must have)

I looked through all the jobs and they are all disabled.

: 2. Set all jobs to run detached and synchronous. Use multiple job queues to
: parallelize job streams. Normally 4 to 8 job queues is enough for any
: system.

All jobs (and there are a lot) are set to detached = no and asynchronous = no.

Is this likely to be the culprit? From the feedback I just got, it is unlikely I will be able to get them changed. Is there anything I can do that would help (like restart the service a couple times a day)?

: 3. Create a maintenance job that periodically archives job logs and the job
: database. If needed you can use this information later (perhaps load logs
: into a database) to #####yze job performance and anomalies and fix them.

I’ll look at getting this setup. Thanks for the idea.

Thanks again for the feedback. I really appreciate it.

Job status display is a global option. See Tools/Options menu; Log page.
: I looked through all the jobs and they are all disabled.

If you can restart the scheduler why cannot you set jobs to run detached? This will ensure that no job can crash the scheduler? If you have lots of jobs you may have hard time finding a no-run window to restart the scheduler. If you restart it during job runs these jobs might abort prematurely.

: All jobs (and there are a lot) are set to detached = no and asynchronous =
: no.

: Is this likely to be the culprit? From the feedback I just got, it is
: unlikely I will be able to get them changed. Is there anything I can do
: that would help (like restart the service a couple times a day)?

: I’ll look at getting this setup. Thanks for the idea.

: Thanks again for the feedback. I really appreciate it.

@ If you can restart the scheduler why cannot you set jobs to run detached?

What does setting the jobs to detached actually do?

The big obstacle would be our internal change control process. Touching all those jobs would be a big issue. They would all have to be retested due to the change control process. I doubt I could get an okay to change all of them.

If I had a definitive, "this is the issue", I might be able to get support to move forward.

@ If you restart it during job runs these jobs might abort prematurely.

We have an hour window each day where we'd be safe and that’s about it.

Thanks for the info any other ideas you might have.

Detached option causes each job to run as a separate process that doesn't share memory space with the scheduler and other jobs. So if a job crashes it doesn't bring the scheduler down. The only caveat, detached jobs of JAL script type cannot access global variables.

Because you have a no-processing window, I would go with a restart option as simple method to deal with this issue. If that doesn't help you can then start looking at other options such as detached jobs and so on...

: @ If you can restart the scheduler why cannot you set jobs to run detached?

: What does setting the jobs to detached actually do?

: The big obstacle would be our internal change control process. Touching all
: those jobs would be a big issue. They would all have to be retested due to
: the change control process. I doubt I could get an okay to change all of
: them.

: If I had a definitive, "this is the issue", I might be able to get
: support to move forward.

: @ If you restart it during job runs these jobs might abort prematurely.

: We have an hour window each day where we'd be safe and that’s about it.

: Thanks for the info any other ideas you might have.

Thanks for the feedback. I will setup a process to restart the service each night and see if that helps ease things up a bit. If not I will pursue getting the jobs modified to detached.

Thanks for all the help on this. I really appreciate it.

You are welcome

: Thanks for the feedback. I will setup a process to restart the service each
: night and see if that helps ease things up a bit. If not I will pursue
: getting the jobs modified to detached.

: Thanks for all the help on this. I really appreciate it.