Clocks

[alloggil]

I am curious about the clock table and how it relates with the other tables in Peregrine. How is it updated? How can I get a value from that table into a Problem record?



Thanks

[fosterma]

The currently running or stopped clocks on an incident or call are tracked in this file. The clocks are set based on the status of the incident or call. Eg. when incident is in "open" status, the "open" clock is running. You can see this when you click the "CLOCKS" icon on the task bar when browsing/updating a call or incident. Clocks are controlled from the pm.status file which will start and stop any clock you wish based on the ticket status. All clocks stop when ticket is closed, you can then run reports against the clocks file using incident/call number as the key. =P

[Maggie]

Hi, hope someone can help me out here..

I have a clock running on incidents (still in test-enviroment), tracking open time, based on a calendar, working days only (mo-fri), from 07:00 till 19:00.

friday afternoon i opened two incidents, and resolved them today.
Open-clocks said the incidents were in open status for 11 hours and 54 minutes. Ok, so using the calendar works fine, clock skipped nights and weekends, cool.

BUT, when i added up the time by hand (did this several times!), it was about 13 hours and 30 minutes the incident was open (open time until 19:00 on friday + monday morning starting at 07:00 untill resolved time)!
I saw the clock starting on friday and stop today, so it is not a matter of starting/stopping the clock too early.

I can't figure out how come... unless the server being down for a while (nightly system-backup) is the reason... that couldn't be it? Don't tell me clocks are that intelligent? (please tell me i'm just dumb and overlooked something instead :wink:

Thx in advance,
Maggie

[tommy]

Which version of SC?

We have experienced that SC have trouble calculating using the calendars so my co-worker made his own calculations (at least that was the case on SC3 I don't know if we still do this on SC5)

And no the clocks don't stop if the server is stopped :wink:

Is the clock stopped or started on status changes? For example the total time clock is stopped if the status is changed to pending customer or pending vendor.

[Maggie]

Tommy,

We use SC405.

great, so i AM dumb? (women and computers.... :wink:
As far as I know clocks do not do more than just adding up times... so it was al long shot to begin with... i know.

Yes it changes on every status change, but i only had it in 'Work in progress' for about 10 seconds to prove the next clocks would start.

strange... must be the calendar then... could'nt find anything wrong there though. What exactly was your co-worker having problems with? You remember?

[Maggie]

oh, and i don't use the clocks defined in pmstatus, because they don't use the calendars. I've stopped them from running, cause they serve no use as long as you cannot define a calendar with them.. too bad.
So i have to recreate them now via macros....

[tommy]

Oops ops: , I think I am mxing things now. The problems we had was with escalation and calculation of next alert times.

But it could be the same that is affecting You. Can You post some screenshots of the clocks in question?

[Maggie]

I will do that tomorrow at work, thanx!

[Maggie]

oh, and yes, we are using calendars on time/alert escalation as well... so we might have a problem here also, but probably never noticed them?
Because of lack of enough personel and time, we kind of ignore all the alerts, but still....

[pcasey]

Clocks only recalculate their time when they are closed. Thus, if you read the times off of the clocks table and look at clocks which are currently "running" e.g. they have started but not yet stopped, you'll get invalid times.

Clocks are manually recalcuated whenever you push the "clocks" button inside of Problem Management or Call Management, thus masking the issue. If you go in through db manager though, and look at the clocks table, running clocks will only be accurate to the last time they were either closed or viewed through PM/CM.

For this reason, you should only report off of (and the OOB reports follow this), "closed" clocks.

[Maggie]

Hi Pat,

Thanx for the reply. Did everything by the book though, still doesn't add up! :wink:

Now you're in the discussion anyway (saw your name on a rad routine involved;-) my clocks only start at first save, the 'real' clocks defined in pmstatus start the moment a ticket is opened. How is it done? (difference is only a few seconds or maybe 1 minute, but still...)

and why is there no ability of using calendars in pmstatus? And why only able to track incidents there? Was it forgotten to add extra functionality there??

[pcasey]

There was rad code that started some of the clocks as soon as you started editing a new problem ticket. It used to be done inside apm.edit.problem, but they recently depricated that routine so if the special case is still in place you'll find it in se.view.engine or in a process thereof.

As for the state change clocks, they're actually in one of two ways, based on what you have set for the "bg.clock" flag in your pmenv record (It's labelled something like "Process State Changes in Background").

If you have this flag set to true (the default), then state changes happen like this:

You save Ticket at time X.
The system writes out a schedule record recording the ticket number, old state, new state, and current time.
The problem scheduler wakes up anywhere from zero to 60 seconds later and processes the state change record.
The appropriate clocks are started and/or stopped as though they had actually been started and/or stopped at the time specified in the schedule record.

If you have this flag set to "false" then the clocks are started or stopped as part of the ordinary foreground problem save cascade.

In either case though, the code that timestamps the state change is *very* late in the problem cascade. It's actually invoked in a trigger after the probsummary record is written which means it's almost the last thing that happens before the user gets control back. On a system that isn't whippet-fast, you can get a situation like this:

At 12:00:00 I press save the hard coded rad clocks start/stop here.
The rest of the processing takes, say, 3 seconds.
At 12:00:03 the system starts/stops the state change clocks.
At 12:00:04 the user gets control back.

[Maggie]

Pat,
thanx, give me some time to have thing fall into peaces (have to concentrate on the english). Do yoou remember we spoke on the phone about intraflow, and the problems wiith SC4.x on aix?

[pcasey]

Ah, yes, I do recall those conversations. You were working with Maurice Terds and Dennis van Drie over there, weren't you?

I hope things are well with you,

--- Pat

[PieterVanPetegem]

We only use clocks that are defined via RAD in scripts that are executed by subroutines.

You cal use following RAD's:

apm.start.clock

name - table name
prompt - clock name
query -ID of the associated record (e.g. incident.id in $file)
string1 -name of the schedule used.

To stop a clock you can use apm.stop.clock with the same parameters.

Hope this can help some of you!

Greetings,

Pieter

[Maggie]

Hi. Thx!
Other things came up, so i haven't had the time to look into the clock-mystery any further. Will have a try tomorrow, and let things know here...

[Maggie]

Well, while getting all the nessecary info together to put it here, i found out where things went wrong.... it was in the calendars/duty hours of this test-system, the last time i was playing around with that, i didn't recalc/rebuild things correctly.... ops: ops: ops:

(like i said in the beginning; please tell me i am stupid and overlooked something;-)

Thanx for all the help, tips and explanations!

[tommy]

Everybody make mistakes sometimes - if they say they don't they are lying :wink:

[Maggie]

That is true, and sometimes you just need someone else to look at things to see where things go wrong.
Still a bit ashamed, but learned from this item through the suggestions and explanations, so it wasn't for nothing;-)


(only poor Pat... has an intraflow problem of mine in his hands now, he must probably think, "Oh my god, what hás she overlooked this time...." :wink: