主机外航数据处理问题分析及解决

2011-11-27解开颜

中国民航大学学报 2011年3期

胡恒，孔刚，解开颜

（中国民航信息股份有限公司，北京 100029）

目前国际民航业主流使用集中式主机作为主体IT支持平台，其主要是指在相对封闭的专有网络环境下，大型主机（mainframe）与传统开发语言环境下的集中式IT平台系统，即传统订座系统平台，目前中国民航的所有航空公司均使用UNISYS公司的基于OS2200平台的USAS系统（unisys standard airline system）。

随着民航市场的发展，中航信系统处理的国内国际航班数量日趋增多，特别是近年来代码共享的提出，引入市场方航班（marketing flight）概念，在扩大航班销售渠道，提高航班客座率、方便旅客的同时，也极大地丰富了航班和航线。由于理论上一个承运航班可对应无穷多个市场方航班，城市对（如纽约到芝加哥）对应的航班数量急剧增加，航信主机系统在处理外航航班数据时经常出现525和storage full的问题，导致系统不能正确加载及生成正确的航班数据，用户查询航班时也不能获得正确的信息。

文中涉及的主要专业术语意义如下：

外航：航班数据控制权不在航信的航空公司；

Host航空公司：航班数据在航信的航空公司；

Code share（代码共享）：航空公司A（承运航空公司）允许航空公司B（市场航空公司）销售由航空公司A运营的航班上的座位。

1 外航数据的两种形式及原有处理流程

中航信系统内的外航数据来源分SSM/ASM报文和SSIM TAPE磁带2种，具体取决于航信与外航空公司签订的协议而定。

由于报文与磁带数据在信息量上的巨大差异，处理算法也不同。

外航数据和国内航班数据综合，形成了航班查询和订座的数据来源，如图1所示。

图1 用户查询结果与外航数据处理之间的关系图Fig.1 Relationship of user AV result and other airlines data

1.1 SSM/ASM报文及原有处理流程

如果某外航与航信系统签订了SSM/ASM协议，则当其航班数据发生变化时，将实时发送SSM/ASM报文，经由SITA转发到航信系统更新其航班数据。

SSM/ASM通常只包含同一航班N个日期段数据，如图2所示。

图2 SSM/ASM报文示例Fig.2 SSM/ASM message sample

SSM/ASM报文处理时，系统逐个读入当前航班/日期段的数据后，读入并更新该航班/日期段对应的inventory、schedule以及routing记录，如图3所示。如果该航班/日期段对应的某城市对的航班计划数据记录过大，由于计算过程中需要分配DBA保存active schedule及staged schedule数据，可能DBA不够分配，导致525错误发生；同时在路由数据生成过程中，如果对应城市对的直飞及联程schedule数据过多，也可能计算过程中DBA分配出错，导致525错误发生。此时系统中所有schedule数据均不能得到更新，只有在装载进程顺利结束时，才能更新全部数据。

图3 SSM/ASM报文处理流程图Fig.3 SSM/ASM message processing flow chart

1.2 SSIM TAPE磁带数据及原有处理流程

如果某外航与航信签订的是航节可利用协议，则其航班数据更新是通过OAG的SSIM TAPE磁带。航信定期收到OAG公司的SSIM TAPE数据磁带后将其装载到系统中，更新所有相关外航航班数据。

OAG公司定期收集全世界所有航空公司的所有航班/日期段数据，并按照固定格式生成SSIM TAPE发送给各家航空公司，数据压缩后大小为几百兆左右，OAG每周固定向中航信发送2次SSIM TAPE数据，具体数据格式如图4所示。

SSIM TAPE磁带数据处理时，首先需要逐个读入某航班/日期段的磁带数据后，读入并更新该航段/日期段对应的inventory数据，并将其schedule数据保存到另一DBA（NW）中；待所有航班/日期段数据都读入完毕后，对NWBUFF中的航班计划数据按照城市对/时间顺序进行排序；排序结束后，生成新的staged schedule数据并按照城市对顺序替换掉原来的active schedule数据，如图5所示。

在此过程中，由于针对所有城市对的所有航班计划数据都将同时放入NWBUFF中保存、计算并排序，在数据量超过某个限制时，很容易发生storage full错误；同样在路由数据生成过程中，如果对应城市对的直飞及联程航班计划数据过多，也可能导致525错误的发生。

1.3 外航航班数据处理时错误原因分析

