民航信息領域傳統(tǒng)大型主機操作系統(tǒng)的技術(shù)創(chuàng)新
——以中國航信為例

王宗強，何 寧，王 強，張 勁

（中國民航信息網(wǎng)絡股份有限公司運行中心 北京 101318)

0 引言

以USAS應用系統(tǒng)為基礎的傳統(tǒng)大型主機是中國民航信息網(wǎng)絡股份有限公司（中國航信）運營的民航商務信息系統(tǒng)的核心組成部分，其數(shù)據(jù)庫系統(tǒng)為TIP，主要應用程序類型為HVTIP（用來儲存應用程序的特殊類型數(shù)據(jù)庫）。該系統(tǒng)廣泛應用于斯堪的納維亞航空公司和西班牙國家航空公司等多家航空公司中。

對于中國航信而言，使廣大用戶滿意是一個非常嚴峻的任務[1]，而保障大型主機系統(tǒng)的平穩(wěn)運行則成為保障企業(yè)順利發(fā)展的一個不可缺少的基石，也是提高客戶忠誠度的必要手段。因此，如何更有效、更合理地保障大型主機系統(tǒng)的正常運行，提高系統(tǒng)運行平穩(wěn)度，便成為亟須考慮的問題[2]。

隨著國內(nèi)航空公司在國內(nèi)外市場的高速增長，傳統(tǒng)的每月一次停止對用戶開放后集中更新應用程序（稱之為“停機”）的工作，雖然是在北京時間凌晨執(zhí)行，并且每次僅持續(xù)60 min，但是這時候歐洲是下午四點，而美國則是中午時間，這使得使用中國航信機場旅客離港系統(tǒng)的國內(nèi)航空公司在這段時間必須改用手工處理模式。為了提高客戶滿意度，通過對操作系統(tǒng)應用邏輯的修改，利用應用程序數(shù)據(jù)庫主備快速切換技術(shù)使機場旅客離港系統(tǒng)每次例行維護時間從60 min縮減為20 min。

民航旅客量連續(xù)多年保持兩位數(shù)增幅[3]。由于旅客需求的增加，導致大型主機指令量的增幅遠高于旅客量的增幅。USAS主機廠商設計能力不能滿足指令量高速增長的需求，因此通過分析操作系統(tǒng)代碼找到可以優(yōu)化的環(huán)節(jié)，使用EXTENDED MODE模式讀取大型主機內(nèi)存數(shù)據(jù)庫文件，有效降低了系統(tǒng)的資源消耗。

1 應用程序數(shù)據(jù)庫主備快速切換

1.1 背景

USAS應用系統(tǒng)中的HVTIP應用程序儲存在名為LIBRARY的一系列數(shù)據(jù)庫文件中，LIBRARY創(chuàng)建在磁盤上，并映射到內(nèi)存中。每個業(yè)務系統(tǒng)有9個LIBRARY，稱之為LIBRARY NUMBER，每個應用程序在LIBRARY中對應一個LIBRARY BANK。使用該功能的指令從內(nèi)存中讀取該LIBRARY BANK對應的內(nèi)存空間。例如，某個應用程序的LIBRARY BANK為（2，20)，表示該程序是LIBRARY2的第20個BANK（應用程序）。修改應用程序時，使用COPY命令把該程序拷貝到對應的LIBRARY BANK中，并由操作系統(tǒng)實時同步到內(nèi)存。但是，這種拷貝必須在沒有用戶使用該程序時才能拷貝成功。

如果應用程序修改較少且不影響應用核心程序，則應用程序經(jīng)過編譯、檢測后便直接拷貝到LIBRARY中。但是如果需要修改應用核心程序，或者應用程序修改量較大、不同應用程序之間存在調(diào)用關(guān)系，就需要在停機（停機的定義是停止對用戶開放，而不是停止硬件的運行）后將編譯、檢測過的應用程序拷貝到LIBRARY中。此方式的特點是把應用程序中的各種修改統(tǒng)一編譯，重新生成新的應用程序，經(jīng)檢測無誤后批量拷貝到LIBRARY中替換舊應用程序。整個過程正常結(jié)束后，再允許用戶訪問系統(tǒng)。停機拷貝方式導致系統(tǒng)計劃停機時間長，正常情況為60 min。同時，大批量修改的程序被投產(chǎn)后，一旦發(fā)生問題，很難及時判斷出錯位置，從而延長了故障時間。由于停機時間較長，外部用戶對此存在或多或少的意見；同時沒有應用程序備份機制，一旦投產(chǎn)的程序發(fā)生故障，就必須將原來的應用程序重新拷到LIBRARY中，無法保證生產(chǎn)系統(tǒng)的快速恢復。

為了減少停機時間，并備份現(xiàn)有LIBRARY，提出了應用程序數(shù)據(jù)庫主備快速切換（SWITCH LIBRARY）的技術(shù)解決方案。

1.2 技術(shù)方案

USAS系統(tǒng)中HVTIP應用程序通過CALL或TRANSFER方式互相調(diào)用，這兩種方式的執(zhí)行都是由底層程序SFXLNK來完成。為此，在磁盤上創(chuàng)建數(shù)據(jù)庫表LF（LIBRARY FLAG）并映射到內(nèi)存中，編寫了讀取和修改內(nèi)存數(shù)據(jù)庫表LF內(nèi)容的系統(tǒng)程序。此程序讀取LF數(shù)據(jù)時，從內(nèi)存直接讀取，修改數(shù)據(jù)則是在停機時修改磁盤數(shù)據(jù)庫表并實時同步到內(nèi)存中。SFXLNK在調(diào)用指定的應用程序之前必須從內(nèi)存數(shù)據(jù)庫表LF中判斷所調(diào)用的程序相對應的LIBRARY是否被替換。LF表第1個word（36-bit word）為最近更新時間，第2個word為實施最近更新的用戶，從第4個word開始，每個word對應一個LIBRARY，第4個word對應LIBRARY1，第5個word對應LIBRARY2，依此類推。如果該LIBRARY對應的數(shù)值為0，則使用原來的LIBRARY NUMBER，如果不為0，則SFXLNK把原始LIBRARY NUMBER修改為該數(shù)值。以LIBRARY 2 BANK 20為例，執(zhí)行過程如圖1所示。

根據(jù)上述修改，需要對系統(tǒng)中的LIBRARY做統(tǒng)一規(guī)劃。每個業(yè)務系統(tǒng)建立兩套LIBRARY，一套為投產(chǎn)LIBRARY，另一套為備份LIBRARY。兩套LIBRARY包含的程序框架一致。以航班控制系統(tǒng)為例，LIBRARY1為測試用LIBRARY，其余LIBRARY的程序被整合到LIBRARY2至LIBRARY5，并復制到LIBRARY6至LIBRARY9。然后編寫并修改USAS程序，自動生成應用程序投產(chǎn)程序和回滾程序，同時生成拷貝程序，負責把要投產(chǎn)的應用程序在停機之前全部拷貝到備份LIBRARY中。這樣，原來需要在停機之后做的拷貝工作被移到停機之前做。例如當目前投產(chǎn)LIBRARY為LIBRARY2至LIBRARY5時，就把待投產(chǎn)的應用程序拷貝到備份LIBRARY（LIBRARY6至LIBRARY9）中。在對用戶停止業(yè)務開放后，執(zhí)行應用程序投產(chǎn)程序，通過修改數(shù)據(jù)庫表LF完成投產(chǎn)LIBRARY切換到備份LIBRARY的工作。這時LIBRARY6至LIBRARY9變成了投產(chǎn)LIBRARY，而LIBRARY2至LIBRARY5轉(zhuǎn)變成了備份LIBRARY。當新應用程序投產(chǎn)后，如果出現(xiàn)重大應用程序問題，則立即啟動回滾程序，將應用環(huán)境恢復到投產(chǎn)之前的情況。這時，也只需要很短的時間完成修改數(shù)據(jù)庫表LF的工作。

對于內(nèi)部應用人員除了程序修復之外，不會感覺到系統(tǒng)應用環(huán)境的變化，無須考慮目前使用的是哪套LIBRARY。

1.3 成效

正常情況下，HVTIP應用程序的切換需要2 mins。但是由于應用程序更新還包含非HVTIP應用程序的更新，再加上前置的執(zhí)行停機操作以及完成后恢復對用戶開放的操作時間，機場旅客離港系統(tǒng)的停機時間從原來的60 mins下降為20 min。

2 用EXTENDED MODE模式讀取主機內(nèi)存數(shù)據(jù)庫文件

2.1 背景

TCDBF數(shù)據(jù)庫文件是一種特殊的數(shù)據(jù)庫文件，它被映射在內(nèi)存中，適用于讀多寫少的數(shù)據(jù)庫文件。在對TCDBF數(shù)據(jù)庫文件進行讀操作時，訪問的是內(nèi)存中的鏡像；進行寫操作時，先寫入磁盤然后實時同步到內(nèi)存。該類數(shù)據(jù)庫文件最大為262 143個words，現(xiàn)有的基于BASIC MODE編程模式的USAS程序只能讀取不超過131 071個words的內(nèi)存數(shù)據(jù)庫文件。應用系統(tǒng)調(diào)用標準函數(shù)FC$SSN（系統(tǒng)標準調(diào)用，針對所有數(shù)據(jù)庫文件）讀取TCDBF的方式消耗較多的資源，這是因為FC$SSN針對的是所有類型的數(shù)據(jù)庫文件，很多程序邏輯對于讀取TCDBF是多余的。如果能夠直接訪問內(nèi)存讀取相關(guān)數(shù)據(jù)，則能節(jié)省大量的系統(tǒng)資源，因此需要開發(fā)專用程序替代FC$SSN以便降低這部分資源消耗。廠商給出的解決方案是將整個USAS升級為EXTENDED MODE。這個方案需要對USAS底層做很大改動，存在一定風險性，且在短時間內(nèi)無法完成。經(jīng)過進一步研究，提出了開發(fā)一個專用的EXTENDED MODE程序，由USAS調(diào)用該程序?qū)崿F(xiàn)讀取TCDBF數(shù)據(jù)庫的功能。廠商及其他使用USAS主機的用戶并沒有做過類似的工作，此設計在全世界屬于首創(chuàng)。

