The Alarm Inversion Function Is Enabled on the OSN 3500 So That the Main Control Board Is Repeatedly Reset

For some versions of the OSN 3500, the main control board may repeatedly be reset (usually every 12 minutes) in any of the following scenarios:
Scenario 1: The alarm inversion function is enabled on board on the extended subrack of the OSN 3500.
Scenario 2: A physical board on the active subrack of the OSN 3500 is inconsistent with the logical board and the alarm inversion function is enabled on the board. 
 

The main control board is repeatedly reset (usually every 12 minutes) and the alarm information can be queried through the errlog command. 

 Judgment methods:
This problem can be determined by using errlog and dbms-query:"alminv.dbf",drdb commands.
1. If the error log contains the following records, you can determine that the problem is caused by the setting of alarm inversion function:
fatal task errorcode=1, Line 2069 in alm_char.cpp:TA
2. Run the :dbms-query:"alminv.dbf",drdb command. In the following results, "4d" and "57" indicate that scenario 1 exists and
"ff" indicates that scenario 2 exists.
:dbms-query:"alminv.dbf",drdb
                                     ALMINV.DBF                                   
               record num  BID     OPPORT        PATH      ALLOW                  
               1           ff      01            0001      01                     
               2           05      02            0001      01                     
               3           05      03            0001      01                     
               4           05      04            0001      01                     
               5           05      05            0001      01                     
               6           4d      06            0001      01                     
               7           57      07            0001      01 

Urgent solutions:
Solution 1: If the alarm inversion function is enabled on the existing network, disable the function, replace the main control board with a new one (If there are two main control boards on the existing network, you need to remove both of them), and upload configuration data through the T2000.
Solution 2: If the BID of the extended subrack is found in the alarm inversion database when the OSN 3500 runs normally, you need to delete the alarm inversion database to avoid repeated resetting of the OSN3500 after the main control board is reset, and perform the following operations to recover the state.
:dbms-get-autobackup //（1）
:dbms-set-autobackup:disable; // When the query result of (1) is enable, set disable.
:dbms-get-cyclebackup //（2）
:dbms-set-cyclebackup:disable；// When the query result of (2) is enable, set disable.
:dbms-delete:"alminv.dbf",drdb
:dbms-copy-all:drdb,fdb0
:dbms-copy-all:drdb,fdb1
:dbms-query:"alminv.dbf",fdb0
:reset
:dbms-query:"alminv.dbf",drdb
:dbms-set-autobackup:enable; // When the query result of (1) is enable, recover the original state.
:dbms-set-cyclebackup:enable; // When the query result of (2) is enable, recover the original state.
Solution 3: Upgrade the version to the following version that solves the problem:
V version T version
OSPV100R007C03 T15 and later versions
OSPV100R008 B01D and later versions
OSPV100R009 B01D and later versions 
 

This problem is a platform version defect. The platform versions involved include the following:
OSPV100R007C02T18D02 and earlier versions
OSPV100R007C03T13D02 and earlier versions
OSPV100R008B01C and earlier versions
OSPV100R009B01C and earlier versions
A platform version can be queried through the sys-get-ptsoftver command.
Note: This problem exists not only in the OSN 3500, but also in other optical network products that use any of the above-mentioned platforms. 
 

You are recommended not to enable the alarm inversion function on the board in the extended subrack of the OSN 3500. The enabling of the alarm inversion function affects all optical network devices that use the above-mentioned platform versions.