主機(jī)外航數(shù)據(jù)處理問題分析及解決

胡 恒，孔 剛，解開顏

（中國(guó)民航信息股份有限公司，北京 100029）

目前國(guó)際民航業(yè)主流使用集中式主機(jī)作為主體IT支持平臺(tái)，其主要是指在相對(duì)封閉的專有網(wǎng)絡(luò)環(huán)境下，大型主機(jī)（mainframe）與傳統(tǒng)開發(fā)語(yǔ)言環(huán)境下的集中式IT平臺(tái)系統(tǒng)，即傳統(tǒng)訂座系統(tǒng)平臺(tái)，目前中國(guó)民航的所有航空公司均使用UNISYS公司的基于OS2200平臺(tái)的USAS系統(tǒng)（unisys standard airline system）。

隨著民航市場(chǎng)的發(fā)展，中航信系統(tǒng)處理的國(guó)內(nèi)國(guó)際航班數(shù)量日趨增多，特別是近年來代碼共享的提出，引入市場(chǎng)方航班（marketing flight）概念，在擴(kuò)大航班銷售渠道，提高航班客座率、方便旅客的同時(shí)，也極大地豐富了航班和航線。由于理論上一個(gè)承運(yùn)航班可對(duì)應(yīng)無(wú)窮多個(gè)市場(chǎng)方航班，城市對(duì)（如紐約到芝加哥）對(duì)應(yīng)的航班數(shù)量急劇增加，航信主機(jī)系統(tǒng)在處理外航航班數(shù)據(jù)時(shí)經(jīng)常出現(xiàn)525和storage full的問題，導(dǎo)致系統(tǒng)不能正確加載及生成正確的航班數(shù)據(jù)，用戶查詢航班時(shí)也不能獲得正確的信息。

文中涉及的主要專業(yè)術(shù)語(yǔ)意義如下：

外航：航班數(shù)據(jù)控制權(quán)不在航信的航空公司；

Host航空公司：航班數(shù)據(jù)在航信的航空公司；

Code share（代碼共享）：航空公司A（承運(yùn)航空公司）允許航空公司B（市場(chǎng)航空公司）銷售由航空公司A運(yùn)營(yíng)的航班上的座位。

1 外航數(shù)據(jù)的兩種形式及原有處理流程

中航信系統(tǒng)內(nèi)的外航數(shù)據(jù)來源分SSM/ASM報(bào)文和SSIM TAPE磁帶2種，具體取決于航信與外航空公司簽訂的協(xié)議而定。

由于報(bào)文與磁帶數(shù)據(jù)在信息量上的巨大差異，處理算法也不同。

外航數(shù)據(jù)和國(guó)內(nèi)航班數(shù)據(jù)綜合，形成了航班查詢和訂座的數(shù)據(jù)來源，如圖1所示。

圖1 用戶查詢結(jié)果與外航數(shù)據(jù)處理之間的關(guān)系圖Fig.1 Relationship of user AV result and other airlines data

1.1 SSM/ASM報(bào)文及原有處理流程

如果某外航與航信系統(tǒng)簽訂了SSM/ASM協(xié)議，則當(dāng)其航班數(shù)據(jù)發(fā)生變化時(shí)，將實(shí)時(shí)發(fā)送SSM/ASM報(bào)文，經(jīng)由SITA轉(zhuǎn)發(fā)到航信系統(tǒng)更新其航班數(shù)據(jù)。

SSM/ASM通常只包含同一航班N個(gè)日期段數(shù)據(jù)，如圖2所示。

圖2 SSM/ASM報(bào)文示例Fig.2 SSM/ASM message sample

SSM/ASM報(bào)文處理時(shí)，系統(tǒng)逐個(gè)讀入當(dāng)前航班/日期段的數(shù)據(jù)后，讀入并更新該航班/日期段對(duì)應(yīng)的inventory、schedule以及routing記錄，如圖3所示。如果該航班/日期段對(duì)應(yīng)的某城市對(duì)的航班計(jì)劃數(shù)據(jù)記錄過大，由于計(jì)算過程中需要分配DBA保存active schedule及staged schedule數(shù)據(jù)，可能DBA不夠分配，導(dǎo)致525錯(cuò)誤發(fā)生；同時(shí)在路由數(shù)據(jù)生成過程中，如果對(duì)應(yīng)城市對(duì)的直飛及聯(lián)程schedule數(shù)據(jù)過多，也可能計(jì)算過程中DBA分配出錯(cuò)，導(dǎo)致525錯(cuò)誤發(fā)生。此時(shí)系統(tǒng)中所有schedule數(shù)據(jù)均不能得到更新，只有在裝載進(jìn)程順利結(jié)束時(shí)，才能更新全部數(shù)據(jù)。

圖3 SSM/ASM報(bào)文處理流程圖Fig.3 SSM/ASM message processing flow chart

1.2 SSIM TAPE磁帶數(shù)據(jù)及原有處理流程

如果某外航與航信簽訂的是航節(jié)可利用協(xié)議，則其航班數(shù)據(jù)更新是通過OAG的SSIM TAPE磁帶。航信定期收到OAG公司的SSIM TAPE數(shù)據(jù)磁帶后將其裝載到系統(tǒng)中，更新所有相關(guān)外航航班數(shù)據(jù)。

OAG公司定期收集全世界所有航空公司的所有航班/日期段數(shù)據(jù)，并按照固定格式生成SSIM TAPE發(fā)送給各家航空公司，數(shù)據(jù)壓縮后大小為幾百兆左右，OAG每周固定向中航信發(fā)送2次SSIM TAPE數(shù)據(jù)，具體數(shù)據(jù)格式如圖4所示。

SSIM TAPE磁帶數(shù)據(jù)處理時(shí)，首先需要逐個(gè)讀入某航班/日期段的磁帶數(shù)據(jù)后，讀入并更新該航段/日期段對(duì)應(yīng)的inventory數(shù)據(jù)，并將其schedule數(shù)據(jù)保存到另一DBA（NW）中；待所有航班/日期段數(shù)據(jù)都讀入完畢后，對(duì)NWBUFF中的航班計(jì)劃數(shù)據(jù)按照城市對(duì)/時(shí)間順序進(jìn)行排序；排序結(jié)束后，生成新的staged schedule數(shù)據(jù)并按照城市對(duì)順序替換掉原來的active schedule數(shù)據(jù)，如圖5所示。

在此過程中，由于針對(duì)所有城市對(duì)的所有航班計(jì)劃數(shù)據(jù)都將同時(shí)放入NWBUFF中保存、計(jì)算并排序，在數(shù)據(jù)量超過某個(gè)限制時(shí)，很容易發(fā)生storage full錯(cuò)誤；同樣在路由數(shù)據(jù)生成過程中，如果對(duì)應(yīng)城市對(duì)的直飛及聯(lián)程航班計(jì)劃數(shù)據(jù)過多，也可能導(dǎo)致525錯(cuò)誤的發(fā)生。

1.3 外航航班數(shù)據(jù)處理時(shí)錯(cuò)誤原因分析

航信系統(tǒng)更新外航航班數(shù)據(jù)時(shí)，主要涉及的數(shù)據(jù)文件有 inventory、schedule及 routing，inventory 數(shù)據(jù)為航班詳細(xì)數(shù)據(jù)[1-2]，一個(gè)inventory記錄對(duì)應(yīng)一個(gè)航班/日期段，記錄了航班號(hào)/日期段/機(jī)型/起飛地/起飛時(shí)間/目的地/到達(dá)時(shí)間/艙位/艙位狀態(tài)等航班信息，如圖6所示。

