Hi,

It would be nice to run a job with some parameters (like the command execute arguments) done by the 'run job' task.
These job parameters could be accessed by a new job variable.

A way of doing it now is making a user variable for this, but this addition makes it easier. No user variable needed and a few tasks less in Visualcron.

Regards,
Erik

(I thought I had this posted some time agoo, but could not find it anymore..)

---

This is interesting, Erik.
What kind of functionality would this variable processing allow?
Any examples?

Hi trevinom,

What I'm thinking is that you have a variable in the activejob environment which you can fill with the job run task.
You could have a generic job and based on the passed parameter it does other things.

I know you can do this with the use of a UserVariable, but this is easier and dismisses the creation of a UserVariable and setting the variable with a task.

So I'm giving no examples, because it is just a new variable.

Regards,
Erik

---

I think I"m not using User Variables as elegantly as you. The only way I'm using them, currently, is to hold information that gets passed between tasks in a job. I'm going to have to take it up a notch to get to your level.

here is our use case:
we have a job that triggers on a file, processes the file and then archives it. we wanted to separate the archive task to its own job (to make it generic and reusable). our problem: there is no easy way to pass the full path of the file from the trigger to the second job. we would like to be able to easily trigger the next job and pass it params.

here is our use case:
we have a job that triggers on a file, processes the file and then archives it. we wanted to separate the archive task to its own job (to make it generic and reusable). our problem: there is no easy way to pass the full path of the file from the trigger to the second job. we would like to be able to easily trigger the next job and pass it params.

If you were able to choose how this was made - what do you suggest? Keep in mind that during a Job there are thousands of values changing and you want a specific value from the Trigger. You need some way to either pass a value from first (then retrieve value) or just retrieve a value that is already there. How would you suggest this is done if you just look at the current interface?

---

How this should look could be done like this:

Method 1
In the job variables there should be a extra variable called JobParameters
With the set variable task you can set this variable for a specific job to whatever you want.
When the job runs, this variable is accessible to every task in the job, just like a normal variable.

Method 2
In every screen where you can run a job, there should be a text field to fill in the sending parameters.
These parameters are stored in the job varaible JobParameters and are accessible for every task in the job, just like a normal variable.

I think the Method 1 is earier to implement.

There might be a method 3 though...

Regards,
Erik

---

I don't see how this is any different from using normal variables.
Once you create a variable, its accessible to all jobs. If a job gets done processing a file, you can set a variable to something which your archive job can use as a trigger, if you don't want to process it immediately, you can set the first task of the archive job to wait a given time. If you have multiple jobs running, then you might have to create a unique identifier for the job and pass it as a parameter, but you can still employ user variables.

How this should look could be done like this:

Method 1
In the job variables there should be a extra variable called JobParameters
With the set variable task you can set this variable for a specific job to whatever you want.
When the job runs, this variable is accessible to every task in the job, just like a normal variable.

Method 2
In every screen where you can run a job, there should be a text field to fill in the sending parameters.
These parameters are stored in the job varaible JobParameters and are accessible for every task in the job, just like a normal variable.

I think the Method 1 is earier to implement.

There might be a method 3 though...

Regards,
Erik

So, basically, method 1 and 2 could be combined. The text field is just showing the current Variable but it can be set from anywhere with a fixed function.

---

I don't see how this is any different from using normal variables.
Once you create a variable, its accessible to all jobs. If a job gets done processing a file, you can set a variable to something which your archive job can use as a trigger, if you don't want to process it immediately, you can set the first task of the archive job to wait a given time. If you have multiple jobs running, then you might have to create a unique identifier for the job and pass it as a parameter, but you can still employ user variables.

Yes, the problem is the lifetime of Variable. If you want a global Variable you can set it anytime and use it anytime.

But in this case we want a Variable connected to a Job.

If this is connected to a specific Job it does not matter if multiple Jobs are running if it is not multiple instances of the same Job. If it is I guess the "Put job in queue" will separate each instance - the same way result variables are set.

So, basically, this will be exactly like a user Variable. It is accessible from anywhere. You will, some way, be able to set it from the Set Variable Task. Only differencies are:

1. this Variable is unique for the Job
2. you will be able to read (and set) the Variable in the main settings of the Job

---

I see now. So this variable exists in a specific format for a particular job.
Any other job can reference it and point to a unique identifier for that job's run.
It makes perfect sense now. This variable can be used to daisy chain jobs and create instances of a 'job' composed of jobs, i.e. a schedule, like a nightly run of jobs that execute based on the completion of previous jobs.

I LOVE IT.

I see now. So this variable exists in a specific format for a particular job.
Any other job can reference it and point to a unique identifier for that job's run.
It makes perfect sense now. This variable can be used to daisy chain jobs and create instances of a 'job' composed of jobs, i.e. a schedule, like a nightly run of jobs that execute based on the completion of previous jobs.

I LOVE IT.

I don't think a unique identifier for a specific Jobs run is a good idea as this is pretty much behind the scenes (the unique Job run id). I think one instance is enough and that is the Job instance.

So, just as you can access the Name property of a Job you will be able to access Parameter property. You will be able to set parameter in Set Variable Task and in Job itself (along with Name and the rest).

The only thing you need to keep track of is that if you have unchecked "Do not run Job if it is already running" things might get messy as you may set the value somewhere, then it is set somewhere else, then you read the value. The first value is now overwritten. To be clear - there can only be one Name and in this case Parameter for a Job at a time. Hopefully it will be enough and easiest way to handle this.

---

Yes I agree,

There can be only one parameter variable for a job. Setting it will overwrite the current value, and in a looping job, there still is this one parameter variable.

Instead of using this parameter variable as a bucket for passing something to an other job, every job has it's own temp variable. So it reduces the need of creating a custom variable in several cases. The custom variales are more global in this case, not totally if you need more than one though..

Regards,
Erik

---

In the latest beta 6.1.9 you have something called Job Variables. They can be set at Job level and in the Job/Task control Task.

http://www.visualcron.co....aspx?g=posts&t=2948 

---