2.2 設計

USAS底層程序PRMXDF負責完成所有數(shù)據(jù)庫文件的訪問。修改程序執(zhí)行邏輯（圖2）后，在調(diào)用FC$SSN之前先判斷是否為對數(shù)據(jù)庫的讀操作，如果不是讀操作則繼續(xù)原有的邏輯；如果是讀操作則調(diào)用EXTENDED MODE程序。EXTENDED MODE程序結(jié)束后返回PRMXDF程序。PRMXDF程序判斷返回的狀態(tài)字，狀態(tài)字為真，說明完成了TCDBF的讀操作，可以跳過FC$SSN；狀態(tài)字為假，說明數(shù)據(jù)庫文件不是TCDBF或者提供的參數(shù)有誤，繼續(xù)調(diào)用FC$SSN。EXTENDED MODE程序設計基于下列原理：

（1）EXTENDED MODE程序放在COMMON BANK（USAS主機系統(tǒng)存放程序和數(shù)據(jù)的內(nèi)存空間）中，原因是USAS本身是BASIC MODE，只能訪問COMMON BANK中的EXTENDED MODE程序。

（2）EXTENDED MODE程序代碼部分和配置部分放在不同文件中，聯(lián)編后放在同一個COMMON BANK中，這樣便于維護，既能分別修改又能保證二者同時上線。

（3）EXTENDED MODE程序使用TVA指令判斷TCDBF數(shù)據(jù)庫內(nèi)存鏡像是否存在。這是因為對TCDBF維護時需要將TCDBF轉(zhuǎn)換成普通數(shù)據(jù)庫文件，但這時仍然可以對用戶開放。如果不存在，則返回狀態(tài)字“假”；如果存在，則把本次需要訪問的TCDBF數(shù)據(jù)庫內(nèi)存鏡像的地址儲存到X10寄存器，然后EXTENDED MODE程序從X10寄存器獲取地址，讀取數(shù)據(jù)后存儲到B10寄存器返回USAS底層程序PRMXDF。

2.3 成效

用EXTENDED MODE模式讀取主機內(nèi)存數(shù)據(jù)庫文件技術(shù)有效降低了USAS主機系統(tǒng)對TCDBF數(shù)據(jù)庫的I/O。根據(jù)FC$SSN調(diào)用量統(tǒng)計，4月22日晚間投產(chǎn)后TIP數(shù)據(jù)庫文件訪問量大幅度下降（圖3）。根據(jù)計算，主機應用程序讀取TCDBF數(shù)據(jù)庫的I/O量降低了80%，每個應用指令所有的資源消耗平均從198萬機器指令下降為184.5萬機器指令（Machine Instructions，是CPU能直接識別并執(zhí)行的指令，它的表現(xiàn)形式是二進制編碼），下降比例為7%。由于大型主機按照機器指令數(shù)量收費，因此每年可以節(jié)約數(shù)百萬元人民幣的支出。

該技術(shù)的創(chuàng)新在于充分考慮到與現(xiàn)有USAS應用環(huán)境的整合，通過集成創(chuàng)新將EXTENDED MODE模式編程技術(shù)整合于傳統(tǒng)USAS應用環(huán)境中。在沒有對USAS底層進行大量修改的情況下，實現(xiàn)了BASIC MODE應用程序直接訪問EXTENDED MODE程序，擴展了應用程序訪問內(nèi)存空間大小（從13 1071個words擴展到12*262 143個words）。同時充分考慮到了對內(nèi)部應用人員和外部用戶的透明度，對終端用戶的使用沒有任何影響，不影響研發(fā)人員研發(fā)新項目，不需要任何應用代碼修改。

該技術(shù)在USAS大型主機領域?qū)儆谑讋?chuàng)。它的投產(chǎn)不僅提高了大型主機性能，而且實現(xiàn)了沒有對USAS底層進行大量修改的情況下直接調(diào)用EXTENDED MODE程序的方法，為大型主機系統(tǒng)中的類似應用提供了一個非常好的應用實例。

3 結(jié)語

通過質(zhì)疑操作系統(tǒng)代碼的效率并進行優(yōu)化，提高了中國航信大型主機系統(tǒng)的運行效率。正是在這種創(chuàng)新精神的引導下，USAS大型主機領域開展了多項技術(shù)創(chuàng)新，成為最早實現(xiàn)六臺主機分區(qū)松耦合架構(gòu)的USAS主機系統(tǒng)[4]。在此基礎上，進一步自主研發(fā)實現(xiàn)了通過Linux服務器跨平臺讀取主機數(shù)據(jù)庫數(shù)據(jù)、調(diào)度主機作業(yè)流[5]以及實時監(jiān)控主機性能等多項創(chuàng)新，有效提高了運行維護水平，并創(chuàng)造了良好的經(jīng)濟效益。