schedule數(shù)據(jù)為航班計(jì)劃數(shù)據(jù)[3-4]，一個(gè)schedule數(shù)據(jù)記錄了直飛對(duì)應(yīng)城市對(duì)的所有航班/日期段信息。routing數(shù)據(jù)則是在schedule數(shù)據(jù)的基礎(chǔ)上，包含了全部的直飛對(duì)應(yīng)城市對(duì)的所有直飛及聯(lián)程信息，如圖7所示。

inventory數(shù)據(jù)通常來說都較小，最大為3584個(gè)字，但schedule和routing最大可能突破4W個(gè)字。

在更新航班inventory/schedule/routing數(shù)據(jù)時(shí)，主機(jī)系統(tǒng)為了避免并發(fā)沖突，不是直接修改原有的數(shù)據(jù)，而是先將原有的記錄數(shù)據(jù)讀入到內(nèi)存中，稱為Active數(shù)據(jù)，同時(shí)根據(jù)算法生成一個(gè)新的數(shù)據(jù)，稱為Staged數(shù)據(jù)，在commit（提交操作系統(tǒng)執(zhí)行）之后才真正用Staged數(shù)據(jù)替換Active數(shù)據(jù)，在數(shù)據(jù)處理過程中，內(nèi)存中需要至少保留兩份數(shù)據(jù)，實(shí)踐證明當(dāng)某城市對(duì)對(duì)應(yīng)的s航班計(jì)劃數(shù)據(jù)超過4W個(gè)字之后，很容易引起系統(tǒng)storage full錯(cuò)誤。

處理SSM/ASM報(bào)文或SSIM TAPE數(shù)據(jù)時(shí)出525/storage full錯(cuò)誤，意味著在數(shù)據(jù)處理過程中，用于當(dāng)前計(jì)算和存儲(chǔ)中間結(jié)果的DBA不夠用，需要申請(qǐng)更多的DBA空間來保存相關(guān)數(shù)據(jù)及中間結(jié)果，但是此時(shí)擴(kuò)大DBA失敗，說明當(dāng)前系統(tǒng)內(nèi)存里已經(jīng)無(wú)法分配所需大小的連續(xù)空白空間。從原理上來說，只要在程序初始化時(shí)，一次性分配足夠空間的DBA就可解決這個(gè)問題，但UNISYS的內(nèi)存資源有限并且不可擴(kuò)充，隨著航班數(shù)據(jù)量的進(jìn)一步增加，SSIM TAPE或SSM/ASM處理時(shí)需要越來越多的DBA來保存相關(guān)航班數(shù)據(jù)及中間結(jié)果，但DBA不可能無(wú)止境擴(kuò)大，導(dǎo)致了問題和矛盾，必須從根本上解決這一問題，實(shí)際應(yīng)用中我們也證實(shí)了這一點(diǎn)，程序初始化時(shí)擴(kuò)充DBA有時(shí)候可行，但當(dāng)航班計(jì)劃數(shù)據(jù)量繼續(xù)增加到超過此空間容納度時(shí)依然會(huì)出現(xiàn)525/storage full的錯(cuò)誤，不能從根本上解決此問題。

進(jìn)一步分析525/storage full發(fā)生時(shí)的DUMP發(fā)現(xiàn)，航班計(jì)劃/路由數(shù)據(jù)中，市場(chǎng)方航班占了較大比例，特別是來自規(guī)模很小的航空公司的航班計(jì)劃數(shù)據(jù)，以市場(chǎng)方航班為主。在SSIM TAPE磁帶中，大航空公司的數(shù)據(jù)也比較靠前，同時(shí)在用戶查詢航班信息時(shí)，通常只會(huì)查看符合條件的前三頁(yè)航班顯示，即只有前24個(gè)航班信息對(duì)用戶才有效，因此，可以考慮當(dāng)某城市對(duì)對(duì)應(yīng)的航班計(jì)劃數(shù)據(jù)增加到某個(gè)限度之后（如112×32×8=229376個(gè)字，即2388個(gè)航班）就不再增加新的數(shù)據(jù)，避免航班計(jì)劃數(shù)據(jù)量過大。

