Possibly corrupted TN (type 2317) 6

[jdlrez]

Reading this thread:

http://tek-tips.com/viewthread.cfm?qid=286057

I have the same problem. I had to MOV a set from one TN to another due to office changes. It was an ACD set, and according to the thread I posted above, the TN the set Was on is probably now corrupted.

It shows up as a type 2317 and I cannot OUT it. I also cannot copy a set to it, or do a mov to it as it says it's "in the process of relocating."

The aforementioned thread suggests ini, or debug mode. I don't know anything about debug mode, or even how to get into it, and doing an ini is usually my last resort.

I'd rather not have to trace it back and re-punch to a new TN, so I'd like to hear my options (if I have any) first.

Thoughts?

 

[56BelAir]

You should never MOV or easy change an ACD set. This will cause corruption.

 

[jdlrez]

I realize that now. Doesn't help me much at the moment though.

 

[Telecomlady]

Sorry about your troubles. How long has it been "waiting". Maybe give it a day. I would use another TN.

 

[RS528]

If you don't correct this corruption it will creep through the whole PABX.

If you don't know how to correct DN and TN corruption in the PDT, contact your vendor / distributor.

 

[tekice]

you need to get your vendor to clear the problem or you could reload your switch[last resort]

 

[cmawbey]

TN corruption is caused when the protected & unprotected unit pointers are invalid, or have become missing from the card pointers.
The corrupted TN can be printed as normal in LD 20, but you will not be able to make any changes to it. It can’t be removed in LD 11. You will also get the error “SCH0128” message.
e.g
REQ: “CHG” or “OUT”
TYPE: 2616
TN 4 0 0 6
SCH0128 = Terminal does not exist.
TN ****

Another way to find out if a TN port is stuck in set relocation, Is to do a “STAT” first in LD 32. Use e.g. “STAT 4” etc to list out all the TN’s on the card that port is on.
REQ: STAT 4
00 = UNIT 00 = IDLE (2616)
01 = UNIT 01 = IDLE (2616)
02 = UNIT 02 = IDLE (2616)
03 = UNIT 03 = IDLE (2616)
04 = UNIT 04 = IDLE (2616)
05 = UNIT 05 = UNEQ
06 = UNIT 06 = MSBY (2317)
07 = UNIT 07 = IDLE (2616)
08 = UNIT 08 = IDLE (2616)
09 = UNIT 09 = UNEQ
10 = UNIT 10 = UNEQ
11 = UNIT 11 = UNEQ
12 = UNIT 12 = UNEQ
13 = UNIT 13 = UNEQ
14 = UNIT 14 = UNEQ
15 = UNIT 15 = UNEQ
16 = UNIT 16 = UNEQ
17 = UNIT 17 = UNEQ
18 = UNIT 18 = UNEQ
19 = UNIT 19 = UNEQ
20 = UNIT 20 = UNEQ
21 = UNIT 21 = UNEQ
22 = UNIT 22 = UNEQ
23 = UNIT 23 = UNEQ
24 = UNIT 24 = UNEQ
25 = UNIT 25 = UNEQ
26 = UNIT 26 = UNEQ
27 = UNIT 27 = UNEQ
28 = UNIT 28 = UNEQ
29 = UNIT 29 = UNEQ
30 = UNIT 30 = UNEQ
31 = UNIT 31 = UNEQ
REQ:
This situation tends to happen only on older Option 11 software versions. The cause of this is when a customer picks up the handset on a TN port that has just become spare. The old DN on that TN port was in the process of being moved via TTY programming to a new TN position.
There is a Model set template that exists for the Option 11 software. This will have now become corrupted.
There are a number of ways to resolve this problem, & I’ll start off with the easy & safe method. You will need to be in contact with an Engineer / Customer on site. If they are providing a new extension, It may be possible for them to unlock the TN port.
This is done my using a revised Opt11 “Model” set (Usually 20) for either the M2006, 2008, 2216, 2616 & Orion type phone versions. First of all, I would print out the phones type model set to check if it exists in software.

