Informix job scheduler issues
A user on IDS 11.50.FC5 (HP-UX) added a row to sysadmin:ph_task to run a UDR hourly, but the task never did real work (sub-second run_duration), skipped its start time, then produced bursts of dozens of extra runs near midnight. Replies explained that the first run waits one full frequency interval, that EXECTASK takes the task name/id (not the function), and that onstat -g dbc shows task errors. The key cause was that the target database was unlogged — the 11.50 scheduler requires logging (fixed in 11.70). After switching to a logged database and resetting tk_next_execution, the task ran properly; John Miller advised setting both start and stop times to NULL with frequency 1 hour for true hourly runs. The odd clusters of extra runs near midnight were still unexplained when the thread ends.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
IDS 11.50.fc5
HP-UX 11.31 (11i V3) PA-RISC
I have created a function that I would like to execute on an hourly basis. I
created an entry in sysadmin:ph_task:
insert into ph_task
( tk_id
, tk_name
, tk_description
, tk_type
, tk_dbs
, tk_execute
, tk_delete
, tk_start_time
, tk_stop_time
, tk_frequency
, tk_group
, tk_enable
, tk_priority
)
values
( 0
, "my_test_function"
, "description for my_test_function"
, "TASK"
, "dev_db_2"
, "fn_my_test(3)"
, "10 00:00:00"
, "19:15:00"
, null
, "0 01:00:00"
, "INDEXES"
, "T"
, 0
)
;
I did this at approx. 19:05:00 and waited to see what would happen. The
designated time came and went with no activity, so I did 'exec function
task("scheduler shutdown")' and 'exec function task ("scheduler start")'.
After that point, the ph_task table showed tk_next_execution of 20:01:00. I
again waited until the designated time. This time, it seemed that the task
ran, as the tk_sequence incremented from 0 to 1, and there was a row in ph_run.
However, the run_duration was only 0.011209212, way too short for this job to
have run.
Further, the hourly schedule seems suspect. After the run at 20:01:00, the
next run was at 21:01:00 (so far, so good), followed by 22:01:00, then
23:01:03. That's where it gets really weird. Immediately after the run at
23:01:03 was a second run, at the same time, followed by 99 runs, the first of
which occurred at 23:15:02, the last at 23:15:04.
There are no runs after 23:15:04, even though there is no tk_stop_time.
Why did it not run the first time (19:15:00)?
Why, after stopping/starting the scheduler, did the next run get scheduled for
20:01:00 instead of 20:15:00?
Why did I get 99 runs at 23:15?
Why did none of the runs actually do any work? This may be something I need to
test on my side, but the function executes successfully when I run it in the
test database when running as user "informix". My understanding is that the
tasks run by the scheduler run as "informix", and that the scheduler changes
to that database prior to executing the task, so it should be the same as my
testing within the database.
When you set it to run at 1H interval, it will wait that interval to run
the first time. So it would have run at around 20:05H.
I don't have a good explanation to the other questions (specially the 99
runs - did you verified this on ph_run?).
As for why it didn't run... Your database dev_db_2 has logging?
Where did you create your function?
What is the function signature?
For he scheduling issue I believe that version has a problem that leads to
a bad calculation of the stop time (it affected AUS) but it doesn't seem to
match your scenario...
But I'd suggest you solve the reason why it doesn't run and then try to
check the scheduling.
You can run the task manually using:
DATABASE sysadmin;
EXECUTE FUNCTION EXECTASK("my_test_function");
Regards.
On Tue, Jan 24, 2012 at 6:25 PM, MARK COLLINS <markc@myfastmail.com> wrote:
> IDS 11.50.fc5
> HP-UX 11.31 (11i V3) PA-RISC
>
> I have created a function that I would like to execute on an hourly basis.
> I
> created an entry in sysadmin:ph_task:
>
> insert into ph_task>
> ( tk_id
>
> , tk_name
>
> , tk_description
>
> , tk_type
>
> , tk_dbs
>
> , tk_execute
>
> , tk_delete
>
> , tk_start_time
>
> , tk_stop_time
>
> , tk_frequency
>
> , tk_group
>
> , tk_enable
>
> , tk_priority
>
> )
> values
>
> ( 0
>
> , "my_test_function"
>
> , "description for my_test_function"
>
> , "TASK"
>
> , "dev_db_2"
>
> , "fn_my_test(3)"
>
> , "10 00:00:00"
>
> , "19:15:00"
>
> , null
>
> , "0 01:00:00"
>
> , "INDEXES"
>
> , "T"
>
> , 0
>
> )
> ;
>
> I did this at approx. 19:05:00 and waited to see what would happen. The
> designated time came and went with no activity, so I did 'exec function
> task("scheduler shutdown")' and 'exec function task ("scheduler start")'.
> After that point, the ph_task table showed tk_next_execution of 20:01:00. I
> again waited until the designated time. This time, it seemed that the task
> ran, as the tk_sequence incremented from 0 to 1, and there was a row in
> ph_run.
>
> However, the run_duration was only 0.011209212, way too short for this job
> to
> have run.
>
> Further, the hourly schedule seems suspect. After the run at 20:01:00, the
> next run was at 21:01:00 (so far, so good), followed by 22:01:00, then
> 23:01:03. That's where it gets really weird. Immediately after the run at
> 23:01:03 was a second run, at the same time, followed by 99 runs, the
> first of
> which occurred at 23:15:02, the last at 23:15:04.
>
> There are no runs after 23:15:04, even though there is no tk_stop_time.
>
> Why did it not run the first time (19:15:00)?
>
> Why, after stopping/starting the scheduler, did the next run get scheduled
> for
> 20:01:00 instead of 20:15:00?
>
> Why did I get 99 runs at 23:15?
>
> Why did none of the runs actually do any work? This may be something I
> need to
> test on my side, but the function executes successfully when I run it in
> the
> test database when running as user "informix". My understanding is that the
> tasks run by the scheduler run as "informix", and that the scheduler
> changes
> to that database prior to executing the task, so it should be the same as
> my
> testing within the database.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--00248c7691363074f704b74a8842
Thanks for the response.
OK, that almost makes sense about the first run. I would have thought that
since I created the ph_task entry prior to the scheduled start time, that it
would use the specified start time to determine when to try the first run. The
way you describe it, if I want something to run at daily 6:00 PM starting
today, I would have had to create the ph_task entry yesterday?
I did confirm the run times and number of runs for the original posting by
querying ph_run.
You may be onto something about the logging. No, dev_db_2 is not logged.
Sadly, many of our databases are not logged (it's on our to-do list).
However, your idea of testing it by running EXECTASK seems to indicate that
this is not a problem. I executed the following:
database sysadmin;
execute function exectask("dev_db_2:my_test_function(3)");
and it appears to be running correctly (the function takes several minutes to
run, and it is taking time now. Last night, the ph_run indicated that it was
ending in less than a second.) Also, I am able to run the function manually
'execute function my_test_function(3)' successfully when I am logged in to
dev_db_2. I mention this because I am not certain whether the scheduler runs
the task from sysadmin, or if it instead connects to dev_db_2 prior to
attempting to execute the function.
The function is defined in dev_db_2. The signature is
my_test_function(smallint) returning integer.
Can you give me more details, or tell me where to find more details, about the
problem calculating stop time (the problem affecting AUS) in this version?
Also, where is EXECTASK documented? I did a search in the online docs and came
up with no matches.
>> When you set it to run at 1H interval, it will wait that interval to run
>> the first time. So it would have run at around 20:05H.
>> I don't have a good explanation to the other questions (specially the 99
>> runs - did you verified this on ph_run?).
>>
>> As for why it didn't run... Your database dev_db_2 has logging?
>> Where did you create your function?
>> What is the function signature?
>>
>> For he scheduling issue I believe that version has a problem that leads to
>> a bad calculation of the stop time (it affected AUS) but it doesn't seem to
>> match your scenario...
>> But I'd suggest you solve the reason why it doesn't run and then try to
>> check the scheduling.
>>
>> You can run the task manually using:
>>
>> DATABASE sysadmin;
>> EXECUTE FUNCTION EXECTASK("my_test_function");
Regards.
I have tried to use the scheduler and after opening a case found that it
requires the database to be logged. I was told they were look at fixing it so
it would work with logged on non-logged databases.
Bruce Simms
Data Base Services
TALX, Provider of Equifax Workforce Solutions
2330 Ball Drive
St. Louis, MO 63146
Phone (314) 214-7703
FAX (314) 983-3238
bsimms@talx.com
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of MARK
COLLINS
Sent: Tuesday, January 24, 2012 2:26 PM
To: ids@iiug.org
Subject: Re: Informix job scheduler issues [26029]
Thanks for the response.
OK, that almost makes sense about the first run. I would have thought that
since I created the ph_task entry prior to the scheduled start time, that it
would use the specified start time to determine when to try the first run. The
way you describe it, if I want something to run at daily 6:00 PM starting
today, I would have had to create the ph_task entry yesterday?
I did confirm the run times and number of runs for the original posting by
querying ph_run.
You may be onto something about the logging. No, dev_db_2 is not logged.
Sadly, many of our databases are not logged (it's on our to-do list).
However, your idea of testing it by running EXECTASK seems to indicate that
this is not a problem. I executed the following:
database sysadmin;
execute function exectask("dev_db_2:my_test_function(3)");
and it appears to be running correctly (the function takes several minutes to
run, and it is taking time now. Last night, the ph_run indicated that it was
ending in less than a second.) Also, I am able to run the function manually
'execute function my_test_function(3)' successfully when I am logged in to
dev_db_2. I mention this because I am not certain whether the scheduler runs
the task from sysadmin, or if it instead connects to dev_db_2 prior to
attempting to execute the function.
The function is defined in dev_db_2. The signature is
my_test_function(smallint) returning integer.
Can you give me more details, or tell me where to find more details, about the
problem calculating stop time (the problem affecting AUS) in this version?
Also, where is EXECTASK documented? I did a search in the online docs and came
up with no matches.
>> When you set it to run at 1H interval, it will wait that interval to
>> run the first time. So it would have run at around 20:05H.
>> I don't have a good explanation to the other questions (specially the
>> 99 runs - did you verified this on ph_run?).
>>
>> As for why it didn't run... Your database dev_db_2 has logging?
>> Where did you create your function?
>> What is the function signature?
>>
>> For he scheduling issue I believe that version has a problem that
>> leads to a bad calculation of the stop time (it affected AUS) but it
>> doesn't seem to match your scenario...
>> But I'd suggest you solve the reason why it doesn't run and then try
>> to check the scheduling.
>>
>> You can run the task manually using:
>>
>> DATABASE sysadmin;
>> EXECUTE FUNCTION EXECTASK("my_test_function");
Regards.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
In version 11.70 the database scheduler can execute SQL/functions in
non-logged databases.
John F. Miller III
STSM, Embedability Architect
miller3@us.ibm.com
503-578-5645
IBM Informix Dynamic Server (IDS)
(Embedded image moved to file: pic23978.gif)
ids-bounces@iiug.org wrote on 01/24/2012 12:32:51 PM:
> From: "Bruce Simms" <Bruce.Simms@talx.com>
> To: ids@iiug.org
> Date: 01/24/2012 12:39 PM
> Subject: RE: Informix job scheduler issues [26030]
> Sent by: ids-bounces@iiug.org
>
> I have tried to use the scheduler and after opening a case found that it
> requires the database to be logged. I was told they were look at fixing
it so
> it would work with logged on non-logged databases.
>
> Bruce Simms
> Data Base Services
> TALX, Provider of Equifax Workforce Solutions
> 2330 Ball Drive
> St. Louis, MO 63146
>
> Phone (314) 214-7703
> FAX (314) 983-3238
> bsimms@talx.com
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
MARK
> COLLINS
> Sent: Tuesday, January 24, 2012 2:26 PM
> To: ids@iiug.org
> Subject: Re: Informix job scheduler issues [26029]
>
> Thanks for the response.
>
> OK, that almost makes sense about the first run. I would have thought
that
> since I created the ph_task entry prior to the scheduled start time, that
it
> would use the specified start time to determine when to try the
> first run. The
> way you describe it, if I want something to run at daily 6:00 PM starting
> today, I would have had to create the ph_task entry yesterday?
>
> I did confirm the run times and number of runs for the original posting
by
> querying ph_run.
>
> You may be onto something about the logging. No, dev_db_2 is not logged.
> Sadly, many of our databases are not logged (it's on our to-do list).
>
> However, your idea of testing it by running EXECTASK seems to indicate
that
> this is not a problem. I executed the following:
>
> database sysadmin;
> execute function exectask("dev_db_2:my_test_function(3)");>
> and it appears to be running correctly (the function takes several
minutes to
> run, and it is taking time now. Last night, the ph_run indicated that it
was
> ending in less than a second.) Also, I am able to run the function
manually
> 'execute function my_test_function(3)' successfully when I am logged in
to
> dev_db_2. I mention this because I am not certain whether the scheduler
runs
> the task from sysadmin, or if it instead connects to dev_db_2 prior to
> attempting to execute the function.
>
> The function is defined in dev_db_2. The signature is
> my_test_function(smallint) returning integer.
>
> Can you give me more details, or tell me where to find more details,about
the
> problem calculating stop time (the problem affecting AUS) in this
version?
>
> Also, where is EXECTASK documented? I did a search in the online
> docs and came
> up with no matches.
>
> >> When you set it to run at 1H interval, it will wait that interval to
> >> run the first time. So it would have run at around 20:05H.
> >> I don't have a good explanation to the other questions (specially the
> >> 99 runs - did you verified this on ph_run?).
> >>
> >> As for why it didn't run... Your database dev_db_2 has logging?
> >> Where did you create your function?
> >> What is the function signature?
> >>
> >> For he scheduling issue I believe that version has a problem that
> >> leads to a bad calculation of the stop time (it affected AUS) but it
> >> doesn't seem to match your scenario...
> >> But I'd suggest you solve the reason why it doesn't run and then try
> >> to check the scheduling.
> >>
> >> You can run the task manually using:
> >>
> >> DATABASE sysadmin;
> >> EXECUTE FUNCTION EXECTASK("my_test_function");>
> Regards.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
On Tue, Jan 24, 2012 at 8:26 PM, MARK COLLINS <markc@myfastmail.com> wrote:
> Thanks for the response.
>
> OK, that almost makes sense about the first run. I would have thought that
> since I created the ph_task entry prior to the scheduled start time, that
> it
> would use the specified start time to determine when to try the first run.
> The
> way you describe it, if I want something to run at daily 6:00 PM starting
> today, I would have had to create the ph_task entry yesterday?
>
Err... probably. I'd have to make a few tests or check the docs... Another
option would be to schedule it with a small interval to make it run today
(just once) and then change the interval. Err... again... I believe you
could get it done by filling the tk_next_execution field in ph_task
>
> I did confirm the run times and number of runs for the original posting by
> querying ph_run.
>
> You may be onto something about the logging. No, dev_db_2 is not logged.
> Sadly, many of our databases are not logged (it's on our to-do list).
>
> However, your idea of testing it by running EXECTASK seems to indicate that
> this is not a problem. I executed the following:
>
> database sysadmin;
> execute function exectask("dev_db_2:my_test_function(3)");>
Weird... This should take the task name as the parameter....
>
> and it appears to be running correctly (the function takes several minutes
> to
> run, and it is taking time now. Last night, the ph_run indicated that it
> was
> ending in less than a second.) Also, I am able to run the function manually
> 'execute function my_test_function(3)' successfully when I am logged in to
> dev_db_2. I mention this because I am not certain whether the scheduler
> runs
> the task from sysadmin, or if it instead connects to dev_db_2 prior to
> attempting to execute the function.
>
> The function is defined in dev_db_2. The signature is
> my_test_function(smallint) returning integer.
>
> Can you give me more details, or tell me where to find more details, about
> the
> problem calculating stop time (the problem affecting AUS) in this version?
>
http://www.ibm.com/support/docview.wss?uid=swg1IC70870
But the APAR doc is strange. It's fixed...
And it doesn't look like the problem you had.
>
> Also, where is EXECTASK documented? I did a search in the online docs and
> came
> up with no matches.
>
John Miller mentioned it here previously, but it's referenced in:
http://www.redbooks.ibm.com/abstracts/sg247666.html?Open
The RedBook for embedding Informix. But I really don't understand how it
worked for you...
Regards
>
> >> When you set it to run at 1H interval, it will wait that interval to run
> >> the first time. So it would have run at around 20:05H.
> >> I don't have a good explanation to the other questions (specially the 99
> >> runs - did you verified this on ph_run?).
> >>
> >> As for why it didn't run... Your database dev_db_2 has logging?
> >> Where did you create your function?
> >> What is the function signature?
> >>
> >> For he scheduling issue I believe that version has a problem that leads
> to
> >> a bad calculation of the stop time (it affected AUS) but it doesn't
> seem to
> >> match your scenario...
> >> But I'd suggest you solve the reason why it doesn't run and then try to
> >> check the scheduling.
> >>
> >> You can run the task manually using:
> >>
> >> DATABASE sysadmin;
> >> EXECUTE FUNCTION EXECTASK("my_test_function");>
> Regards.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--20cf300faebb95275b04b74dc356
What is really happening:
What happens when you create a task? The tk_next_execution time
gets sent to CURRENT and time values are sanity checked. If the time
values fit executing the task now we continue to execute the task else
we do not execute the task, but just request that the task be schedule for
the
next valid execution. This is tracked as the task running even though the
function
itself was not executed, it was work done to manage this task (often very
small).
In order to simulate the a task being executed by the scheduler
the function exetask() are availible. These force the worker
thread to execute the task now, even if the schedule indicates
it should not be run.
execute function exectask( tk_name )
OR
execute function exectask( tk_id )
Something that does not seem correct is
that the exectask() function does not take
the function to be executed, but rather the
name of the task which is is stored in tk_name
column. In version 11.50 if you called this with
an incorrect name to many times this could
serverly slow down the scheduler and a restart
of the scheduler would clena this up.
I would look at the onstat option onstat -g dbc to view any error
messages which occur during the running of your task.
John F. Miller III
STSM, Embedability Architect
miller3@us.ibm.com
503-578-5645
IBM Informix Dynamic Server (IDS)
(Embedded image moved to file: pic00070.gif)
ids-bounces@iiug.org wrote on 01/24/2012 12:26:20 PM:
> From: "MARK COLLINS" <markc@myfastmail.com>
> To: ids@iiug.org
> Date: 01/24/2012 12:32 PM
> Subject: Re: Informix job scheduler issues [26029]
> Sent by: ids-bounces@iiug.org
>
> Thanks for the response.
>
> OK, that almost makes sense about the first run. I would have thought
that
> since I created the ph_task entry prior to the scheduled start time, that
it
> would use the specified start time to determine when to try the
> first run. The
> way you describe it, if I want something to run at daily 6:00 PM starting
> today, I would have had to create the ph_task entry yesterday?
>
> I did confirm the run times and number of runs for the original posting
by
> querying ph_run.
>
> You may be onto something about the logging. No, dev_db_2 is not logged.
> Sadly, many of our databases are not logged (it's on our to-do list).
>
> However, your idea of testing it by running EXECTASK seems to indicate
that
> this is not a problem. I executed the following:
>
> database sysadmin;
> execute function exectask("dev_db_2:my_test_function(3)");>
> and it appears to be running correctly (the function takes several
minutes to
> run, and it is taking time now. Last night, the ph_run indicated that it
was
> ending in less than a second.) Also, I am able to run the function
manually
> 'execute function my_test_function(3)' successfully when I am logged in
to
> dev_db_2. I mention this because I am not certain whether the scheduler
runs
> the task from sysadmin, or if it instead connects to dev_db_2 prior to
> attempting to execute the function.
>
> The function is defined in dev_db_2. The signature is
> my_test_function(smallint) returning integer.
>
> Can you give me more details, or tell me where to find more details,about
the
> problem calculating stop time (the problem affecting AUS) in this
version?
>
> Also, where is EXECTASK documented? I did a search in the online
> docs and came
> up with no matches.
>
> >> When you set it to run at 1H interval, it will wait that interval to
run
> >> the first time. So it would have run at around 20:05H.
> >> I don't have a good explanation to the other questions (specially the
99
> >> runs - did you verified this on ph_run?).
> >>
> >> As for why it didn't run... Your database dev_db_2 has logging?
> >> Where did you create your function?
> >> What is the function signature?
> >>
> >> For he scheduling issue I believe that version has a problem thatleads
to
> >> a bad calculation of the stop time (it affected AUS) but it
> doesn't seem to
> >> match your scenario...
> >> But I'd suggest you solve the reason why it doesn't run and then try
to
> >> check the scheduling.
> >>
> >> You can run the task manually using:
> >>
> >> DATABASE sysadmin;
> >> EXECUTE FUNCTION EXECTASK("my_test_function");>
> Regards.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
Fernando, John,
Thanks for the responses. I found that the task was not actually executing
when I ran it with the name of the function. It never responded after that,
and I had to kill the session.
Also, I was able to change the database (it's a test database) to a logged
database. Once I did that, I had to reset tk_next_execution, and then it ran
correctly, and ran successfully every hour until midnight. Then it stopped,
even though there was no "stop time" specified, and tk_next execution now
shows 01/26/2012 13:15:00, which matches the start time I specified yesterday.
I will watch to see if it really restarts then.
I really wanted it to run every hour, period. Perhaps if I give a start time
of 00:10:00 and an end time of 23:55:00 it will work. Something else to try.
>> What is really happening:
>>
>> What happens when you create a task? The tk_next_execution time
>> gets sent to CURRENT and time values are sanity checked. If the time
>> values fit executing the task now we continue to execute the task else
>> we do not execute the task, but just request that the task be schedule for
>> the
>> next valid execution. This is tracked as the task running even though the
>> function
>> itself was not executed, it was work done to manage this task (often very
>> small).
>>
>> In order to simulate the a task being executed by the scheduler
>> the function exetask() are availible. These force the worker
>> thread to execute the task now, even if the schedule indicates
>> it should not be run.
>>
>> execute function exectask( tk_name )>>
>> OR
>> execute function exectask( tk_id )>>
>> Something that does not seem correct is
>> that the exectask() function does not take
>> the function to be executed, but rather the
>> name of the task which is is stored in tk_name
>> column. In version 11.50 if you called this with
>> an incorrect name to many times this could
>> serverly slow down the scheduler and a restart
>> of the scheduler would clena this up.
>>
>> I would look at the onstat option onstat -g dbc to view any error
>> messages which occur during the running of your task.
>>
>> John F. Miller III
>> STSM, Embedability Architect
>> miller3@us.ibm.com
>> 503-578-5645
>> IBM Informix Dynamic Server (IDS)
>> (Embedded image moved to file: pic00070.gif)
If you would like it to run every hour, then set the stop and start
time both to NULL and the tk_frequency to 1 hour. There are
several built in tasks with both the start and stop times set to
NULL (see mon_profile as an example)
John F. Miller III
STSM, Embedability Architect
miller3@us.ibm.com
503-578-5645
IBM Informix Dynamic Server (IDS)
(Embedded image moved to file: pic65069.gif)
ids-bounces@iiug.org wrote on 01/26/2012 08:18:30 AM:
> From: "MARK COLLINS" <markc@myfastmail.com>
> To: ids@iiug.org
> Date: 01/26/2012 08:20 AM
> Subject: Re: Informix job scheduler issues [26051]
> Sent by: ids-bounces@iiug.org
>
> Fernando, John,
>
> Thanks for the responses. I found that the task was not actually
executing
> when I ran it with the name of the function. It never responded after
that,
> and I had to kill the session.
>
> Also, I was able to change the database (it's a test database) to a
logged
> database. Once I did that, I had to reset tk_next_execution, and then it
ran
> correctly, and ran successfully every hour until midnight. Then it
stopped,
> even though there was no "stop time" specified, and tk_next execution now
> shows 01/26/2012 13:15:00, which matches the start time I specified
> yesterday.
> I will watch to see if it really restarts then.
>
> I really wanted it to run every hour, period. Perhaps if I give a start
time
> of 00:10:00 and an end time of 23:55:00 it will work. Something else to
try.
>
> >> What is really happening:
> >>
> >> What happens when you create a task? The tk_next_execution time
> >> gets sent to CURRENT and time values are sanity checked. If the time
> >> values fit executing the task now we continue to execute the task else
> >> we do not execute the task, but just request that the task be schedule
for
> >> the
> >> next valid execution. This is tracked as the task running even though
the
> >> function
> >> itself was not executed, it was work done to manage this task (often
very
> >> small).
> >>
> >> In order to simulate the a task being executed by the scheduler
> >> the function exetask() are availible. These force the worker
> >> thread to execute the task now, even if the schedule indicates
> >> it should not be run.
> >>
> >> execute function exectask( tk_name )> >>
> >> OR
> >> execute function exectask( tk_id )> >>
> >> Something that does not seem correct is
> >> that the exectask() function does not take
> >> the function to be executed, but rather the
> >> name of the task which is is stored in tk_name
> >> column. In version 11.50 if you called this with
> >> an incorrect name to many times this could
> >> serverly slow down the scheduler and a restart
> >> of the scheduler would clena this up.
> >>
> >> I would look at the onstat option onstat -g dbc to view any error
> >> messages which occur during the running of your task.
> >>
> >> John F. Miller III
> >> STSM, Embedability Architect
> >> miller3@us.ibm.com
> >> 503-578-5645
> >> IBM Informix Dynamic Server (IDS)
> >> (Embedded image moved to file: pic00070.gif)
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
John, Thanks for the info. I will try that next, but I hope that someone might be able to explain some strange behavior that seems to happen near midnight. I have the job defined in ph_task with tk_start_time = 13:15:00, and tk_frequency = 0 01:00:00. The first time on Wednesday, it didn't start at 13:15:00, so I manually set tk_next_execution to 'current + 5 units minute', which ended up 15:38:00. From that point on, it ran correctly at 38 past the hour, every hour from 15:38:00 through 23:38:00, taking a little over four minutes each time. Then things get weird. Selecting run_id, run_task_seq, and run_time from ph_run, I get: run_id run_task_seq run_time 81369 3 2012-01-25 15:42:19 81378 4 2012-01-25 16:42:33 81388 5 2012-01-25 17:42:31 81396 6 2012-01-25 18:43:26 81406 7 2012-01-25 19:42:30 81411 8 2012-01-25 20:42:29 81417 9 2012-01-25 21:42:28 81422 10 2012-01-25 22:42:31 81431 11 2012-01-25 23:42:31 81670 12 2012-01-25 23:48:32 82479 13 2012-01-25 23:59:26 82518 14 2012-01-26 00:04:11 So run_seq 3 through 11 are correct. Then, just a couple of minutes after #11 finishes, #12 starts at 23:44:00, followed by #13 at 23:55:00, and #14 at 00:00:00. As I mentioned in the previous email, the job then stops, but starts up at the desired tk_start_time of 13:15:00. Runs identified by task_seq 15 through 25 show "correct" runs, but then things go weird, with 9 extra runs: run_id run_task_seq run_time 82589 15 2012-01-26 13:19:02 82599 16 2012-01-26 14:19:01 82608 17 2012-01-26 15:19:01 82626 18 2012-01-26 16:19:01 82635 19 2012-01-26 17:19:02 82644 20 2012-01-26 18:19:00 82650 21 2012-01-26 19:18:56 82659 22 2012-01-26 20:18:55 82664 23 2012-01-26 21:18:58 82671 24 2012-01-26 22:18:58 82676 25 2012-01-26 23:18:58 82677 26 2012-01-26 23:22:38 82678 27 2012-01-26 23:26:23 82684 28 2012-01-26 23:30:05 82685 29 2012-01-26 23:33:48 82686 30 2012-01-26 23:37:31 82687 31 2012-01-26 23:41:17 82688 32 2012-01-26 23:45:00 83406 33 2012-01-26 23:55:15 83725 34 2012-01-27 00:02:50 Any thoughts about why these "extra" runs are occurring as the time gets close to midnight? >> If you would like it to run every hour, then set the stop and >> start time both to NULL and the tk_frequency to 1 hour. There are >> several built in tasks with both the start and stop times set to >> NULL (see mon_profile as an example)
What does the ph_task record look like in the middle of the nine every-four-minute runs just before midnight? Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jan 27, 2012 at 10:34 AM, MARK COLLINS <markc@myfastmail.com> wrote: > John, > > Thanks for the info. I will try that next, but I hope that someone might be > able to explain some strange behavior that seems to happen near midnight. > > I have the job defined in ph_task with tk_start_time = 13:15:00, and > tk_frequency = 0 01:00:00. The first time on Wednesday, it didn't start at > 13:15:00, so I manually set tk_next_execution to 'current + 5 units > minute', > which ended up 15:38:00. From that point on, it ran correctly at 38 past > the > hour, every hour from 15:38:00 through 23:38:00, taking a little over four > minutes each time. Then things get weird. Selecting run_id, run_task_seq, > and > run_time from ph_run, I get: > > run_id run_task_seq run_time > > 81369 3 2012-01-25 15:42:19 > > 81378 4 2012-01-25 16:42:33 > > 81388 5 2012-01-25 17:42:31 > > 81396 6 2012-01-25 18:43:26 > > 81406 7 2012-01-25 19:42:30 > > 81411 8 2012-01-25 20:42:29 > > 81417 9 2012-01-25 21:42:28 > > 81422 10 2012-01-25 22:42:31 > > 81431 11 2012-01-25 23:42:31 > > 81670 12 2012-01-25 23:48:32 > > 82479 13 2012-01-25 23:59:26 > > 82518 14 2012-01-26 00:04:11 > > So run_seq 3 through 11 are correct. Then, just a couple of minutes after > #11 > finishes, #12 starts at 23:44:00, followed by #13 at 23:55:00, and #14 at > 00:00:00. > > As I mentioned in the previous email, the job then stops, but starts up at > the > desired tk_start_time of 13:15:00. Runs identified by task_seq 15 through > 25 > show "correct" runs, but then things go weird, with 9 extra runs: > > run_id run_task_seq run_time > > 82589 15 2012-01-26 13:19:02 > > 82599 16 2012-01-26 14:19:01 > > 82608 17 2012-01-26 15:19:01 > > 82626 18 2012-01-26 16:19:01 > > 82635 19 2012-01-26 17:19:02 > > 82644 20 2012-01-26 18:19:00 > > 82650 21 2012-01-26 19:18:56 > > 82659 22 2012-01-26 20:18:55 > > 82664 23 2012-01-26 21:18:58 > > 82671 24 2012-01-26 22:18:58 > > 82676 25 2012-01-26 23:18:58 > > 82677 26 2012-01-26 23:22:38 > > 82678 27 2012-01-26 23:26:23 > > 82684 28 2012-01-26 23:30:05 > > 82685 29 2012-01-26 23:33:48 > > 82686 30 2012-01-26 23:37:31 > > 82687 31 2012-01-26 23:41:17 > > 82688 32 2012-01-26 23:45:00 > > 83406 33 2012-01-26 23:55:15 > > 83725 34 2012-01-27 00:02:50 > > Any thoughts about why these "extra" runs are occurring as the time gets > close > to midnight? > > >> If you would like it to run every hour, then set the stop and > >> start time both to NULL and the tk_frequency to 1 hour. There are > >> several built in tasks with both the start and stop times set to > >> NULL (see mon_profile as an example) > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340f9dc4c32e04b7845e59
>> What does the ph_task record look like in the middle of the nine >> every-four-minute runs just before midnight? >> >> Art A very good question, and one that I can not answer. I can put a job together to track that for tonight and post the findings.
Art, I put a job in place to extract the ph_task row for this task every minute between 23:00:00 and 01:00:00. First, though, here is a listing of run_id, run_task_seq, run_time, and run_duration for those timeframes: run_id run_task_seq run_time run_duration 83878 44 2012-01-27 22:18:59 238.3691137240 83883 45 2012-01-27 23:18:59 237.3704702960 83884 46 2012-01-27 23:22:42 223.1655906960 83885 47 2012-01-27 23:26:26 224.1932542360 83891 48 2012-01-27 23:30:10 224.1815808520 83892 49 2012-01-27 23:33:57 226.1970016640 83893 50 2012-01-27 23:37:41 224.1519945040 83894 51 2012-01-27 23:41:23 222.1748240520 83903 52 2012-01-27 23:45:09 226.2174782520 84558 53 2012-01-27 23:55:26 616.2679021120 84865 54 2012-01-28 00:02:54 448.3445583280 84938 55 2012-01-28 13:19:00 237.3244417640 Moving now to the ph_task, I see the following: Time tk_sequence tk_next_execution 23:00:00 44 2012-01-27 23:15:00 23:01:00 44 2012-01-27 23:15:00 23:02:00 44 2012-01-27 23:15:00 23:03:00 44 2012-01-27 23:15:00 23:04:00 44 2012-01-27 23:15:00 23:05:00 44 2012-01-27 23:15:00 23:06:00 44 2012-01-27 23:15:00 23:07:00 44 2012-01-27 23:15:00 23:08:00 44 2012-01-27 23:15:00 23:09:00 44 2012-01-27 23:15:00 23:10:00 44 2012-01-27 23:15:00 23:11:00 44 2012-01-27 23:15:00 23:12:00 44 2012-01-27 23:15:00 23:13:00 44 2012-01-27 23:15:00 23:14:00 44 2012-01-27 23:15:00 23:15:00 44 2012-01-27 23:15:00 23:16:00 45 2012-01-27 23:15:00 23:17:00 45 2012-01-27 23:15:00 23:18:00 45 2012-01-27 23:15:00 23:19:00 46 2012-01-27 13:15:00 23:20:00 46 2012-01-27 13:15:00 23:21:00 46 2012-01-27 13:15:00 23:22:00 46 2012-01-27 13:15:00 23:23:01 47 2012-01-27 13:15:00 23:24:00 47 2012-01-27 13:15:00 23:25:00 47 2012-01-27 13:15:00 23:26:00 47 2012-01-27 13:15:00 23:27:00 48 2012-01-27 13:15:00 23:28:00 48 2012-01-27 13:15:00 23:29:00 48 2012-01-27 13:15:00 23:30:00 48 2012-01-27 13:15:00 23:31:00 49 2012-01-27 13:15:00 23:32:00 49 2012-01-27 13:15:00 23:33:00 49 2012-01-27 13:15:00 23:34:00 50 2012-01-27 13:15:00 23:35:00 50 2012-01-27 13:15:00 23:36:00 50 2012-01-27 13:15:00 23:37:00 50 2012-01-27 13:15:00 23:38:00 51 2012-01-27 13:15:00 23:39:00 51 2012-01-27 13:15:00 23:40:00 51 2012-01-27 13:15:00 23:41:00 51 2012-01-27 13:15:00 23:42:01 52 2012-01-27 13:15:00 23:43:00 52 2012-01-27 13:15:00 23:44:00 52 2012-01-27 13:15:00 23:45:00 52 2012-01-27 13:15:00 23:46:00 53 2012-01-27 13:15:00 23:47:00 53 2012-01-27 13:15:00 23:48:00 53 2012-01-27 13:15:00 23:49:01 53 2012-01-27 13:15:00 23:50:00 53 2012-01-27 13:15:00 23:51:00 53 2012-01-27 13:15:00 23:52:00 53 2012-01-27 13:15:00 23:53:00 53 2012-01-27 13:15:00 23:54:00 53 2012-01-27 13:15:00 23:55:00 53 2012-01-27 13:15:00 23:56:00 54 2012-01-27 13:15:00 23:57:00 54 2012-01-27 13:15:00 23:58:00 54 2012-01-27 13:15:00 23:59:00 54 2012-01-27 13:15:00 00:00:00 54 2012-01-27 13:15:00 00:01:00 54 2012-01-27 13:15:00 00:02:00 54 2012-01-27 13:15:00 00:03:00 54 2012-01-28 13:15:00 00:04:00 54 2012-01-28 13:15:00 00:05:00 54 2012-01-28 13:15:00 00:06:00 54 2012-01-28 13:15:00 00:07:00 54 2012-01-28 13:15:00 00:08:00 54 2012-01-28 13:15:00 00:09:00 54 2012-01-28 13:15:00 00:10:00 54 2012-01-28 13:15:00 00:11:00 54 2012-01-28 13:15:00 00:12:00 54 2012-01-28 13:15:00 00:13:00 54 2012-01-28 13:15:00 00:14:00 54 2012-01-28 13:15:00 00:15:00 54 2012-01-28 13:15:00 >> What does the ph_task record look like in the middle of the nine >> every-four-minute runs just before midnight? >> >> Art
OK, but what about the rest of the record? tk_next_execution may not be the problem. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Mon, Jan 30, 2012 at 5:25 PM, MARK COLLINS <markc@myfastmail.com> wrote: > Art, > > I put a job in place to extract the ph_task row for this task every minute > between 23:00:00 and 01:00:00. First, though, here is a listing of run_id, > run_task_seq, run_time, and run_duration for those timeframes: > > run_id run_task_seq run_time run_duration > > 83878 44 2012-01-27 22:18:59 238.3691137240 > > 83883 45 2012-01-27 23:18:59 237.3704702960 > > 83884 46 2012-01-27 23:22:42 223.1655906960 > > 83885 47 2012-01-27 23:26:26 224.1932542360 > > 83891 48 2012-01-27 23:30:10 224.1815808520 > > 83892 49 2012-01-27 23:33:57 226.1970016640 > > 83893 50 2012-01-27 23:37:41 224.1519945040 > > 83894 51 2012-01-27 23:41:23 222.1748240520 > > 83903 52 2012-01-27 23:45:09 226.2174782520 > > 84558 53 2012-01-27 23:55:26 616.2679021120 > > 84865 54 2012-01-28 00:02:54 448.3445583280 > > 84938 55 2012-01-28 13:19:00 237.3244417640 > > Moving now to the ph_task, I see the following: > > Time tk_sequence tk_next_execution > > 23:00:00 44 2012-01-27 23:15:00 > > 23:01:00 44 2012-01-27 23:15:00 > > 23:02:00 44 2012-01-27 23:15:00 > > 23:03:00 44 2012-01-27 23:15:00 > > 23:04:00 44 2012-01-27 23:15:00 > > 23:05:00 44 2012-01-27 23:15:00 > > 23:06:00 44 2012-01-27 23:15:00 > > 23:07:00 44 2012-01-27 23:15:00 > > 23:08:00 44 2012-01-27 23:15:00 > > 23:09:00 44 2012-01-27 23:15:00 > > 23:10:00 44 2012-01-27 23:15:00 > > 23:11:00 44 2012-01-27 23:15:00 > > 23:12:00 44 2012-01-27 23:15:00 > > 23:13:00 44 2012-01-27 23:15:00 > > 23:14:00 44 2012-01-27 23:15:00 > > 23:15:00 44 2012-01-27 23:15:00 > > 23:16:00 45 2012-01-27 23:15:00 > > 23:17:00 45 2012-01-27 23:15:00 > > 23:18:00 45 2012-01-27 23:15:00 > > 23:19:00 46 2012-01-27 13:15:00 > > 23:20:00 46 2012-01-27 13:15:00 > > 23:21:00 46 2012-01-27 13:15:00 > > 23:22:00 46 2012-01-27 13:15:00 > > 23:23:01 47 2012-01-27 13:15:00 > > 23:24:00 47 2012-01-27 13:15:00 > > 23:25:00 47 2012-01-27 13:15:00 > > 23:26:00 47 2012-01-27 13:15:00 > > 23:27:00 48 2012-01-27 13:15:00 > > 23:28:00 48 2012-01-27 13:15:00 > > 23:29:00 48 2012-01-27 13:15:00 > > 23:30:00 48 2012-01-27 13:15:00 > > 23:31:00 49 2012-01-27 13:15:00 > > 23:32:00 49 2012-01-27 13:15:00 > > 23:33:00 49 2012-01-27 13:15:00 > > 23:34:00 50 2012-01-27 13:15:00 > > 23:35:00 50 2012-01-27 13:15:00 > > 23:36:00 50 2012-01-27 13:15:00 > > 23:37:00 50 2012-01-27 13:15:00 > > 23:38:00 51 2012-01-27 13:15:00 > > 23:39:00 51 2012-01-27 13:15:00 > > 23:40:00 51 2012-01-27 13:15:00 > > 23:41:00 51 2012-01-27 13:15:00 > > 23:42:01 52 2012-01-27 13:15:00 > > 23:43:00 52 2012-01-27 13:15:00 > > 23:44:00 52 2012-01-27 13:15:00 > > 23:45:00 52 2012-01-27 13:15:00 > > 23:46:00 53 2012-01-27 13:15:00 > > 23:47:00 53 2012-01-27 13:15:00 > > 23:48:00 53 2012-01-27 13:15:00 > > 23:49:01 53 2012-01-27 13:15:00 > > 23:50:00 53 2012-01-27 13:15:00 > > 23:51:00 53 2012-01-27 13:15:00 > > 23:52:00 53 2012-01-27 13:15:00 > > 23:53:00 53 2012-01-27 13:15:00 > > 23:54:00 53 2012-01-27 13:15:00 > > 23:55:00 53 2012-01-27 13:15:00 > > 23:56:00 54 2012-01-27 13:15:00 > > 23:57:00 54 2012-01-27 13:15:00 > > 23:58:00 54 2012-01-27 13:15:00 > > 23:59:00 54 2012-01-27 13:15:00 > > 00:00:00 54 2012-01-27 13:15:00 > > 00:01:00 54 2012-01-27 13:15:00 > > 00:02:00 54 2012-01-27 13:15:00 > > 00:03:00 54 2012-01-28 13:15:00 > > 00:04:00 54 2012-01-28 13:15:00 > > 00:05:00 54 2012-01-28 13:15:00 > > 00:06:00 54 2012-01-28 13:15:00 > > 00:07:00 54 2012-01-28 13:15:00 > > 00:08:00 54 2012-01-28 13:15:00 > > 00:09:00 54 2012-01-28 13:15:00 > > 00:10:00 54 2012-01-28 13:15:00 > > 00:11:00 54 2012-01-28 13:15:00 > > 00:12:00 54 2012-01-28 13:15:00 > > 00:13:00 54 2012-01-28 13:15:00 > > 00:14:00 54 2012-01-28 13:15:00 > > 00:15:00 54 2012-01-28 13:15:00 > > >> What does the ph_task record look like in the middle of the nine > >> every-four-minute runs just before midnight? > >> > >> Art > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8f234cd3611ca404b7c6848e
Oh, boy, I didn't think you'd want that much detail, but here it is: 23:00:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:01:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:02:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:03:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:04:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:05:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:06:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:07:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:08:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:09:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:10:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:11:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_
Oh, boy, I didn't think you'd want that much detail, but here it is: 23:00:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:01:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:02:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:03:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:04:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:05:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:06:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:07:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:08:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:09:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:10:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_total_time 11291.71332490 tk_monday t tk_tuesday t tk_wednesday t tk_thursday t tk_friday t tk_saturday t tk_sunday t tk_attributes 80 tk_group INDEXES tk_enable t tk_priority 0 23:11:00 tk_id 40 tk_name my_test_function tk_description description for my_test_function tk_type TASK tk_sequence 44 tk_result_table tk_create tk_dbs dev_db_2 tk_execute execute function fn_my_test(3) tk_delete 10 00:00:00 tk_start_time 13:15:00 tk_stop_time tk_frequency 0 01:00:00 tk_next_execution 2012-01-27 23:15:00 tk_total_executio+ 43 tk_
Related threads
- Posting from the Informix-list
- Migrating from IDS 9.40.UC6 to 11.50.UC3
- Ip for a network session
- questions onstat -g