AUD313 errors but cannot find how to OUT TN 6

[pd968042]

I have recently been getting regular AUD313 errors reported and the following are a few examples:

AUD313 00001504 DIAL 00000000 00184C5A 000008CB 00000002

AUD313 000000CC DIAL 00000000 00184C5A 000008CB 00000002

AUD313 0000140E DIAL 00000000 00184C5A 000008CB 00000002

I have read through previous article regarding AUD313 errors and have established that the problem TN is 10 15 from translating the 000008CB of the AUD313 using LD32. I remember I tried to setup a new phone by copying a TN to 10 15 but this failed for some reason however it looks like the TN is still in the system and I want to try and OUT it.

I've used LD11 and the TNs not listed and I've tried using LD50 (OUT and MTRT) but get a SCH5652 error returned.

Can anyone give any other pointers as to how to get rid of this TN as the repeated AUD errors has interefered with our normal remote administration of this switch and I'm having to do everything by the command line which is OK for me but not for others.

Thanks in advance,

Peter

 

[pd968042]

Just to let everyone know, I've just had an opportunity to do an INI of the switch as there's virtually nobody in at the moment and this has resolve the issue. I am not getting any more AUD313 errors reported and I can remotely program the switch again using the OTM GUI.

Many thanks for everyones help with this problem but hope this may help others in the future.

Best wishes for 2008.

Regards,

Peter

 

[Mars1968]

I had the same problem and found a solution.

if you get this error:
AUD313 00001504 DIAL 00000000 00184C5A 000008CB 00000002

just go to
ld 32
conv 08CB (see 000008CB, just use last 4 digits)

a tn will be displayed

then in ld32
enlu tn

problem solved

grtz
Marcel de Jong

 

[x11tech]

Done a bit more digging and found using LD 83 with TNB, shows the problem TN as having a type of 2317 which is certainly not one of our normal types and don't know how that got there but tried OUTing using LD11 and now get a SCH4516 response - M2317 set requires DLT2 package (91).

So getting there but not quite at the moment.

This is typical of the older systems with lower memory (RAM) limits. It's called "corruption." Provided that you've not accidently saved that corruption to disk (usually the EDD will prevent bad data from being written to disk, but not always) a sysload will clear the problem.

If a sysload does not clear the problem, then you will need to seek assistance from Nortel through your Vendor (your vendor may have engineers who are capable of clearing this corruption without Nortel assistance, and if they do, they probably can resolve the problem temporarily for you without an INI. The danger is that once you perform corruption clearing through the PDT interface, it is strongly recommended that you EDD and sysload the system at the earliest opportunity to permit the system to reload the uncorrupted database from disk in to memory. Failure to do this may cause additional problems.)

Segue way, I once corrupted the database on a RLS 21 system (old Opt 11E chassis/ssc) when I was asked to change the AC1 code on the system, only to discover after doing so that they had HOTD keys programmed on all phones in the building. The first digit on all of the HOTD keys was the AC1. Once I deleted the AC1, I could not longer chg/nul the HOTD keys. Corruption. Thankfully, I had not EDD'd after changing the AC1, so I sysloaded the system and then went back and removed all of the HOTD keys before changing the AC1 (then I had to put all of the HOTD keys back on the phones with the new AC1 code preceding all of the numbers... what a nightmare.)

 

[x11tech]

typo, should have said INI not sysload.