101 資訊民國百年問題的因應與思考

  • 張貼日期:2010/4/28
  • 更新日期:2010/6/25

資訊民國百年問題的因應與思考

壹、前言

人過百歲,我們稱他「人瑞」,是件喜事;一個系統要過民國百年,還真引發一些麻煩。

在資訊應用系統的日期欄位的規劃與設計上,當然是以國人環境因素考量,自然以民國年份顯示。有些較早開發的系統的民國年欄位只設定2位數,一旦到了民國100年,依照程式文數字右靠的慣例,2位數的民國年欄位就呈現「00」;如遇有年份計算公式,譬如民國100年有人剛好申請退休,其退休年資一經計算(00年-70年=-70年),再乘以退休基數,依會計常識,負數的金額代表負債;那麼此人非但領不到退休金,還欠款呢!此即所謂的「資訊民國百年問題」。

貳、釋疑

民國百年問題只發生在資訊系統或一些可能的辦公室軟體(如Word),它不像Y2K(千禧年危機)涉及硬體設計、操作系統OS、程式語言、與業務資訊應用系統,甚至發生於嵌入式設備。當年記憶體技術有限,價格昂貴,為節省記憶體空間的使用,也是採2位數表示,譬如以98取代1998年。

百年問題比千禧年的問題簡單許多,衝擊性亦輕,但卻也不容等閒視之。因為民國百年問題只發生在我國,此之所以個人僅稱之「問題」,不稱「危機」的原因。

記得個人在Y2K的宣導上及「Y2K教戰手冊」,亦曾一併呼籲「在修改Y2K程式的同時,一併處理民國百年3位數,竟其功於一役」;只是,事過境遷,人事更迭,資訊界近來新進青年才俊輩出,或許未逢2000年時Y2K全世界總動員的盛況,在電腦年序可能的問題上沒有特別留意欄位長度的陷阱,這幾年來系統開發設計時或有可能仍習慣性地使用2位數。

民國年欄位資訊最常被利用於資料的儲存(如出生欄位)、計算(如程式中的公式)、顯示(如螢幕)、印表(如証明單、收費單…等),何況政府資訊具有公文書特質,非正確無誤不可。是以,釜底抽薪之計仍然不可輕忽,應作及早因應。

參、因應步驟

資訊技術演進神速,2000年時,應用系統運作平台仍多屬傳統主機型態,使用的程式語言大多集中於COBOL、FORTRAN等,因應方法單純;而今日歷經Client-Server、Web-Base、Web2.0等規劃或設計風潮的演化,使用的軟體語言工具很多,各機關必須針對個別軟體環境分類,搜集所使用的各種軟體語言工具的日期年份的習慣性程式寫法,找出關鍵字詞,彙成關鍵字詞庫,以之當key進行原始碼的搜尋,找出有民國年的欄位,然後修正、測試和取代舊程式。

其步驟列表如下:

步驟 工作內容

一、清查

1.原碼程式檔分2類清查:(1)需編譯為執行檔者、和(2)直譯者

2.按「各資訊系統原始碼清查表」全面清查

二、分類

1.將各資訊系統原始碼依程式語言工具歸類

2.搜集有關民國年的各資訊系統,及該程式語言工具寫法,擬出關鍵字詞(含運算的公式)

3.彙總各資訊系統關鍵字詞成關鍵字詞檔

4.可參考附表一「各程式語言之日期關鍵字詞一覽表」

三、搜尋

1.逐步以一個資訊系統的原碼檔為對象,依關鍵字詞搜尋有無民國年的定義或公式

四、修正

1.執行修正前,務必先作好原始程式碼完整備份及擬妥回復程序;避免修正或測試失敗

2.執行修正與測試的日期宜選在假日;避免失敗而影響正常作業

3.team work狀況下,宜妥善分配team member負責修正之程式 群,避免重覆修正,免除版本控制之問題

4.修正原始程式碼,並應記錄

5.若原碼程式檔非直譯語言,需重新編譯執行檔至原執行檔所在 之目錄夾

五、測試

1.能有測試套系統最好;(與正式套系統分開)就不必在假日為之

2.檢視相關的儲存、計算、顯示、印表…等功能是否無誤

六、正式上線

1.確認測試成功後,上線至正式系統,完成原始程式碼修正作 業

另應用系統中用來儲存資料之資料庫,亦需一併處理民國百年問題,先確認儲存「日期」所採用之資料類型為何,及欄位長度是否足夠,配合擴充欄位長度。

依其資料欄位儲存類型,概述其處理方式列表如下:

資料欄位儲存類型 處理方式

西元年方式  無民國百年問題,不需變動

字元字串  如為日期欄位,原長度為6位,遇民國百年時會遭截斷,需將長度擴充為7位以上。

 如為年度欄位,原長度為2位,同理,需將長度擴充為3位以上。

數值  資料型別設定為int,欄位長度不需擴充。

 因為int值域範圍為-2^31 (-2,147,483,648) 到2^31-1 (2,147,483,647),可以容納7位長度的值。

因應步驟中,常見較繁瑣或困難的問題如下:

(一)搜尋難度:目前尚無搜索工具可用,如何有系統地搜尋,端賴資訊同仁的思考。個人建議仿windows檔案搜尋方式;先設定Source置放之程式目錄夾為尋找範圍,再以keyword一一搜尋;或建議寫一簡單程式,以關鍵字詞檔表列搜尋產出對應的原碼檔名和關鍵字,再從原碼檔名逐檔修正。或如附表二使用UltraEdit搜尋關鍵字詞。

(二)版本落差:現行原始碼已經遺失,或經過了多次修改的維護版本已經沒有記錄了;這是最頭痛的風險。或可由儲存、計算、顯示、印表…等功能逆推回去。

(三)完全委外:本身資訊人員只辦理委外業務,幾乎不接觸程式或內容。建議仿版本落差方式,與業務同仁多加思考可能的民國年出現的資訊作業,與委外廠商確認;或只好再專案委外辦理。此外,與各委外的廠商連繫,瞭解該系統的民國年設計模式,以為奧援。

肆、工作時程規劃原則

從因應步驟中可以體認,因應民國百年問題必須業務與資訊兩個單位協力合作,更需長官支持。個人認為仍應(一)成立團隊,(二)決定清倉重點優先序,(三)成員中最好有熟悉系統、程式和業務者,(四)規劃適當時程,及早因應。

工作時程之規劃,視業務系統之多寡與繁複、業務影響大小等因素,建議時程可按上述因應步驟採日期倒推法規劃。

時程 完成項目

98.01~9806 組成團隊、宣導

98.07~9812 全面清查、搜尋完成

99.01~99.06 改正、測試完成

99.07~99.10 取代完成,應付失漏或突發狀況

伍、結論

基於國情,政府機關提供民眾的資訊係採民國記年,所以民國百年問題只發生在國內,國際資訊業者不會關注這個課題;又政府資訊多少具有公文書特質,必須為民眾所信賴,自然必須正確無誤。

是以,必須由我政府各機關及早正視,及早動員,及早謀求改正為宜。

附件下載