Alcatel Unleashed

tot3nkopf wrote: I am not considering myself a guru

"One man's student, is another man's Guru.."
(unknown author)

Once in a while in idle moments I do put on my walking shoes and go for a tour. There's a lot to learn;-)

Reinier wrote:Hi tot3nkopf!!

Even the guru's are joining in. Nice:-D
Thanks for your input, however this is an OXE in our New Delhi office. No Duplicate CPU in this case.

In regards to the ABC-F project, slow but steady. with a slight detour. I don't want to risk going to far off topic so I'll maill you direct.
(Greets from Amsterdam Reinier)

Ok so we finally got the supplier to do a reboot. But this did not work. I wonder if you guys might have any further suggestions. if not I'm going to put a request to have them further investigate the problem.

Edit: I noticed that in the Translator-numbering plan there are several prefixes with the same value in the information field (all 53).

This forum debated similar issues several times.
cuser . m is your friend. Use it with caution as it can be your enemy, too
Why didn't you asked your supplier to solve the problem instead of doing a reboot?

Try to show us how your translator looks like in that 53 range. We cannot guess...

Late reply but have you tried in mgr, Users, FORCED DELETE ?

Sorry everyone but you are wrong. If the number is present in translator it means it is still defined somewhere. Otherwise either the deletion has not been applied the "remanent memory" in which case a double-bascul or system reboot should solve the issue(which I doubt is the issue at hand here) or there is a database error present on the installation(more likely).

If number is still present in translator, try to find out as what type of number it is defined:
network number
station
routing number

The above are the most likely definition types.

According to this, you should have an idea where to look for it in mgr.

Next, kindly run the following commands:
cdmao
checkdb
checkinitrem

If there are errors other than the entity tables (e.x nulog, numan table errors) then this means there are database errors present.

You can try rebuilding and reindexing the tables by using the following commands(these are safe to run on a live system):

cdmao
fichges force_recover_dico
fichges recover all

Now try deleting the number again. Did it work?

If this does not work, you will need to open a ticket with Alcatel-Lucent for the manual database correction using "cuser".