I wrote earlier but did not make myself clear.
How do you start an .exe at 6:00am
and stop the same .exe at 11:00pm?
It will run Mon thru Fri.
Thank you
Roddy

The best way is to make a "script type" job like
Dim( process_id, number )
RunAndWait( "myprogram.exe", "", 54000, process_id )

Using Job Wizard make this job "asyncronious" and then schedule this job to run "daily or weekly", check days Mon thru Fri, set start time to 6:00am. This is it. Note that 54000 = 15 hours * 60 minutes * 60 seconds.

: I wrote earlier but did not make myself clear.
: How do you start an .exe at 6:00am
: and stop the same .exe at 11:00pm?
: It will run Mon thru Fri.
: Thank you
: Roddy

: The best way is to make a "script type" job like
: Dim( process_id, number )
: RunAndWait( "myprogram.exe", "", 54000, process_id )

: Using Job Wizard make this job "asyncronious" and then schedule
: this job to run "daily or weekly", check days Mon thru Fri, set
: start time to 6:00am. This is it. Note that 54000 = 15 hours * 60 minutes
: * 60 seconds.

I thought that doing this would keep the job "active" for the period of time specified.

Since i'm having to script this anyway, i check for the end time range as well:

dim time_now, time
dim lResult, boolean

now(time_now)
IsBetween(time_now,0600,1800,lResult)
if(lResult,RUN_PROGRAM,SKIP_PROGRAM)

It would be better if the base program allowed you to establish the time range
during event scheduling. In many of our cases, we would then not require a script.

Suggestion: Since this is a scheduling product, it would be great if it were stronger in the scheduling area. Adding the above feature would really shore it up, IMHO.

Mark

It would keep the job active between 06:00,18:00. So what's wrong with this if it runs/sleeps in the background and doesn't take any significant recourses.

"Yes, it would be better if ....".
Sure, but it is simply impossible to implement all possible schedule scenarios, that's why 24x7 includes this powerful scripting options to allow virtually any schedule (time based, file based, process based, mix of them, any other cases...) No other package has such strong features.

By the way, we are working or numerous customizable templates that will help in implementing frequently used jobs and job schedules. These templates should be available in version 2.4 or may be even in 2.3 (end of this month.) Users will be able to create new jobs from scratch as now or from templates by answering a series of questions.

: I thought that doing this would keep the job "active" for the
: period of time specified.

: Since i'm having to script this anyway, i check for the end time range as
: well: dim time_now, time
: dim lResult, boolean

: now(time_now)
: IsBetween(time_now,0600,1800,lResult)
: if(lResult,RUN_PROGRAM,SKIP_PROGRAM)

: It would be better if the base program allowed you to establish the time
: range
: during event scheduling. In many of our cases, we would then not require a
: script.

: Suggestion: Since this is a scheduling product, it would be great if it were
: stronger in the scheduling area. Adding the above feature would really
: shore it up, IMHO.

: Mark

Hmmm. Perhaps i don't understand what it means when a job runs/sleeps in the background. I thought this meant that the application that is called would never close (the scheduler would not consider the job complete).

We have many tasks that run periodically and go away. During non-business hours, there's no need for them to run (and in fact this may cause problems), hence a time "range" wherein the job execution schedule in enabled.

I think this is a common scenario, enough so to justify adding it to the 24x7 U/I.

Granted, this baby is powerful. I am very impressed!

Mark Richards

: It would keep the job active between 06:00,18:00. So what's wrong with this
: if it runs/sleeps in the background and doesn't take any significant
: recourses.

: "Yes, it would be better if ....".
: Sure, but it is simply impossible to implement all possible schedule
: scenarios, that's why 24x7 includes this powerful scripting options to
: allow virtually any schedule (time based, file based, process based, mix
: of them, any other cases...) No other package has such strong features.

: By the way, we are working or numerous customizable templates that will help
: in implementing frequently used jobs and job schedules. These templates
: should be available in version 2.4 or may be even in 2.3 (end of this
: month.) Users will be able to create new jobs from scratch as now or from
: templates by answering a series of questions.

The original question was how to stop a program after some time assuming that the called program does not exit itself. The RunAndWait statement starts the program and puts the job instance in a sleep mode. That job instance wakes up either when the called program exits or after the specified timeout occurs, whatever happens first.

It seems to me that you are talking about something else, something that may be you want to start every n minutes but only between 06:00 and 18:00. Consider creating a single job that runs between 06:00 and 18:00 as you did it before then add a loop to start the desired program every n minutes, like the following fragment

LoopWhile work_time, END_LOOP

Run "myprogram.exe", "", process_id

// wait 10 minutes before restarting "myprogram.exe"

Wait 600

// ... recalc work_time time
END_LOOP:

: It would keep the job active between 06:00,18:00. So what's wrong with this
: if it runs/sleeps in the background and doesn't take any significant
: recourses.

: "Yes, it would be better if ....".
: Sure, but it is simply impossible to implement all possible schedule
: scenarios, that's why 24x7 includes this powerful scripting options to
: allow virtually any schedule (time based, file based, process based, mix
: of them, any other cases...) No other package has such strong features.

: By the way, we are working or numerous customizable templates that will help
: in implementing frequently used jobs and job schedules. These templates
: should be available in version 2.4 or may be even in 2.3 (end of this
: month.) Users will be able to create new jobs from scratch as now or from
: templates by answering a series of questions.