Let's say you have to run a job between 10. and 15. of a month just one time. In our situation we have to skip holidays and weekends - this is achieved with exceptions.

After the job is run on one of those days, there should be a possiblity to disable the trigger until next interval (10.-15.).

Let's say you have to run a job between 10. and 15. of a month just one time. In our situation we have to skip holidays and weekends - this is achieved with exceptions.

After the job is run on one of those days, there should be a possiblity to disable the trigger until next interval (10.-15.).

How are you starting your job between the 10th and 15th of the month? Some sort of Event Trigger, or do you just have a Time/Interval trigger configured to run once a day on specific days of the month and then have exceptions when Holidays/etc.. come up. So maybe this month the 13th is the first good day, next month might be the 10th?

Just asking in case there's a way to do what you're wanting already in an easy fashion. Not sure there is, but i want to fully understand the requirements before I try and answer.

NOTE: One way to do this is to check (enable) the 'Run once (can be reactivated later)' option on the main settings of the job. ANY time this job runs, it'll immediately be INACTIVATED when finished (red 😵. You could then have a 2nd job set to run on the 16th of every month that has a task to ACTIVATE that other monthly job. The Run Once option stays enabled. So if you have your job set to run the 10th, 11th, 12th......15th, this would satisfy the requirements. It would disable itself until the 16th when another job turns it back on so it can wait for next month.

Just a thought.

Brian
(unpaid VC supporter 😁 )

Hi,

you've understood the situation.

The job is started by a interval trigger (monthly; 15,16,17,18...) with exceptions.

It's not a big deal to workaround that with a second job or a file trigger but it's not fashionable.
This feature is something that we need very often, so I think it would be a great feature for the scheduler.

Regards,
Jasmin

How about a Variable condition, comparing {JOB(Active|LastRun|MM)} with {DATEFORMAT(MM)}?

How about a Variable condition, comparing {JOB(Active|LastRun|MM)} with {DATEFORMAT(MM)}?

Haha. I actually tried this on 6.2.1 and it didn't appear to work properly.

I had 5 rules, Date minus 1, Date Minus 2, etc.... and one specifically for what you said for 'today', so if it matches, Exit.

Maybe I did it wrong, but i was going to suggest that as well till it didn't work, so I didn't mention it.

Maybe something with the Active Job variable not being translated? I couldn't tell, as the Debug information didn't go into detail stating what the variable was being translated to in the condition.

EDIT: I should say... I had a condition set doing date math like mentioned, then I tried a single condition with what you suggested and I didn't have success. Again, i may have done it wrong, I don't use many conditions yet.

Brian

Well, I didn't test it, myself. I was just spinning by the forum and had a brainstorm. I'm not sure what would keep it from working, though. I'll play around with it later and see if I can figure out anything.

Well, I didn't test it, myself. I was just spinning by the forum and had a brainstorm. I'm not sure what would keep it from working, though. I'll play around with it later and see if I can figure out anything.

This is just a guess, but I'm wondering if when the job tries to run... it updates its Last Runtime IMMEDIATELY and then checks the condition before quitting... meaning the LastRun will always be 'now' if the condition is checking the active job?

Just a theory. That might explain my troubles trying this.

Hi thank you for your suggestions. I solved with a file-condition, which checks for a file state\<JOBID>_<MM.YYYY> on each run. If the file is present, the job exits.
The last task of the job is to create this file.

It's nice, because the condition is reusable and it's pretty clear what's going on.

Well, I didn't test it, myself. I was just spinning by the forum and had a brainstorm. I'm not sure what would keep it from working, though. I'll play around with it later and see if I can figure out anything.

This is just a guess, but I'm wondering if when the job tries to run... it updates its Last Runtime IMMEDIATELY and then checks the condition before quitting... meaning the LastRun will always be 'now' if the condition is checking the active job?

Just a theory. That might explain my troubles trying this.

...That would make sense, especially considering that I already know I can look at a running job or task's last run time to find out when it started and therefore how long it's been running...a fact of which I am making use over in my thread where I'm using Powershell to detect long-running tasks.

Fortunately, there is also {JOB(Active|LastExited|MM)}. I bet that would work, as long as you weren't running something when it might finish in the following month.

(...Or there's always the file condition solution.)