SYS TOTAL OR DIM & FEATS DISPLAY?

[MitelInMyBlood]

System: SX2K Redundant, expanded pers.

Per the topic name, I'm trying to determine which number is right.

SYS TOT is giving me a number (1898 total stations) comprised of 1486 DNI, 48 COV and 364 ONS.

By comparison, DIM A F D is giving me 1496 Multiline Sets and 490 single line sets, or 1,986 total stations

So who is right? I'm concerned because I'm running MFRD-21 and we're about to hit the wall. The question is, am I 66 multiline sets away from "the wall" or is it 104?

FLEX DIMS ****IS NOT**** a desirable option.

 

[kwbMitel]

At a guess, the difference may lie in Non-Prime DN's.

System Totals may not count these.

The Dim a f d display would be the number I would trust as far as "Hitting the Wall" is concerned.


*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[MitelInMyBlood]

I would tend to trust DIM A F D as well. I just want to be sure if I get bitten, which dog will be doing the biting.

 

[MitelInMyBlood]

And by the way, for the benefit of anyone ever considering stretching a 2K this far, I cannot recommend it. We have been experiencing PI issues for several months.

 

[MitelInMyBlood]

Random issues such as:

1. Most commonly - user complains that his SS4150 does not work in handsfree mode, spkr audio is muted until mic button is turned off. A set reboot solves it. I'll have 8~10 reports of this anomaly per week, scattered all around the machine, no rhyme or reason as to active controller or peripheral location. It will sometimes plague us for 2~3 days in a row then we'll go maybe a week without another recurrence.

2. User reports that the first incoming call in the morning to his multiline set is sometimes presented in handsfree mode even though the handset was lifted to answer. Subsequent calls are ok. We'll get 1 these complaints perhaps every 3~4 months, not often, but perplexing. I think the msg switch has maybe missed the event or doesn't know the status of the hookswitch as it only occurs on 1st call of the day (flwg activity xfr)

3. User complains that handsfree speaker audio sounds like single-sideband (unintelligile Donald Duck gibberish). A set reboot solves it. We get at least one report of this per month.

4. Attendant console (SS700) reports communications failure onscreen but appears to instantly recover and continue working. Happens every day. Have tried recabling, different PLID, different console, different handset cord, etc. SS700 is on a dedicated PLID with no other sets on the card. Have seen this on the Attendant's console as well as on the maint console in my office. (both are SS700)

5. Machine raises a Major, reporting loss of several DTMF receivers all common to one PSC. A directed test will clear these, but then a few minutes later the PSC reloads. If you leave it alone (without doing a directed test) it will eventually clear the failed DTMF Rcvrs on its own and without causing the PER to reload. We'll see this a couple times a month, never on the same PSC - again purely random around the switch during peak traffic in the AM.

6. Machine raises a Minor, reporting loss of only one DNIC plid. Again, purely at random around the switch. Only happens in the early AM, a couple hours or so after the DBMS check completes. We'll see this anywhere from 2~3 times a month to 2~3 times a week, never on the same PLID, never in the same PER node, doesn't follow with any specific plane being active.

7. Machine raises a Major & switches planes spontaneously, reporting loss of tone generator. Happens infrequently, every 2~3 months. Leave it along and it will come back on its own and be fine for amother 2~3 months. Sliding the MCIII out and in doesn't seem to have an impact on frequency of occurrence. Randomly, seldom the same plane.

Machine is on LW34.2.7.4 MFRD 21, Traffic level 20. These issues, one and all, have been present in the machine for years, and seem to show up every time we get above 1300 multiline sets in service. I really don't think there's anything wrong with the machine other than msg switch overloading.

Nightly activity switch goes OK, daily DBMS check always clean. Drives and MCIII are all original, installed with system in 1999

Sys tot:
TOTAL TRUNKS 281 TOTAL STATIONS 1897
TOTAL ATTENDANTS 2

CEPT TRUNKS 120 UNIVERSAL T1 TRUNKS 161

On Premise Stations 364 DNI Stations 1485
COV Stations 48

Never any congestion reports.
One member of a 3-member cluster

 

[Mitel1973]

The reason for the difference is probably because you have a greater quantity of sets programmed in the DNI Assignment than you do in the Multiline Set Assignment. The hierarchy of the forms on the SX2k means that you first assign the type of sets that you want against each ciruit of the card in the DNI Assignment and then you allocate extension numbers to the sets in the Multiline Set Assignment. If you have programmed set types in the DNI assignment but then not allocated extension numbers to them in the Multiline Set Assignment this will cause a difference! Hope that helps - my SX2K memories are a little rusty!

 

[MitelInMyBlood]

Thanks. However, there are no DNI ports defined that are not in use with active extensions. However, there are a number of PLIDs where both channels of a specific PLID are defined, such as for AIM modules, PKMs, etc. But otherwise, all unassigned PLIDS are fully unassigned in the DNI form as well. That's how we keep it because that's called good housekeeping. A clean switch is a happy switch.

The body count in the DIM A F D form matches exactly with the number of assigned, active PLIDS (those with assigned numbers on them). The disparity is seen on the SYS TOT screen.

I am also pretty meticulous today about using OPSMAN for all my MACS and anything that doesn't propagate or errors out is hunted down and fixed. We do not ever "delete" stuff that won't propagate. You find it and fix it. I've become something of a stickler on that point because I had to clean up someone's mess one time in mismatched databases between OPS and several clustered switches.