I migrated 24x7 Scheduler from V2.4.15 to V3.4.17.
Since the update jobs remain sometimes in the
queue although they have been executed successfully.

The semaphore files which are used to trigger the jobs
are the data file as well which have to be transferred
by FTP commands in JAL scripts. Each job has its own queue.

This are the last lines in one of the JAL script:
NOCONTENT:

LogAddMessage( "INFO", "24x7 EXPORT.DAT: EXPORT.DAT has no content")

FileDelete ( "C:\go\DAT\IE_DELV\EXPORT.CA1" )

Goto END
END:
LogAddMessage( "INFO", "24x7 EXPORT.DAT: Process finished")
Exit

Everything is logged correct in the Windows EventViewer,
the job transferred/deleted the file but the job is still
in the in the dedicated queue for this job and the status
is 'Running'. It is not possible to remove a job with status
'Running', the 24X7.EXE process must shutdown via TaskMananger.

Please set these jobs to run detached. If they run for less than 10 minutes set them to run synchronous. If you have many jobs, place them into separate job queues to allow concurent job runs.

: I migrated 24x7 Scheduler from V2.4.15 to V3.4.17.
: Since the update jobs remain sometimes in the
: queue although they have been executed successfully.

: The semaphore files which are used to trigger the jobs
: are the data file as well which have to be transferred
: by FTP commands in JAL scripts. Each job has its own queue.

: This are the last lines in one of the JAL script: NOCONTENT: LogAddMessage(
: "INFO", "24x7 EXPORT.DAT: EXPORT.DAT has no content")

: FileDelete ( "C:\go\DAT\IE_DELV\EXPORT.CA1" )

: Goto END
: END: LogAddMessage( "INFO", "24x7 EXPORT.DAT: Process
: finished")
: Exit

: Everything is logged correct in the Windows EventViewer,
: the job transferred/deleted the file but the job is still
: in the in the dedicated queue for this job and the status
: is 'Running'. It is not possible to remove a job with status
: 'Running', the 24X7.EXE process must shutdown via TaskMananger.

: Please set these jobs to run detached. If they run for less than 10 minutes
: set them to run synchronous. If you have many jobs, place them into
: separate job queues to allow concurent job runs.

Thanks for the hint. I set them up as detached already
but I specified them as 'asynchronous/background process' as well.
As the job execution takes just a minute I will put them to synchronous.
I will have a look if it works now.

: Thanks for the hint. I set them up as detached already
: but I specified them as 'asynchronous/background process' as well.
: As the job execution takes just a minute I will put them to synchronous.
: I will have a look if it works now.

--

I believe the problem may be a memory leak with 24x7.
I had similar problems until I configured the jobs to just
run all day and loop using a WAIT 120 and GOTO START commands.
The problem still happens every few days instead of several times/day because
I still have a few jobs the run once per day. Any chance of a program
update coming out soon that may fix the issue? Thanks.

Version 4 will change how script type jobs are run. Every job will run detached as a separate system process and the memory and other resources will not be shared between jobs. This way job resource (if any) leaks will not affect the scheduler and job queues.

In the current version I personally find that running detached synchronous jobs is always the best method. It never causes any job anomalies like job hanging in the queue after job completion.

: --

: I believe the problem may be a memory leak with 24x7.
: I had similar problems until I configured the jobs to just
: run all day and loop using a WAIT 120 and GOTO START commands.
: The problem still happens every few days instead of several times/day because
: I still have a few jobs the run once per day. Any chance of a program
: update coming out soon that may fix the issue? Thanks.

: Version 4 will change how script type jobs are run. Every job will run
: detached as a separate system process and the memory and other resources
: will not be shared between jobs. This way job resource (if any) leaks will
: not affect the scheduler and job queues.

: In the current version I personally find that running detached synchronous
: jobs is always the best method. It never causes any job anomalies like job
: hanging in the queue after job completion.
Hello,
We still have the problem that a job hangs in the queue although the JAL script
finished. I checked that by writing EventLog entries.

Is it somehow possible to clean the memory at the end of the JAL script?
When would be version 4 available?

Cheers Juerg

Please set your jobs to run synchronous. Put jobs for different applications into different job queues so that they don't affect each other. This will solve the "job hanging in job queue" problem.

I don't know release date for version 4. It's currently in final development stage.

: Hello,
: We still have the problem that a job hangs in the queue although the JAL
: script
: finished. I checked that by writing EventLog entries.

: Is it somehow possible to clean the memory at the end of the JAL script?
: When would be version 4 available?

: Cheers Juerg