I have a job in autosys and I need to update it to remove the starting time completely.
Currently the start time is set to run at 10pm every night.
update_job: myjobname
start_times:
Do I leave the start_times blank as above or do I change it to start_times: " "
Any help would be greatly appreciated.
Yes, you have to keep it as blank. However, along with this you have to remove the days_of_week or run_calendar as applicable:
update_job: myjobname
start_times:
days_of_week:
If you are looking to remove this from schedule, another way is to just update the boolean value of date_condition
update_job: myjobname
date_conditions: n
here "n" would mean not to follow the timings. It can be mentioned as 0 or 1. The user has to force start the job on need basis.
Related
I'm using "Red Programming Language" version "0.6.4" on Windows and making a command line application.
I don't know much Red language and I don't understand many things. I did go over "work in progress" docs at (https://doc.red-lang.org/en/) before asking here.
I need to see the "Something, something..." on the screen for a bit (let's say 1 second) before the command prompt window closes.
Red []
; do something
print "Something, something..."
; pause 1 // not working
; sleep 1 // not working
quit
As in the code comments I've tried with pause or sleep but I get an error Script Error: sleep has no value. How to make it sleep?
Thank you.
The function you are looking for is WAIT. Try wait 1.
Using WAIT as prescribed by #MarkI above is the correct answer.
But I wanted to add below which should really be a comment but it looks nicer formatted!
The best way to explore Red/Rebol is via the console and making use of HELP
>> help pause
No matching values were found in the global context.
This means there is nothing defined for PAUSE (and ditto for help sleep).
So instead quote the word and it will search through all defined function documentation...
>> help "sleep"
No matching values were found in the global context.
>> help "pause"
No matching values were found in the global context.
Still no luck :(
OK lets try something related...
>> help "time"
... long list found items...
This now returns all functions that have some connection to "time" in their function spec/docs. In this list is WAIT function. However another HELP clearly shows it...
>> help "duration"
wait native! Waits for a duration in seconds or specified time.
Now we have it...
>> help wait
USAGE:
WAIT value
DESCRIPTION:
Waits for a duration in seconds or specified time.
WAIT is a native! value.
ARGUMENTS:
value [number! time! block! none!]
REFINEMENTS:
/all => Returns all events in a block
Hope that helps.
I´m a newbie in Zabbix and I wanna to create a item which search a " problem " word in some log file. This item should search the file every 5 seconds and if there are some " problem " words, it´s trigger a problem.
I create a key with condition:
log[/var/log/test/test.log,problem]
After that, create a trigger:
{Log reader:log[/var/log/test/test.log,problem].strlen()}>0
I Create a fake .log file and fill it with some fake data:
asdasda
asdadad
problem
asadada
Everything works great, trigger works and show me a problem where last data was " problem ". After this a open the fake log again a write:
asdasda
asdadad
problem
asadada
problem 1
Save it, and zabbix shows me a 2 problems, both of these have last data " problem 1 ". When I write problem 3 to log, same again, 3 new reports all with " problem 3 " data.
This item should actaully read only latest data. I´m not 100 % sure if this is a real problem because every time when I edit .log file I re - save it so logically, item finds a 3 words, so it creates 3 reports. How will be this works if .log will be real and be filled with real data ? Does item read only news or it will works the same as I re - save whole file ?
Thanks a lot for your time :)
There's a dedicated page for log file monitoring in the documentation which is very useful, the "Important Notes" section covers most of the gotchas.
Your trigger is working as expected, for every "problem" added in your log you get an alarm, and your alarm stays forever.
You should define a time window for your trigger (i.e.: trigger in I've got at least one "problem" in 5 minutes) or a recovery expression to clear the trigger after a certain condition is met (i.e.: 5 minutes passed without "problem" or a "OK" string in your log).
According to the trigger functions documentation - strlen section, this should fire up one alert which stays up for 1 or more "problem" strings and clears out after 5 minutes:
{Log reader:log[/var/log/test/test.log,problem].strlen(,5m)}>0
I have some TODO's in my recur.org file which look like this:
** TODO Do this thing every day.
SCHEDULED: <2016-09-19 Mon .+1d>
For me, that . before the +1d means "if you happen to do this job late, then when you mark it as done it will re-schedule itself to the day after when it was marked as done." This is correct, because this job does have the property that if I don't do it for 4 days, then I don't need to do it 4 times to catch up, I just need to do it once. On the other hand, if I don't do it for 4 days then I really need to get this job done and I would hope that it gets flagged up in red when I look at my weekly agenda view with C-c a a in emacs org-mode.
Unfortunately, this does not happen. The standard agenda view lists this task as
[stuff in red here with Sched. 4x etc etc]
recur: Scheduled: TODO [#A] Do this thing every day
and the entry is in green with no indication that I'm late. This is presumably because the fact that it is scheduled every day means in particular that it is scheduled today, and so hang the fact that it's still also scheduled 4 days ago.
This is not the behaviour I want. I would like to be able to make a repeated TODO which, when done, resets the scheduled time to today+[interval], and yet I am still warned if I fail to do the task for a time period which exceeds the interval.
Experiments indicate that jobs with things like .+1w behave the same way -- they're 6 days overdue and then all of a sudden they're not overdue any more.
Could I write a custom agenda command somehow, to ensure these jobs are flagged when they are late?
Added 3rd Oct: Some further experimentation has revealed that the dot isn't the problem -- this is also the default behaviour with recurring TODOs that just are due to be rescheduled after a time delay shorter than the time it's taken me to fail to do them.
However I am now slightly more optimistic that this can somehow be solved with a custom agenda view. For C-c a L gives me a view where the recurring task shows up on the first day it's scheduled and not done, rather than the most recent day it's scheduled and not done. However C-c a L is no good for three reasons: (1) it shows tasks which are DONE (2) it shows priority C tasks which are late (and I am much less interested in these) and (3) it only acts on the current buffer. So if I learn enough about agenda views I feel like I might be able to answer my own question.
Added 9th Oct: Having now read the relevant pages of the org manual I realise that I still do not know how to do this. I am surprised. What I am asking for is an agenda view which encompasses all my org files, gives me a weekly agenda like C-c a a, and which flags the first not-yet-done occurrence of each repeating TODO task which has priority A. From a purely logic/programming point of view I don't see any obstruction to this, and I would be quite surprised if there were no way to do this in org-mode, but I certainly can't find it. Help!
If I check 'measure runs at every step' in Netlogo's Behaviorspace, in the output does Step 0 refer to the state of the simuation just before Go has been pressed? And then Step 1 would be as if Go had been pressed once, and so on?
What Seth said. But note that a "step" can be anything your want and is not linked to your Go button in any way.
https://ccl.northwestern.edu/netlogo/docs/behaviorspace.html :
"The run options dialog lets you select the formats you would like the
data from your experiment saved in. Data is collected for each run or
step, according to the setting of Measure runs at every step option.
In either case, the initial state of the system is recorded, after the
setup commands run but before the go commands run for the first time."
Yes, that's right. Step 0 is after the setup commands have run, but before the go commands have run.
on Windows 7, how do I trigger on first occurance of an event each day to run a small batch file?
I'm trying to kick off a small batch script that runs only for a few seconds when I unlock my PC, but I only want it to run the first time I unlock my PC and never again until the I unlock my PC after 12AM of the next day. I can't tigger on specific time because the time at which I unlock my PC is random. I have been playing with task scheduler for days without success.
You could have the script set a state on first run, which keeps it from running again, for example by exiting immediately instead of doing anything when the state is set.
Then set up a task that triggers on log on to execute said script and another task that runs each day at 12AM to unset/remove the state set by the script. This should give you the effect you want.
A better solution, would be to have the script deactivate (f.e. via schtasks) the task triggered by logging on that called it and have the 12AM task restart the logon triggered task once each day.
I just faced the same problem, so here is my workaround without knowing to much scripting:
I created 4 .bat-files containing basically the following.
start application, afterwards replace bat-file1 with bat-file2
do nothing
replace bat-file1 with bat-file4
start application, afterwards replace bat-file1 with bat-file2
Now I created to scheduled tasks:
The first one runs every day at 12am and runs batch-file 3. Hence, it replaces bat-file1 with bat-file4.
The second one runs after every unlocking of the computer and runs batch-file1.
As you can see in total it does exactly what you want, although it might be a little bit complicated...
On your first unlock it starts your desired script and replaces itself with a dummyfile (the batch file only contains the word exit). After every following unlocking nothing but a hardly noticable cmd popup happens.
At 12am the dummyfile is replaced by the initial batch-file again, to provide your task in the next morning.