论文部分内容阅读
【摘 要】简述在删除路由块不成功的时候如何通过各种途径查找，强调做局数据时一定要遵循操作流程。
【关键词】路由块；删除；局间
进入现代社会，人们对通信的依赖程度越来越高了，而通信企业要在竞争激烈的通信市场站稳脚跟，向人民群众提供更加快捷方便的通信手段，就成了在竞争中的有力武器。作为企业的维护人员，保证设备的正常运行、迅速准确地制作各种数据，就成了企业提高服务质量的有力保证。在日常的维护工作中，我们会碰到各种各样的问题，而有一些问题却是由人为因素造成的，是可以避免的。下面的删除路由块不成功事情，就是一例。
我们局的交换机是贝尔公司的S1240交换机，与我局相连的有一个是农场局，他们的设备是HJD04型交换机，使用TUP方式从我们局进入公网。2003年我们局升级为J型74版后，进行大话务量测试时发现两局间掉话现象十分严重，咨询贝尔工程师，认为是局间信令引起的，建议改为ISUP方式。修改后试运行，掉话现象得以解决，因此正式起用ISUP中继，但是在删除不用的TUP路由时，在删除路由块时却出现不成功报告，从报告可以看出其不成功的原因为此路由块还有字冠在用，可是在删除路由块之前我已经把农场局的字冠移到新的ISUP路由上，并且将DESTACC释放掉。这个TUP电路应该没有字冠了。于是，我用7473命令显示是否还有使用此路由块DESTACC。
从报告中可以看出没有字冠连在此路由块上，还有未知的DESTACC与要删除的路由块相连，也就是说系统出现了两个自相矛盾的报告。在这种情况下必需先找到未知的DESTACC，将其释放，然后才能删去路由块，要得到DESTACC就得使用数据库查找，我们知道DESTACC与RTGBLK存在着一定的关系，即关系R_L_DESTIN中的D_INDEX 对应于关系R_L_DESACC中的D_ACC_RSLT，且关系R_L_DESTIN中的D_ACRES2的值为RTGBLKID的值字节翻转且不加H，而关系R_L_DESACC中的D_DESACC的值即为我们要找的DESTACC 先使用MAC MNEMJST查找出D_ACRES2的值为0028<379:1="R_L_DESTIN",2="D_ACRES2"&0&"0028",NA=H'1234.
DISPLAY-TUPLE SUCCESSFUL
INPUT:
LCEID= H'440 NA= H'1234
D_INDEX= 0040<379:1="R_L_DESACC",2="D_ACC_RSLT"&0&"0040".
DISPLAY-TUPLE SUCCESSFUL
INPUT:
REL= R_L_DESACC
QUALIFY :
"D_ACC_RSLT"& =&"0040"
OUTPUT:
REL= R_L_DESACC RID = 2001
LCEID= H'440 NA= H'1234
D_DESACC= 006C
D_ACC_RSLT = 0019
LAST REPORT 00334
于是我们找到了DESTACC=108（6CH=108T），通过命令发现这个没有连字冠。释放掉后，很顺利的删除路由块L-640。
后查阅当时和农场局开电路的记录，发现DESTACC=108是当时试验用的，当电路正式启用时，又制作了一个新的DESTACC，却没有删除这个试验用的，导致路由块连接的DESACC有两个，所以在删除路由块时出现了上述的麻烦。这样的麻烦完全是当时和农场局开TUP电路时，没有及时清理垃圾数据，将没有使用的DESTACC及时删除，导致日后删除路由块出现删除不成功的困难，为自己的维护工作增加了人为因素的困难，也为及时准确制作数据增加了障碍。如果不能及时完成数据的制作，很有可能不能及时为用户提供及时的服务，给企业的信誉带来损害。所以今后制作数据时，一定吸取这个教训，一定严格按操作规程做，及时清理垃圾数据，杜绝人为造成的障碍，为能更好的完成维护工作打下坚实的基础。
【关键词】路由块；删除；局间
进入现代社会，人们对通信的依赖程度越来越高了，而通信企业要在竞争激烈的通信市场站稳脚跟，向人民群众提供更加快捷方便的通信手段，就成了在竞争中的有力武器。作为企业的维护人员，保证设备的正常运行、迅速准确地制作各种数据，就成了企业提高服务质量的有力保证。在日常的维护工作中，我们会碰到各种各样的问题，而有一些问题却是由人为因素造成的，是可以避免的。下面的删除路由块不成功事情，就是一例。
我们局的交换机是贝尔公司的S1240交换机，与我局相连的有一个是农场局，他们的设备是HJD04型交换机，使用TUP方式从我们局进入公网。2003年我们局升级为J型74版后，进行大话务量测试时发现两局间掉话现象十分严重，咨询贝尔工程师，认为是局间信令引起的，建议改为ISUP方式。修改后试运行，掉话现象得以解决，因此正式起用ISUP中继，但是在删除不用的TUP路由时，在删除路由块时却出现不成功报告，从报告可以看出其不成功的原因为此路由块还有字冠在用，可是在删除路由块之前我已经把农场局的字冠移到新的ISUP路由上，并且将DESTACC释放掉。这个TUP电路应该没有字冠了。于是，我用7473命令显示是否还有使用此路由块DESTACC。
从报告中可以看出没有字冠连在此路由块上，还有未知的DESTACC与要删除的路由块相连，也就是说系统出现了两个自相矛盾的报告。在这种情况下必需先找到未知的DESTACC，将其释放，然后才能删去路由块，要得到DESTACC就得使用数据库查找，我们知道DESTACC与RTGBLK存在着一定的关系，即关系R_L_DESTIN中的D_INDEX 对应于关系R_L_DESACC中的D_ACC_RSLT，且关系R_L_DESTIN中的D_ACRES2的值为RTGBLKID的值字节翻转且不加H，而关系R_L_DESACC中的D_DESACC的值即为我们要找的DESTACC 先使用MAC MNEMJST查找出D_ACRES2的值为0028<379:1="R_L_DESTIN",2="D_ACRES2"&0&"0028",NA=H'1234.
DISPLAY-TUPLE SUCCESSFUL
INPUT:
LCEID= H'440 NA= H'1234
D_INDEX= 0040<379:1="R_L_DESACC",2="D_ACC_RSLT"&0&"0040".
DISPLAY-TUPLE SUCCESSFUL
INPUT:
REL= R_L_DESACC
QUALIFY :
"D_ACC_RSLT"& =&"0040"
OUTPUT:
REL= R_L_DESACC RID = 2001
LCEID= H'440 NA= H'1234
D_DESACC= 006C
D_ACC_RSLT = 0019
LAST REPORT 00334
于是我们找到了DESTACC=108（6CH=108T），通过命令发现这个没有连字冠。释放掉后，很顺利的删除路由块L-640。
后查阅当时和农场局开电路的记录，发现DESTACC=108是当时试验用的，当电路正式启用时，又制作了一个新的DESTACC，却没有删除这个试验用的，导致路由块连接的DESACC有两个，所以在删除路由块时出现了上述的麻烦。这样的麻烦完全是当时和农场局开TUP电路时，没有及时清理垃圾数据，将没有使用的DESTACC及时删除，导致日后删除路由块出现删除不成功的困难，为自己的维护工作增加了人为因素的困难，也为及时准确制作数据增加了障碍。如果不能及时完成数据的制作，很有可能不能及时为用户提供及时的服务，给企业的信誉带来损害。所以今后制作数据时，一定吸取这个教训，一定严格按操作规程做，及时清理垃圾数据，杜绝人为造成的障碍，为能更好的完成维护工作打下坚实的基础。