方案實施與管理
一般方案
在直接的技術層麵上,解決Y2K問題的中心環節是程序的修改轉換。
首先，2000年問題可能出現在計算機係統的哪些部分？如何辨識？
公元2000年所可能造成的信息係統運作問題主要有兩類，一為硬件係統方麵的錯誤，另一為軟件應用係統方麵以二位數字表示年份所造成的失序問題，以下分別其解決方法加以簡單的介紹。
1.硬件係統錯誤。
在個人電腦方麵，2000年問題主要是因部分廠牌的基本操作係統(BIOS)，僅以二位數存放年份引起。雖然電池電腦鍾儲存係統(CMOS)與DOS操作係統均可顯示公元2000年之後的日期，但CMOS的數據通過有問題的BIOS轉給DOS操作係統時卻無法傳達正確的係統日期。部分操作係統提供的呼叫功能所獲得的二位數或四位數公元年份也可能有誤，有些程序編譯器則無法提供將四位數年份代碼換算成相對數值或是其功能有誤。這類問題需抽換有問題的BIOS晶片或由電腦廠商出麵解決。
在主機方麵，部分操作係統，如UNIX、VAX/VMS等由於以一串數字來表達距離特定日期的相對日數，而不使用公元紀年日期，尚有四十餘年至數千年該數字才會麵臨用完的危機，因此主機在係統方麵的問題並不似個人電腦的情況那麼嚴重。然而各種型主機的類似問題仍應該和廠商接洽，由廠商負責測試，並可以要求免費其更正產品的缺陷。
在嵌入式係統方麵，一些由微處理器控製的儀器及設備(如工廠自動化設備、醫療儀器等)，是否會受2000年影響呢？這基本上要看內部的程序控製是否利用到日期年份而定。一般而言，若是係統沒有使用日期來控製，隻要在跨世紀那晚將係統稍停機分鍾，既可過關，例如微電腦控製的電梯係統。不過還是要與設備製造商確認為準。
2.軟件應用係統錯誤。
這種問題的主要症結在於十年前數據庫係統尚不普遍時，如果要改變資料欄位的長度，不隻牽涉到數據資料檔案，還必須更改程序中相關的數據定義欄位。近年來逐漸普及的數據庫係統則強調“資料獨立”，使得資料欄位長度定義改變時隻需通過簡單的程序修改數據庫定義即可，而不需改動應用程序。不幸的是，“資料獨立”的理想在遇到公元2000年問題時無法完全實現，如果牽涉到需加入年份數值進行運算或進行邏輯判斷時，即使將年份欄位擴充到四位數字，對應的程序所獲得的四位數年份數值經運算後，結果則並不一定與原二位數時相同，因此仍需要逐一清查及修改相關的程序。
解決Y2K問題的最大困難之一是在於找出軟件應用係統中所有的日期引用之處。由於日期引用可能出現在係統的操作、事務、程序、例程庫、數據庫、數據字典、數據定義、數據索引、數據域、數據集、記錄、命令、操作、查詢、屏幕表格和報表中,幾乎無處不在,因此,無論采用手工方式還是自動方式,都很難將其全部標識出來。
標識困難既有技術方麵的原因,也有管理方麵的原因。技術方麵的原因在於無法自動甚至半自動地標識係統中各種方式的日期引用；管理方麵的原因在於許多係統的文檔編寫不規範、不完全、甚至沒有文檔,一些研製人員也已經不在崗位。有些軟件公司自行開發的係統，如果不幸該公司已不存在，問題就更嚴重了。
由於一般電腦公司不易針對客戶業務的特殊性而提出最佳的解決策略，因此多建議使用軟件工具作全麵的搜尋，找出所有與日期相關的程序再逐一檢查。事實上，最佳的策略為先從應用去推理，看哪些部分牽涉到日期，再運用工具去找出需要檢視的部位。這項策略的主要原理在於會取得係統日期的操作必然是線上即時操作(On-LineReal-Time)，多用於對交易時間立即加以記載。如果是未來性質的排程或非線上作業(Batch)的日期如生日等，則該項日期資料必然是以人工進行登錄的，不會受到係統日期的影響，而隻會受到欄位長度的限製。
一般而言，在舊式的電腦係統中，從電腦硬件開始，其日期年份即是使用兩位數來代表年份，如以99代表1999年，而其所執行的操作係統（如DOS）亦是如此，而在這樣一個係統上所執行的工具軟體、編譯程式、及應用程式，通常也都是使用二位數來代表公元年份。所以在解決2000年日期錯亂危機時，上述電腦係統的每一個部份，均需納入考慮之中。以一般的個人電腦係統為例，目前市麵上還有很多利用DBASE或FOXPRO所寫的會計庫存係統，在老舊的PC386、486上執行，不但其PC386、486的BIOS使用兩位數來代表公元年份，而且其開機的操作係統DOS、所使用的DBASE編譯程序、檔案管理工具、INDEX的修護工具及會計庫存係統本身，均是以兩位數來代表年份。在這樣的一個電腦係統中，隻要少考慮了一個環節，到了公元2000年絕對過不了關。也就是說，即使把上述所有的軟件加以改正，符合公元2000年的日期運算規則，而硬件沒換或是基本操作係統沒有更換新版，也是過不了公元2000年這一關的。也許有人想說，那有人這麼笨！事實上這已不是笨不笨的問題，有些使用王安電腦係統或已成為電腦孤兒的企事業單位，正麵臨想換卻沒東西可換的困境。當然了，如果大家使用的電腦係統的軟硬件廠商都還健在，也還都能提供各種軟硬件更新服務的話，那可要謝謝他們沒倒閉，更要祝福他們在公元2000年以前生意興隆，因為他們的存在是我們的幸福。
其次，解決2000年問題有哪些可行方案？
對於計算機2000年問題,可以根據係統的具體情況,采取不同的解決辦法。
1.淘汰所有存在問題的舊係統，重置一套新係統
這適用於整個係統皆已陳舊，無法單獨對其一部分進行更換的係統。好處是實行起來簡單易行，不必因為局限於老係統而大傷腦筋；缺點是費用昂貴，而且更換過程中會影響工作的效率，要重新進行培訓等一係列的技術支持工作。
2.保留老的硬件，更換所有存在2000年問題的軟件
適用於硬件不存在問題，軟件上存在問題且軟件已經陳舊的係統。此時應注意的是新軟件一定要能完整地與舊硬件集成，不能出現不兼容的問題。
3.僅對存在2000年問題的業務係統進行修改，使其適應2000年。
修改僅涉及業務係統軟件中的年份字段，適用於那些剛剛投入使用的係統。研究表明,除了一些小的應用軟件來得及重新開發外,對於大多數係統來說,修改是唯一的辦法。因為從1997年開始的任何大於2000個功能點的程序,按照目前的軟件開發方式都不可能完成重新開發工作。
最後，軟件應用係統的2000年問題有哪些具體的修改方法呢？
一般而言，在解決2000年日期錯亂危機的事項中，工程最浩大的應該是應用程序修改部份。對於與時間及日期無關的小程序而言，是絕對不會受到2000年問題影響的。例如列印九九乘法表的程序，2000年以前印出來的九九乘法表，必定與2000年以後打印出的九九乘法表沒什麼兩樣。但對於複雜龐大，而且使用時間久遠的應用係統而言，光是所使用的軟件開發工具，就可能不隻一種，更不用說程件本身的複雜了。這種龐大的應用係統，一般而言，都與時間及日期有著密不可分的關係，這類係統至少由數萬個程序組成，改起來準會令人欲哭無淚，後悔當初高考誌願沒填對，總之那種感受就是與打電子遊戲不同。對於像這樣龐大的應用係統而言，如何修改應用程式，就是一門很大的學問，如果采取的修改方法錯誤，保證讓人改到2000年都改不完。這可不是危言聳聽的說法，這是很多美國信息業界人士，更改應用程序所得到的慘痛教訓。
目前常用的修改日期的方法有以下幾種：
1.擴增法
擴增法，也即擴大日期的信息域。
產生2000年問題的根本原因是由於使用兩位數來存儲年代信息。因此,顯而易見的辦法，是將所有表示年代的信息域擴大到四位數,同時將那些需要對年代進行計算和比較的信息域擴大。此外,接口界麵部分也要做相應的修改。總的來說,與下麵所介紹的幾種方法相比較,擴大日期的信息域是最徹底、最根本、最明顯的辦法。
盡管擴大日期的信息域是最徹底的解決辦法,現在新開發的程序和係統都采用這種方案,但是,這給工作環境複雜的公司出了一個很大的難題。例如,兩個不同的應用程序從同一數據庫中提取數據,而數據庫中表示年代的數據結構已改為四位數,在這種情況下,這兩個應用程序必須同步進行修改,以適應四位數的年代表示。因此,就需要編寫一個中介程序(或稱橋接程序)來完成兩位數到四位數之間的自動轉換。一旦轉換完成,就立即取消中介程序。整個過程包括編寫轉換程序、測試、取消轉換程序、再測試等步驟。這種方法需要使所有的轉換都同步進行。比較起來,這是資源投入較多、時間和財力花費最大的方法。
2.滑動窗口法
又稱作“70/30”、“80/20”法,或日期重譯法。如“70/30”表示:任何大於70的數字都為20世紀,小於70的數字為21世紀。使用這種辦法不用改動數據,隻需改動源代碼。程序中凡是用年代信息組進行比較計算時,都應將源代碼做相應的改動。例如日期01/01/01和01/01/99,在程序未經修改時,係統將其解釋為01/01/1901和01/01/1999,如果在這種情況下計算利息,那麼,就會計算出多達一千九百九十八年的利息。但在采用日期重譯法的係統中,這兩組數表示的日期，分別為01/01/2001和01/01/1999。
在滑動窗口法中，由於每個程序都是單獨修改,因此,無需使用“造橋”術來解決相互間的協調問題,相對來說,動用和花費的資源較少。其缺點在於,窗口的大小小於100年。另外,每一個帶有日期域的程序都要改動。由於改動量大,測試的範圍也相應增大。但這種方式對用戶接口並無大的影響,可以人為地對報告或屏幕數據進行翻譯。
3.日期操縱法
日期操縱法又稱日期域壓縮法,指在現存的日期信息組中固定加上某一年數。事實上,這種方法相當於把2000年問題推後解決。就其效果來說,對那些電腦係統已經麵臨2000年問題的公司是最好的辦法。例如,日期01/01/99、01/01/00和01/01/01,將其所有的年代數據後麵都加上80,則分別為01/01/79、01/01/80和01/01/81,即將2000年問題推後20年。雖然日期中的年份數據不符合實際,但是,對於基於日期分類和比較的運算仍可進行。
日期操縱法雖有效地使用了日期域現有的存儲,但增加了係統的複雜性,實現也比較困難。首先要確定增加的數目,因為並不是所有的情況加上“80”都合適。此外,該方法也存在同步配合問題,需要運行臨時轉換程序,得出的數據也需要重譯。如讀到01/01/79、01/01/80和01/01/81時應解釋為01/01/1999、01/01/2000和01/01/2001。
4.月份加計法
在計算機程序中，月份通常定為二位數的十進位，其所表示的範圍原先隻是1～12，而實際上，二位十進位數可表示到99，若把公元2000年以後的年份以99儲存，多出來的年份（200X-1999）乘12加到月份去，如此可將2000年的日期錯亂時間往後延長，約（99-12）/12≈7年。這7年多的時間雖不是很多，但對於了解2000年問題的人而言，都很清楚，2000年問題最大的問題其實是在於時間緊迫，而且無法延後，若能將2000年問題，簡單的延後7年，則2000年問題就能輕鬆麵對。而這種2000年的修改方法，與視窗移位法一樣，可以不用更改變數，更不用像擴增法那樣更改資料庫的資料，這種修改法較適合對月份不作Check（檢查）或少做Check的係統，當然日期亦有相同類似的加乘空間。
上述所介紹僅為可供參考的修改方法，采用何種方法較好呢？
一般而言，較小的應用程序，適用擴增法；而對於程序量龐大，且程序關係複雜的應用係統程序的修改，則建議使用視窗移位法。因為對這類型的應用程組的修改，若采用擴增法或壓縮法時，因為需要同時將相關連的變數及數據庫一口氣改完，否則會因為少改了變數或數據庫，造成錯誤資料漫延的無法控製的情況，或不斷死機的結果。例如采用擴增法時，若資料庫已擴增為四位公元年，而其對應存取的程序漏改成四位時，就很可能造成死機或資料Truncate掉的信息錯亂。至於會造成那種情況，會依不同的編譯器（compiler）有不同的處理結果。而任一龐大應用程序係統中，資料相關連是極為複雜的，這種複雜的資料與變數，及變數與變數的關連性影響，會產生變數關連的爆炸現象，我們以下麵的程序作一說明：
A：為一日期年份變數或日期年份資料庫欄位
@：為一日期運算函數或巨集
C=A@B，D=C@E，F=E@G.......則表示B，C，D，E，F，G......均為相關連的變數，若A由二位擴增成四位，則相關連的變數，也需要由兩位擴增為四位，否則就有可能產生錯誤的結果，而這種A關連B、C，再由C關連D、E變數的情形，就像是樹狀的連鎖反應的展開來，其關連變數展開來，往往令程序修改者大吃一驚（當然這種現象是指在大型應用係統上），而由一個日期變數所展開的關連變數，隻要少改了一個，很多不可預期的信息錯亂問題，就可能接踵而來，更何況一個係統通常需要多個日期變數來展開。這也就是很多美國大公司兩三年前采用擴增法，而最近紛紛宣布失敗，放棄擴增法，改而采用視窗移位法的原因。因此建議在沒有足夠的時間及人力時，不要采用擴增法修改應用程序及數據庫。
除了上述比較正規的解決方案外，下麵再介紹一些比較獨特的方法。
操作係統的休克療法
就操作係統而言，直接買一個可支持公元2000年的新版操作統，是最簡單也是最花錢的方法，便宜的操作係統隻需幾百元，而貴的操作係統則是數千萬元一套（如IBMMVS作業係統）。而在操作係統不支持公元2000年時，如果硬要讓你的電腦係統在公元2000年後仍然執行順暢無誤，則需做如下的配合：
1.修改應用程序，把年份00當成2000處理；
2.在1999年12月31日跨2000年1月1日時，讓你的電腦係統休息一下。也就是在1999年12月31日23點59分以前，先Shutdown你的電腦係統等到2000年1月1日0點2分，再重新開啟你的電腦係統，這樣做的原因是因為操作係統內部，有許多的Queue（隊列）與時間有關，在跨世紀的時候，不支持公元2000年的操作係統，內部的Queue一定會發生混亂；而在跨世紀的時候關機，則可避免Queue的混亂。這樣做之所以會過得了關，是因為操作係統運作的生命周期，是從係統開機到係統關機為止，這種生命周期特性，使得我們在2000年1月1日開啟係統後，操作係統中的Queue歸零重建，這樣就不會錯亂。而一般應用係統的生命周期，卻是從鍵入第一筆資料開始到應用係統不用為止，其生命周期無法Reset重新開始。所以在麵對公元2000年問題時，就可利用操作係統的生命周期特性，將它Reset重來，即可免除信息錯亂，也可以省掉更換操作係統的費用。
一石二鳥：平台轉移法
美國北卡羅萊納州交通局發現了一個解決Y2K問題的好辦法。交通局（DOT）正在進行一項先導計劃，將它的一個COBOL應用係統同時轉換到網絡上。被選中的是補助款管理自動化係統（GAAS），是一個在AS/400上操作的係統，主要是將聯邦和州政府的補助款分配到地方的公共運輸係統上。位於Raleigh的州交通局資訊處的JasonMacEntee表示，GAAS將以C++或VisualBasic撰寫，並移植到更符合成本效益的WindowsNT環境。交通局已經在WindowsNT上開發了應用係統，如道路工程設計的顧問作業。開始的想法主要是因為AS/400已使用了10年，而且缺乏內部資源而維護很困難。“我們的GAAS也麵臨了需要尋求新技術的壓力，隻考慮GAAS是不符合經濟效益的。”GAAS將是第一個在Intranet上撰寫的係統，預計明年可以讓上百的公共運輸公司上網申請這項費用，交通局的目標是實現無紙化。這一項計劃分為二個階段：第一階段是將程式碼改寫，並在6月時在新環境上作業；第二階段是將這些程式碼物件化（Object-Oriented）以符合N-tier的需要。N-tier是州政府製定的一項標準以適用所有的作業，N-tier描述可以獨立修改的使用者界麵、數據庫與業務的規則。MacEntee說，交通局應用了Relativity科技公司的RescueWare工具軟體，可以讓交通局在轉換程序碼時，在使用C++或VisualBasic上更有彈性。MacEntee說：“GAAS將符合Y2K規範，而且是在網絡上應用。轉移平台的成本效益相當明顯，你可以節省10倍的時間與10倍的成本，下次一定要親自動手才行。”
最簡單的Y2K解決方案
隨著2000年問題的迫近，一位專家提出了一個獨特而又簡單的解決方案：將資料都打印出來。他建議將易受2000年問題影響而又比較重要的資料，如保險憑證、貸款單據、稅務報表、銀行記錄等以硬拷貝的形式保留起來。保留1999年所有財務往來的書麵記錄，確定其在12月底前的記錄正確無誤。如果信用卡的失效日期是在2000年，則應保留2000年所有的交易單據；電費單據不可遺失；確認個人的保險有無2000年的排除條款；測試錄影機、傳真機等家電用品能否由1999過渡至2000年等等。
（如果想要了解各家軟、硬件產品對公元2000年問題的解決方案，可查詢：
http://www.mitre.org/research/cots/COMPLIANCE_CAT.html）
軟件工具
麵對解決Y2K問題繁重的工作和高額費用,如果不精心挑選得力的軟件工具,以實現對2000年問題的修改,即使最好的解決問題的計劃也有可能失敗。目前,有很多商業軟件工具可以用來幫助解決2000問題,如劃定問題的範圍、找出日期調用的地方、擴展日期域等功能。但是,必須強調指出的是,針對2000年問題的解決,不存在一個萬能的工具。主要工具按功能可以分為以下幾種:
1.清查和分析工具
清查工具又稱日期調用識別工具，是廣義定義的用於跟蹤兩位數字日期調用問題的工具集。可以用不同的方法識別日期的調用,包括用瀏覽器進行基本的文本掃描和大量的代碼檢查。有的工具使用解析技術,以提供有關日期被調用的更加詳細的信息；上下文敏感搜索是基於日期如何在係統中被使用,而不是如何被調用來產生標識；時鍾模擬器用模擬的時鍾日期運行係統；日期查找器根據特定的日期標準在應用程序中搜索；在數據庫中,識別工具可以定位兩位數字的日期域,並識別這些域是如何被交叉引用的。清查工具集適用於係統中所有的程序、模塊、複寫簿、命令、屏幕和報表。其中係統清查工具用於找出需要進行轉換的範圍,並輔助製定相應的解決策略。清查工具又可為兩種:一種是含有基本引擎代碼的分析工具,內置日期域尋找功能；另一種為專門解決2000年問題的公司產品,這些工具用專門區域執行日期運算。
分析工具包括影響分析工具和成本估計分析工具。
影響分析工具是用於幫助企業了解修改的效果,跟蹤程序之間、係統之間的關係,並提供滿足不同抽象級別的分析工具。如模塊級、程序級、子係統級、係統級、企業範圍級等不同規模、不同級別的分析工具。這類工具產生係統各部件之間的交叉調用、程序代碼行的大小、涉及到的總的程序數和必須要進行修改的程序代碼行數等靜態統計信息。某些工具可用於執行程序的維護。有很多分析工具具有圖形界麵,可對受影響的係統部件、數據和邏輯之間的關係進行圖形表示,並增加了標注,有助於程序員進行2000年問題的分析和修改。
成本估計分析工具用於企業預測和管理本機構2000年問題轉換工作所需的成本。該類工具可以依據用戶所提供的計量或成本模型進行成本分析。成本因素包括總的勞動力成本、編譯、測試、校正、再編譯所需的計算機環境和CPU的時間開銷。
2.修改轉換工具
修改轉換工具包括配置管理工具和編輯、調試、代碼生成工具。
配置管理工具用於在2000年軟件轉換修改中引入正式的控製和規則。在整個過程中,負責記錄和監控修改要求,刪除過時的和複製的程序。有些工具可以建立邏輯的和數據的中心存儲區。
編輯、調試、代碼生成工具用於轉換係統中必須處理的2000年日期調用的各方麵。可以使用幾種方法,包括自動域擴展、日期名稱標準化、隱藏信息和四位數字日期壓縮。其它任務包括語法檢查和錯誤調試。
對於選擇修改工具有以下若幹建議：
(1)首先要選擇支持多種語言和平台的工具。這樣,開發者可將從一個開發環境中獲得的知識方便地應用到另一個環境中。工具的自動化程度越高,修改項目的進展也就能越快。據估計,轉換工具的自動化程度可高達30%。
(2)在PC環境中工作。由於許多轉換工具的價格是依據硬件的性能而定價,所以,從經濟的角度考慮,應盡可能地將日期的轉換工作置於PC環境中。其工作效率可以通過使用圖形用戶界麵(GUI)得到提高。這樣做也能減輕某些處理能力已接近飽和的係統的負擔。
(3)應選擇對代碼數量和數據數量影響最小的工具和數據轉換方法。這樣不僅能減少轉換工作需要的時間,還能減少對轉換結果進行測試所需的時間。
(4)要注意避免選擇提供特定解決方案的工具和服務商。如果隻能選擇某一個專用軟件,或者隻能向某個特定的人谘詢有關轉換過程和對應用程序的代碼進行處理等問題,那將是不明智的,沒有人願意將自己陷入到這樣的境地,這對係統的維護將是非常困難的。
(5)選擇有長期使用價值的軟件工具。不要僅僅著眼於對2000年問題的解決,應考慮選擇有長期使用價值的軟件工具。數據貯存庫(Repository)和版本控製係統就是這樣的工具。
(6)對所有進行數據交換的應用程序,應采用同一種技術同時進行處理。這樣不僅能減少冗餘測試,還能減少因使用不同轉換例程而引發的程序錯誤。開發者應盡可能使用已有的日期例程或選擇橋接方法來縮短編程時間。
3.測試工具
在大多數情況下,成功轉換的標準是更新後的係統與老係統可以同樣工作。測試工具用於完成所需證明的確認,以保證新老係統性能一致。包括測試產品的固定程序；確定被轉換的程序在生產環境下如何運行；模擬各種2000年的情況；比較新舊係統的邏輯,以產生測試數據；完成其它任務。
分析家們預計測試工具將是一個很大的發展領域,在今後幾個月內會有大量新麵孔出現,多數公司還沒有走到這一步,其原因是需求還不夠。留心一下工具的測試級別,是單元測試、壓迫式測試還是回歸測試?
4.係統集成（版本管理）工具
當公司完成測試時就需要把修正係統與現有係統集成在一起,這最後一個階段的任務極為艱巨。你看,這時公司有兩套係統:一套是現行係統,一套是2000年版本。其難點在於當公司集成進2000年的變化內容後公司各部門的日常運作係統也相應地應做出調整。即如何讓新舊係統之間通信,這需要搭橋,從而使用工具來實現版本的管理和控製,另外審計跟蹤(Audittrail)和文檔也不可輕視。要選擇一個具有良好魯棒性的版本管理軟件。CA公司的版本管理工具Endevor在這方麵十分有用。
下麵介紹一些解決2000年問題的“非專用工具”及方法,以及它們對解決2000年問題所提供的幫助。
1.數據貯存庫
就其對企業的長期作用而言,數據貯存庫(Repository)對處理2000年問題是非常經濟的。當日期轉換工作結束後,數據貯存庫不僅記錄了轉換中進行的一切工作,而且是非常有價值的維護工具和商業信息處理工具。