Strange Entries in Stat Server Log

[Superglide]

Hi,
I was just cruising through some of our Stat Server log files and found the following:

Action: RoutingPoint '10211@Springvale'(WaitForNextCall):
Monitored since [05/12/03 15:57:56]
WaitForNextCall since [05/12/03 15:57:56]
CallWait (ConnID 30400376766868094) since [05/12/03 15:57:56]
CallWait (ConnID 30400376766868090) since [05/12/03 15:57:56]
CallWait (ConnID 30400376766868073) since [05/12/03 15:57:56]
CallWait (ConnID 30400376766868005) since [05/12/03 15:57:56]


The same is happening to some other VDN/Route Points as well, with one having 13,500 entries. These may have been genuine calls at some point in time (back on the 12/05) but why are they still in my log files? Has anyone seen this before? Our details:

New Genesys 6.5 install (The log is off a preprod stat server)
Avaya G3r with EAS

Thanks

Graeme

[Vic]

Ok, you have some tiny bitsy problem there, alright!

There are several things that you should be aware of statserver uses statserver.001 (or backup.001) file for backing all the information, so if your statserver is shutdown while calls were on queue and then those calls were dropped, when you restart your statserver it will read that file and will think that there are still some calls left in the queue and it will never know that those calls actually no longer exist. There are several ways of fixing this problem tweaking TServer option or just deleting backup.001 file before restarting your TServer.

There might be another reason for it, but this is all that I can think of right now.

[Superglide]

Hi,
I think we tracked it down today. It was (yet to be confirmed) caused by vector to vector processing in the Avaya. Goes like this:
The call hits a VDN which has a Vector associated with it to provide call treatments. Now there are several ways to leave the VDN. Route to Skill X, Route to VDN X or route to Vector X etc.

Apparantly if you do route to vector commands in a VDN that is also a Route Point then Genesys looses track of the call and still thinks it is waiting to be answered within the original VDN.

One of those quirks I suppose. But has the potential to really mess up Reporting and Stat Server (as Stat Server continues to report on them and just chews through CPU and Disk doing so).

Graeme