Dissimilar DNIC set types and Move/Swaps

[MitelInMyBlood]

I'm curious if any SX2K user with a fairly large system has ever seen this anomaly. I have a system w/16 per cabs (expanded pers) w/flex dims for 1600 supersets, MFRD 23 (LW32, U-03.9.9). Frequently when performing a mov/swap between dissimilar DNIC devices, i.e., between a ss4025 and a ss4150, the state command will indicate the incorrect set type on the PLID and the set will be OOS. However, in checking the PLID in the DNI assignment form, the programmed DNI type is correct. To fix it you must toggle the DNI types from one to another and then back to what it should be. Thereafter the state command shows the correct device type and the instrument will then come up. I know that the set "type" does not follow the mov/swap, but the programmed DNI assignment shows to be correct tho the state command says something else. Only by toggling the programmed type are we able to recover. Mitel Product Support professes not to have ever seen this but our TAM has personally witnessed it. Anyone else?

 

[macphoneguy]

If I'm following your Question if to different SS change locations you basically would need to do either one of two "trains of thought" A: set both DNIC to be the same, then do a Move/Swap then change them Back to what they should be, and then change the phone/Label if needed, or B: simply change the cross connects on the respective Sets presuming they both Come out of the same Node.
As the Tech handbook says there are a Number of "variations" of the Move command renumber, Add, it all depend on your particulars, with the Sx2K world much like Nortel and the others (like Microsoft)there is usually more then "one way to skin a Cat" I usually don't have to go through too many "hoops" I just have 4025's 4001, and a few PKM's

 

[MitelInMyBlood]

The issue is the MOV/SWAP command is intermittently broken on the one large machine (1200+ Supersets active) because although the command appears to work and in fact does swap the instruments (extn and key apps), performing the command with dissimiler set types, i.e., ss4025 vs ss4150, the PLID data in the DNIC Assignment programming form does not agree with the results of the "state" command issued against the PLID. Example, the DNIC Assignment form might show PLID 9-2-9-12 programmed as a SS4150 however issuing the state command from the CLI, example ST 9 2 9 12 reports the PLID as having a SS4025 programmed on it. We can dupe it practically at will and the area TAM has even witnessed it.
This is not something that is software load dependent, as the bug has been with us since LW 29.