e.g.
>LD 20
REQ: PRT
TYPE: 2616 M
MODL 20 (You can just key in “Enter” to list out all the model sets for the set type!)
DATE
PAGE
DES

DES MOD20
MODL 020
TYPE 2616
CUST 0
AOM 0
FDN
TGAR 1
LDN NO
NCOS 7
SGRP 0
RNPG 1
SCI 0
SSU 0010
XLST
SCPW
CLS UNR FBD WTA LPR PUA MTD FND HTD ADD HFD
MWA AAD IMD XHD IRD NID OLD VCE DRG1
POD DSX VMD CMSD CCSD SWD LND CNDD
CFTD SFD MRD DDV CNID
ICDD CDMD MCTD CLBD AUTU
GPUA DPUA DNDD CFXA ARHD CLTD ASCD
ABDD CFHD FICD NAID
UDI HBTD AHA DDGA NAMA MIND PRSD NRWD NRCD NROD
EXR0
USRD ULAD OCBD
CPND_LANG ENG
RCO 0
HUNT
PLEV 02
AST
IAPG 0
ITNA NO
DGRP
DNDR 0
KEY 00 SCR
01 SCR (This key needs to be removed!)
02 AO6
03 CFW 4
04 RNP
05 RGA
06 SCC 0100
07
08 TRN
09 RDL 16
10 SSU 0010
11 ADL 16
12 ADL 16
13 ADL 16
14 ADL 16
15 ADL 16
DATE NO DATE

NACT

Some of the later Meridian Option 11c databases will not have any model sets programmed on the system. In that case it’s best to create a new model set 20.
Don’t programme in two SCR / MCR keys etc. Just provide a basic phone with key 0 as SCR. If you find that the model set 20 exists, then check or make key 1 “Null”.
The next thing to do, Is to plug the phone in onto the faulty TN port. If the phone has a display fitted then you may see “20” appear on the right hand side of the terminal screen, when the handset is picked up.
All that needs to be done on site, Is to get the Engineer or Customer to key in ## on the phone & replace the handset. One of two things should then happen.

1) The TN port will become spare & unequipped. (The port can now be used)
2) Or a new digital phone will be shown on the TN. (TN can now be deleted)

Whatever the result is, The TN can be used for programming again.

 

[TAnselm]

I've had this problem before and had to call Nortel. Excellent post Gibblett... you get a star.

 

[jdlrez]

Thanks for the very informative post Gibblett.

Before getting into the stuff you mentioned, here's what I did this morning:

LD 20
STAT 14 9
MSBY

DISU 14 9
ENLU 14 9

STAT 14 9
UNEQ

Now when I PRT TN 14 9 I get the usual SCH0805 which is normal for my PBX when there's nothing programmed on a TN. Before I was getting a set program with type 2317.

So it would APPEAR to be usable again. However, I have another question:

I still need to move an ACD phone to this TN for a new person. Either that or make one up from scratch. Being that ACD sets are apparently so touchy, how should I proceed?

 

[cmawbey]

build a new one..dont chg acd sets

print an existing one then build the new acd make changes as needed

 

[fgibson]

great info Gibblett

 

[jdlrez]

Thanks again all.
One final question: does copying an ACD set (cpy 1) present the same potential damage as moving or chg'ing one? Just for future reference.

 

[LeeMcCauslin]

That's what I am led to believe. Always. Build. New.

I don't even know the technical reasons behind it but I have been sufficiently scared to make sure I always out and build new. My vendor says it. The folks here say it. Little old ladies on the street say it. When it comes to ACD phones: Always. Build. New. I don't even change the CPND name on the scr key of an ACD set. I print the set, out it, and build it new.

 

[jdlrez]

Thanks again, everyone.

 

[acewarlock]

The system will not let you copy an ACD set.

You could move the Crossconnects with out any problems.