I am testing your 24x7 scheduler and I have setup a dependancy chain of five jobs which execute in order based on the existence of files created by one job and deleted by the next.

This works fine when I run it locally on the Master Server but it does not work if I attempt to run the jobs on a remote host. The problem appears to be that when you run the job on the remote host it create the semaphore file on the remote host but the other jobs in the chain are looking locally for the file.

Thank you for your help,

John

Thanks for your input.
We'll look at the issue in the next few days.

: I am testing your 24x7 scheduler and I have setup a dependancy chain of five
: jobs which execute in order based on the existence of files created by one
: job and deleted by the next.

: This works fine when I run it locally on the Master Server but it does not
: work if I attempt to run the jobs on a remote host. The problem appears to
: be that when you run the job on the remote host it create the semaphore
: file on the remote host but the other jobs in the chain are looking
: locally for the file.

: Thank you for your help,

: John

What version of 24x7 do you use?
In all latest versions, all semaphore files should be created localy on the Master.

: I am testing your 24x7 scheduler and I have setup a dependancy chain of five
: jobs which execute in order based on the existence of files created by one
: job and deleted by the next.

: This works fine when I run it locally on the Master Server but it does not
: work if I attempt to run the jobs on a remote host. The problem appears to
: be that when you run the job on the remote host it create the semaphore
: file on the remote host but the other jobs in the chain are looking
: locally for the file.

: Thank you for your help,

: John

The version of 24x7 scheduler is 2.3.2. Its the 30-day trial version since I'm testing to see if we are going to purchase this product. I did a workaround by creating a "MASTER" job and then programmatically calling the remote jobs using JobRemoteRun. This appears to work ok but it isn't as neat and clean as it should be.

Thank you for your efforts,

John

: What version of 24x7 do you use?
: In all latest versions, all semaphore files should be created localy on the
: Master.
I am using 2.3.2 and semaphore files get created on the machine the job runs on. If the job runs on the Master and creates d:\trigger.247, it is on the d:\ drive of the master. If the job runs on the Remote and creates d:\trigger2.247, it is created on the d:\ drive of the remote machine. Indeed they are created locally. Locally to where the job is running.

: I am using 2.3.2 and semaphore files get created on the machine the job runs
: on. If the job runs on the Master and creates d:\trigger.247, it is on the
: d:\ drive of the master. If the job runs on the Remote and creates
: d:\trigger2.247, it is created on the d:\ drive of the remote machine.
: Indeed they are created locally. Locally to where the job is running.

Thanks, Pat!
We'll check that and get back to you.

Please try the most recent version 2.3.5. I will also check it. If it doesn't work as described I will put a request for regresion bug fix.

: I am using 2.3.2 and semaphore files get created on the machine the job runs
: on. If the job runs on the Master and creates d:\trigger.247, it is on the
: d:\ drive of the master. If the job runs on the Remote and creates
: d:\trigger2.247, it is created on the d:\ drive of the remote machine.
: Indeed they are created locally. Locally to where the job is running.

I've upgraded to 2.3.5 and it still does the same thing. It creates the file local to the point of execution.

Another way I've worked around the problem is to have a "Link" job that calls another Job using JAL Job commands and when the "Link" job finishes it creats the file on the master server because it is running locally. Example:

Link1 --------- Run remote job
|------------ Create semaphore file

Link2 --------- Scan for semaphore file
|------------ When found run remote job
|------------ Create semaphore file

Etc, Etc.

It isn't a neat solution and the main problem with this is that you end up with TWICE the number of jobs because you need one local job for each remote job.

John

The way I've gotten around the problem isn't neat either. The jobs that run on the remote machine are batch files that ftp the semaphore file back to the Master when the job is complete.

One job per process, but extra coding and maintenance on the remote jobs. It also requires the Master to be an ftp server.

: I've upgraded to 2.3.5 and it still does the same thing. It creates the file
: local to the point of execution.

: Another way I've worked around the problem is to have a "Link" job
: that calls another Job using JAL Job commands and when the
: "Link" job finishes it creats the file on the master server
: because it is running locally. Example: Link1 --------- Run remote job
: |------------ Create semaphore file

: Link2 --------- Scan for semaphore file
: |------------ When found run remote job
: |------------ Create semaphore file

: Etc, Etc.

: It isn't a neat solution and the main problem with this is that you end up
: with TWICE the number of jobs because you need one local job for each
: remote job.

: John

This appears to be a regression bug. We will fix it in the next upgrade 2.3.6(should be available around end of the next week)

: I've upgraded to 2.3.5 and it still does the same thing. It creates the file
: local to the point of execution.

: Another way I've worked around the problem is to have a "Link" job
: that calls another Job using JAL Job commands and when the
: "Link" job finishes it creats the file on the master server
: because it is running locally. Example: Link1 --------- Run remote job
: |------------ Create semaphore file

: Link2 --------- Scan for semaphore file
: |------------ When found run remote job
: |------------ Create semaphore file

: Etc, Etc.

: It isn't a neat solution and the main problem with this is that you end up
: with TWICE the number of jobs because you need one local job for each
: remote job.

: John

In general this appears to work and fix the problem.

John