1.4 報(bào)文與磁帶數(shù)據(jù)處理修改后算法

綜上所述，系統(tǒng)處理SSM/ASM報(bào)文及SSIM TAPE數(shù)據(jù)時(shí)發(fā)生525/storage full問題的原因，在于主機(jī)系統(tǒng)航班數(shù)據(jù)的計(jì)算更新方式以及航班數(shù)據(jù)裝載時(shí)對(duì)schedule數(shù)據(jù)量完全不作控制的算法導(dǎo)致的。

修改數(shù)據(jù)錄入算法為，首先設(shè)定航班計(jì)劃數(shù)據(jù)量上限，一個(gè)航班計(jì)劃數(shù)據(jù)記錄最多只能有2388個(gè)航班/日期段；其次當(dāng) NW DBA排序完成后，staged schedule生成時(shí)，如果數(shù)據(jù)量大于設(shè)置的上限時(shí)，去掉NW DBA尾部的多余數(shù)據(jù)項(xiàng)（即最后讀入的超過限制的數(shù)據(jù)項(xiàng)），以保證生成的staged schedule數(shù)據(jù)量不超過設(shè)置的上限，新算法如圖8所示。

從理論的角度分析，當(dāng)所有城市對(duì)對(duì)應(yīng)的航班計(jì)劃數(shù)據(jù)量都被限制在某個(gè)范圍之內(nèi)時(shí)，系統(tǒng)在保存、排序及計(jì)算時(shí)都不會(huì)無(wú)限制要求擴(kuò)大DBA，降低了525/storage full錯(cuò)誤的發(fā)生率；而且只有當(dāng)某城市對(duì)的航班計(jì)劃數(shù)據(jù)超過限度時(shí)，才會(huì)需要去掉NW DBA中尾端的航班/日期段數(shù)據(jù)，其基本為小航空公司的市場(chǎng)方航班，對(duì)大航空公司基本無(wú)影響，對(duì)外航航班的inventory數(shù)據(jù)無(wú)影響，航班計(jì)劃數(shù)據(jù)也受影響不大，對(duì)訂座用戶基本無(wú)影響，是對(duì)系統(tǒng)處理SSM/ASM報(bào)文及SSIM TAPE磁帶數(shù)據(jù)算法的優(yōu)化，如圖9所示。

1.5 報(bào)文與磁帶數(shù)據(jù)處理算法修改的運(yùn)用

圖8 修改后的SSM/ASM報(bào)文處理流程圖Fig.8 New flow char of SSM/ASM message processing

在航信系統(tǒng)中實(shí)現(xiàn)了上述數(shù)據(jù)錄入算法的修改后，在不增加系統(tǒng)計(jì)算損耗的情況下，明顯減少了系統(tǒng)處理SSM/ASM報(bào)文及SSIM TAPE數(shù)據(jù)時(shí)的525/storage full出錯(cuò)幾率，對(duì)客戶查詢及航空公司的影響可忽略不計(jì)，改善了系統(tǒng)在處理SSM/ASM報(bào)文及SSIM TAPE數(shù)據(jù)時(shí)的運(yùn)行狀況，減輕了系統(tǒng)維護(hù)人員的壓力，取得了良好的效果。

圖9 修改后的SSIM數(shù)據(jù)處理流程圖Fig.9 New flow char of SSIM data processing

[1]OS 2200 Transaction Processing Administration and Operations Reference Manual（78307881）[G].Blue Bell：Unisys Corporation，2010.

[2]OS 1100 Transaction Processing Applications Configuration and Administration Guide（78309978）[G].Blue Bell：Unisys Corporation，2010.

[3]OS 1100 Transaction Processing Applications Programming Guide（78309986）[G].Blue Bell：Unisys Corporation，2010.

[4]OS 2200 Transaction Processing Programming Reference Manual（78307402）[G].Blue Bell：Unisys Corporation，2010.