Tk Out Grp error 1

[McGruff753]

Just took over a new site and the activity log has been getting flooded with the following errors:

07182005 14:44:48 CUSTINFO Undefined resource referenced Resource TK OUT GRP Value 0 SpecParm 206 SpecParm 14 33 TRUNK trunk_avail 136
07182005 14:44:56 CUSTINFO Undefined resource referenced Resource TK OUT GRP Value 0 SpecParm 206 SpecParm 14 33 TRUNK trunk_avail 136
07182005 14:45:14 CUSTINFO Undefined resource referenced Resource TK OUT GRP Value 0 SpecParm 206 SpecParm 5 33 TRUNK trunk_avail 136

Went onto Aspect's eServices and found this:

12112000 07:28:23 CUSTINFO Undefined resource referenced Resource TKOUT GRP Value SpecParm 207 SpecParm 1 33 TRUNK trunk_avail 100

This is a common problem and the fix is to modify the trunk database record. Usually occurs when a trunk group is deleted by the sys admin.

The following query can locate the trunks in question. Before running the first query you may want to do a count(*) first, because when you see these errors there usually are a lot of them.

select trknum, card_num, direct, in_grp_num, out_grp_num from trunk where direct = 'B' and (in_grp_num = 0 or out_grp_num = 0) order by card_num, trk_num;

Any trunks returned by this query may be a problem. If you happen to get zeros for both and there is no trunk group 0 defined, I think it would stand to reason that no calls will be processed on those trunks.

The following query will show all the trunk groups:
select grp_num from trunkgrp;

Finally, before running the first query you may want to do a count(*), first, because when you see these errors there usually are a lot of them.

Queries provided by jmcgee.

Okay, so the step by step process is a litle Greek to me. Anyone experienced this or can make sense of the directions to repair the issue? Is this a Unix thing? If so, then I guess I have to put it back in Aspect's hands cause I don't have the access to do this then. Thanks.

 

[chris13]

Hi,
the problem is that there is a trunk which is allowed to be used for outbound calls, but is not assigned an existing outgoing trunk group.

The "greek" code is just a SQL query; it shows card, port and so on from the table "trunks" for trunks with direction "B" (both = in- + outgoing) having in- or outgoing trunk group set to 0.
You can build a report using reportwriter (or crystal/seagate reports or anything else) to get the same results.

Or use customview, there are tables trunk_group and trunk, too. Look at the fields "in_grp_num" and "out_grp_num". If the trunks should be used for outbgoing calls, verfy that "out_grp_num" is always set to one of your existing trunk groups.

 

[McGruff753]

Thanks. I don't have access to the reporting, so I went into each Trunk one by one and checked their programming. Here's what I found:

4 Trunks, on their Characteristics tab under Direction, were set as ‘Inbound’, but the Trunk Group was being used for both Inbound and Outbound. I changed the 4 Trunks to ‘Both’. This was probably not the culprit, but...

115 Trunks, on their Characteristics tab under Direction, were set as ‘Both’, but the Trunk Group was being used for Inbound only. I changed the 115 Trunks to ‘Inbound’.

Have not seen the error re-occur since these changes and it's been about an hour and a half now.

 

[chris13]

Sounds good.
The errors occur when the system tries to select one of the "misconfigured" trunks; the probability to hit one of these depends on how many outbound calls are initiated at the same time and the configuration of the trunk groups (channel selection: ascending, descending, round robin, least used).

I wouldn't like to be resonsible for an ACD without having access to any reports. And beeing able to launch some ad hoc queries can be very helpfull and save a lot of time. Shure, that needs some knowledge, but imagine within seconds you can get the full picture from which supergroups an agent gets his calls, the CCTs which queue to these groups and the schedules at which these CCTs are bound to which DDIs...
At least I would talk to the reporting dept. and ask if they can give you the content of the basic configuration tables (trunks, trunk status, trunks goups, dnis...) as files (excel).

 

[IndianaSkinny]

Here is how to read this error message:

The Resource TK OUT GRP Value 0 says there is a trunk without an outgoing trunk group value when it is either a bothway or outgoing trunk.

SpecParm 206 says it is card 20/2. If the value is greater than 186, subtract 186 from the value for the slot and it will be span 2 in the slot.

SpecParm 14 gives you the channel on the card that is reporting the error.

 

[IndianaSkinny]

It must be Monday. Correction to my last post.

SpecParm 206 says it is card 38/2. If the value is greater than 168, subtract 168 from the value for the slot and it will be span 2 in the slot. Values 168 or less indicate the actual slot.

 

[McGruff753]

Yeah, that makes more sence. I don't have a card 20 as a DTIC or DTIC2. But 38/2 was definately one of the cards having the issue. Thanks for the response.

On a side note, do you have some sort of documentation that disects activity log error messages? Thanks.

 

[chris13]

Get an account for eServices at aspect.com.
There is file in the download-section called "Activity Log Message Guide" (almg.hlp).
Within eServices, there is "Guided Help". If you give the the right keywords you often can get some more detailed docs.

 

[IndianaSkinny]

The activity log message guide is available from Aspect. If you have access to eServices, look in technical library, callcenter, user guides. If not, your local support group should be able to provide it. I believe it is a general document available to customer.