航信系统更新外航航班数据时，主要涉及的数据文件有 inventory、schedule及 routing，inventory 数据为航班详细数据[1-2]，一个inventory记录对应一个航班/日期段，记录了航班号/日期段/机型/起飞地/起飞时间/目的地/到达时间/舱位/舱位状态等航班信息，如图6所示。

schedule数据为航班计划数据[3-4]，一个schedule数据记录了直飞对应城市对的所有航班/日期段信息。routing数据则是在schedule数据的基础上，包含了全部的直飞对应城市对的所有直飞及联程信息，如图7所示。

inventory数据通常来说都较小，最大为3584个字，但schedule和routing最大可能突破4W个字。

在更新航班inventory/schedule/routing数据时，主机系统为了避免并发冲突，不是直接修改原有的数据，而是先将原有的记录数据读入到内存中，称为Active数据，同时根据算法生成一个新的数据，称为Staged数据，在commit（提交操作系统执行）之后才真正用Staged数据替换Active数据，在数据处理过程中，内存中需要至少保留两份数据，实践证明当某城市对对应的s航班计划数据超过4W个字之后，很容易引起系统storage full错误。

处理SSM/ASM报文或SSIM TAPE数据时出525/storage full错误，意味着在数据处理过程中，用于当前计算和存储中间结果的DBA不够用，需要申请更多的DBA空间来保存相关数据及中间结果，但是此时扩大DBA失败，说明当前系统内存里已经无法分配所需大小的连续空白空间。从原理上来说，只要在程序初始化时，一次性分配足够空间的DBA就可解决这个问题，但UNISYS的内存资源有限并且不可扩充，随着航班数据量的进一步增加，SSIM TAPE或SSM/ASM处理时需要越来越多的DBA来保存相关航班数据及中间结果，但DBA不可能无止境扩大，导致了问题和矛盾，必须从根本上解决这一问题，实际应用中我们也证实了这一点，程序初始化时扩充DBA有时候可行，但当航班计划数据量继续增加到超过此空间容纳度时依然会出现525/storage full的错误，不能从根本上解决此问题。

进一步分析525/storage full发生时的DUMP发现，航班计划/路由数据中，市场方航班占了较大比例，特别是来自规模很小的航空公司的航班计划数据，以市场方航班为主。在SSIM TAPE磁带中，大航空公司的数据也比较靠前，同时在用户查询航班信息时，通常只会查看符合条件的前三页航班显示，即只有前24个航班信息对用户才有效，因此，可以考虑当某城市对对应的航班计划数据增加到某个限度之后（如112×32×8=229376个字，即2388个航班）就不再增加新的数据，避免航班计划数据量过大。

1.4 报文与磁带数据处理修改后算法

综上所述，系统处理SSM/ASM报文及SSIM TAPE数据时发生525/storage full问题的原因，在于主机系统航班数据的计算更新方式以及航班数据装载时对schedule数据量完全不作控制的算法导致的。

修改数据录入算法为，首先设定航班计划数据量上限，一个航班计划数据记录最多只能有2388个航班/日期段；其次当 NW DBA排序完成后，staged schedule生成时，如果数据量大于设置的上限时，去掉NW DBA尾部的多余数据项（即最后读入的超过限制的数据项），以保证生成的staged schedule数据量不超过设置的上限，新算法如图8所示。

从理论的角度分析，当所有城市对对应的航班计划数据量都被限制在某个范围之内时，系统在保存、排序及计算时都不会无限制要求扩大DBA，降低了525/storage full错误的发生率；而且只有当某城市对的航班计划数据超过限度时，才会需要去掉NW DBA中尾端的航班/日期段数据，其基本为小航空公司的市场方航班，对大航空公司基本无影响，对外航航班的inventory数据无影响，航班计划数据也受影响不大，对订座用户基本无影响，是对系统处理SSM/ASM报文及SSIM TAPE磁带数据算法的优化，如图9所示。

1.5 报文与磁带数据处理算法修改的运用

图8 修改后的SSM/ASM报文处理流程图Fig.8 New flow char of SSM/ASM message processing

在航信系统中实现了上述数据录入算法的修改后，在不增加系统计算损耗的情况下，明显减少了系统处理SSM/ASM报文及SSIM TAPE数据时的525/storage full出错几率，对客户查询及航空公司的影响可忽略不计，改善了系统在处理SSM/ASM报文及SSIM TAPE数据时的运行状况，减轻了系统维护人员的压力，取得了良好的效果。