從小螞蟻到酷斯拉 ──「抓蟲尖兵」也抓狂

:::

1999 / 4月

文‧李光真 圖‧李淑玲



有人說,千禧蟲危機的最大受惠者將是替眾人打索賠官司的律師;而最大受害者,自然是身負「抓蟲」重任的資訊人了。

「要做好會被累死,做不好則會被打死,」一位抓蟲人如是說。到底,抓蟲人如何殺蟲?什麼是他們真正的困擾?他們的心聲又有誰知道?

為了喚起企業主的高度重視,千禧蟲專家在演講時總是強調,「Y2K絕不只是技術問題!」

沒錯,Y2K不只是技術問題。不過光談技術,就足夠讓全球資訊工作者抓狂了。

「酷斯拉」再現?

理論上來說,Y2K問題,不過就是電腦日期中的年份,必須由現行的兩欄改為四欄,資訊工程師只要將程式碼中的日期符號一個個搜尋出來改正就好了。

話是沒錯,動起手來卻發現不是那麼一回事。在《別被千禧蟲咬死》這本書中,作者弗萊契用「換燈泡」來比喻抓千禧蟲:換一個燈泡誠然不難,然而,擺在眼前的是要將整個社區裡的每盞燈泡都換掉,包括怚芊B六怚芊B一百瓦的;省電燈泡、日光燈、鹵素燈、車頭燈、霓虹燈、手電筒燈、聖誕樹裝飾燈……。這些燈上天入地、位置不明,還有些深鎖空屋,外人不得其門而入,更有的早已燈座朽爛、停產多年……。尤其糟糕的是,所有的工作必須於兩星期內完成,一分鐘都延遲不得!

用燈泡來比喻千禧蟲,其實失之過簡,因為電腦系統網網相連,比單個燈泡複雜何止千百倍,千禧蟲之所以被視為一種「病毒」,也是因為它們具有傳染的特性。

譬如許多國家的稅務部門已普遍接受企業及民眾上網報稅,然而報稅者的電腦未必都符合Y2K標準;一旦有錯誤的日期進入稅務系統,系統要有能力辨識、隔離並作修正,否則讓錯誤日期「混」進來後,不僅應納及滯納稅款等計算會出問題,系統本身也會受到損害。

再說,再怎樣的藝術燈泡,也還有個燈泡的樣子,可是電腦裡的日期表示方法卻可能千奇百怪,逃過搜尋者的法眼。

事實上,儘管在使用者看來,電腦的日期顯示方式似乎大同小異,然而深入程式中會發現,有些日期的順序是日月年(DDMMYY),有些是年月日(YYMMDD),以及各式各樣的三者組合。有些程式為了運算方便,將日期以數字型式代表,譬如8796代表本世紀(一九○○年元旦)以後的第8796天;還有些數字代表從今年初開始推算的第幾天。有些應用軟體配合公司的作業而有不同的日期設計,譬如會計系統可能使用怳T期、每期四周的日曆。最教人啼笑皆非的是,有些工程師會突發奇想,用自己孩子的名字代表孩子出生的那個年份……。

「以前以為是小蟲,現在卻覺得好像有一大群酷斯拉正在暗中潛伏、伺機而出,」中衛發展中心Y2K專案經理姜述尚形容自己的抓蟲感想。

別驚訝,這些酷斯拉可不是世紀末的新種怪獸,其實早在六○年代,它們就曾引起騷動。

誰能不短視?

在六○年代記憶體極其昂貴的時候,不少工程師慣用一個欄位來代表年份,譬如用「五」代表一九六五年,結果要進入七○年代時,大家才紛紛修正改寫。

七○年代的教訓為什麼沒有讓世人警覺?這個疑問如今已成為資訊史上一段不可考的公案。有人推測是因為當時電腦應用不普及、也或許當時的資訊人員覺得自己寫的程式絕不可能「存活」到下世紀,更或許資訊界一直有份樂觀的憧憬,認為「船到橋頭自然直」,到世紀末總會有人神來一筆,將所有的年序問題一筆勾消吧?

遺憾的是,離下一世紀只剩二百多天了,神奇的仙女棒依舊芳蹤杳然,而因循拖延的結果,徒然使得千禧蟲問題層層疊疊、難以解套。

為了抓蟲,每天要看上千行舊程式的凌群電腦市場處總工程師陳建國就半開玩笑地埋怨,有時忍不住邊改邊罵:「哪個蠢蛋,寫這些缺德沒大腦的程式!」

要當心的是,短視心態並不是前人的專利,而現在的「被害者」也可能搖身變成「加害人」。只要檢視眼前東拼西湊、削足適履的各式Y2K解決方案,就知道日後的資訊人還有得苦頭吃呢。

「本來年序的欄位,兩欄不夠,就應該增為四欄。這是最徹底安全的方法,」陳建國指出,只是這種方法必須要將所有程式及歷年堆積如山的資料檔都一併修改,檔案的格式要變更、容量要加大,不僅工程浩大,而且所費不貲,超乎多數企業的能力。因此國外估計,目前採用此法的企業,不會超過百分之二怴C

為了取巧省錢,許多人改採「區間法」:因應個別的業務需要,選取一個基準年份,據此區分為不同的世紀。譬如某家銀行現存的最早開戶記錄是一九五八年,於是以五○年為基準年份,超過五○的,像是五八,就視為一九五八年;小於五○的,像是四八,就視為二○四八年。

「區間法」只修改程式而不必修改資料檔,然而它的業務涵蓋範圍只有一百年;而且在一套大型的應用系統裡,可能不同的程式會需要不同的基準年。再說,隨著時間推移,基準年份說不定還得跟著調前移後。這種「挖東牆補西牆式」的修改法,維護起來徒增困擾,然而卻是眼前最受歡迎的作法。

西元九九九九年時……

還有一種修改方式,則是藉西曆的日期和星期對應每二怳K年將重複一次的特性(例如今年一月一日是星期五,二怳K年後又是如此),將系統倒退二怳K年,重回一九七○年代。等電腦內部按正常方式進行各種計算排序後,又再加上二怳K後才輸出,因此使用的人不會發覺電腦暗藏的「返老還童」把戲。

和「倒退二怳K年」有異曲同工之妙的,則是有人將台灣慣用的民國紀年,以西元年份表示。譬如民國八怳C年,就將電腦主機系統日期設定為一九八七(而非正確的一九九八)。還有人把民國年的計算方式(西元年份-11)改為西元年份+89,譬如一九九九年是99+89=188,而民國年欄位只有兩欄,剛好等於民國八怳K年,這樣可以拖延個怳@年,將迫在眼前的千禧蟲改裝為民國一百年才會發作的「百年蟲」。

令人驚訝的是,電腦年序問題何等重要,為什麼資訊界想不出斧底抽薪的辦法,卻任憑大家各出奇招,但求「矇混」過眼前的難關呢?

這樣的問題,得到的回答只有沈默。然而,「最慘的還不是我們——誰要去管九九九九?!」一位資訊工作者開玩笑說,如果到時候地球依然運轉、科技依然發達,電腦想必更在人類驅動下遍佈火星與外太空。那時面對由千禧蟲升格的「萬年老蟲」,資訊界的徒子徒孫們可不知道要如何咬牙切齒了!

考古工程?

「蟲」的演變有趣,抓蟲尖兵──資訊人的心路歷程也同樣耐人尋味。

用「剝洋蔥──越剝越想流眼淚」來形容抓蟲工作的惠普科技公司顧客服務處軟體支援服務部協理、同時也是惠普Y2K專案負責人的吳增峰表示,這幾年工作下來,讓他對科技的奧秘更加心存敬畏。

「We don't know what we don't know.」(我們不知道我們所不知道的),吳增峰強調,壓力大,正是來自太多的 「unknown」(未知)。

而身為各家客戶寄予重望的資訊設備及服務廠商,每個人都期望他們能夠負起完全責任。可是「軟體問題,是沒辦法百分之百打包票的,」吳增峰坦承,即使每一行程式都看得到、修正好,也沒辦法保證執行結果一定完美無缺。

再說,Y2K危機雖然使得資訊人員炙手可熱,身價暴漲,然而這份工作之枯燥繁瑣,使得高薪都不足以構成吸引力。

「每個工程師都想學新東西,可是Y2K卻是一板一眼做苦工,重新研究早就過時的程式語言(COBOL、FORTRAN等),替前人收拾爛攤子,毫無創新可言,」陳建國指出。

惠群電腦公司董事長傅武雄就表示,許多企業為了Y2K而登門拜託,但他都一律拒絕。

「這種案子只能接到今年年底,我為什麼要做短期生意?為Y2K增聘的人手,到時候難道又要解雇?」傅武雄表示,軟體的潛力無窮、科技進展更是日新月異,如果把時間耗在千禧蟲堆裡,不出兩年就落伍了,誰願意自我犧牲?

而台灣企業對Y2K認知不足、重視不夠,也間接降低了資訊廠商的抓蟲意願。在國外,抓蟲的代價是以「一行程式碼一元美金」來估算的,且這個價碼隨著二千年「大限」逼近而在持續高漲中。可是在國內,「大概只有三分之一的價錢,」冠佳資訊公司協理陳輝龍不諱言,他們目前正想跨海去接美國的案子來做。

報喪的烏鴉?

資訊廠商可以拒絕接案,可是企業內的資訊人員卻毫無選擇,必須投身其中。

裕隆汽車前副總經理林茂寅,去年曾經兼任資訊室主任,因此對箇中甘苦深有體會。由於裕隆為因應Y2K而決定更新整個電腦架構,因此資訊部門可謂人仰馬翻。

「有段日子,每天晚上到了怳@點,大夥就出去吃宵夜,放著程式自己跑。吃完宵夜回來後繼續幹,熬到兩眼發直,才披星戴月回宿舍,」林茂寅笑道,「那時我們常常自嘲,『是啊,我們比別人早下班──我們早上三點就下班了!』」

對企業來說,Y2K既不能創造業績,也無法研發新產品,多數企業主都視之為不得不負擔的累贅,平時少有聞問,但一旦聽到問題還沒解決,卻又難免動怒。在這種氣氛下,「報喜不報憂」,其實是企業內資訊部門的普遍心態。

一家員工規模達到二千人的服務業公司資訊部專員,被指派來聽Y2K演講後大吃一驚,原來千禧蟲如此棘手,而他的公司截至目前還有沒做任何因應動作。然而要不要將聽講內容據實回報呢?

「現在提這些,太遲了吧?」他一臉猶疑地說,「我可不敢當報喪的烏鴉,搞不好還會害(資訊部)老闆被炒魷魚!」

中衛中心經理姜述尚透露,不少公司的資訊人員早已準備在今年六月底前辦理退休,美其名要把握Y2K良機,自己創業,其實是想在大難爆發前藉機開溜。

惠普的系統工程師詹德瀚則說了一個普遍流傳在業界的笑話:有個資訊人員受不了Y2K的壓力,決定辭職跳槽,沒想到問來問去,每家老闆都要他去抓千禧蟲。無處可逃之下,他乾脆找個冷凍櫃把自己凍進去,還把解凍時間設定在西元二千年後。不過這位可憐的資訊人從此再無下文──原來他忘了要先解決冷凍櫃的千禧蟲問題!

請給我們鼓勵

換一個角度,台灣IBM公司大中華地區公元二千年綜合策進處協理林獻仁還是希望同業用積極的心態思考,用使命感來肯定自己的價值。

由於Y2K人手缺乏,IBM正進行招聘。今年過年時,林獻仁就陸續接到一些同業的電話,希望跳槽過來。可是他說,「對不起,我不要你來。你如果離開,你的公司怎麼辦?誰能接手你的工作?」林獻仁在一場演講中,對台下二百多名資訊同業表示,「不管你的老闆多惡劣、多無知,但你要想到公司裡的數百位同事,他們未來的生計可能都得靠你今天的苦工。做Y2K就像跑馬拉松,成也好、敗也罷,你要咬牙跑完它!」

林獻仁的話令人動容。而在抓蟲尖兵們默默付出之際,旁人是否也能不吝於多給些掌聲呢?

p.22

在有關Y2K的演講會場外,常見各家資訊廠商向企業界推銷、解釋自己的Y2K解決方案。(卜華志攝)

p.25

Y2K危險日期一覽表

日期 發病原因

1999/1/1   跨年度計畫開始日;「99」可能代表特殊涵意,導致當機。

1999/4/9   今年第九怳E日,羅馬日誌為9999,「9999」可能代表特殊涵意,導致當機。

1999/9/9   日期表示為9999,「9999」可能代表特殊涵意,導致當機。

1999/12/31  1999最後一天。

2000/1/1   西元二千年第一天。

2000/1/3   西元二千年第一個營業日。

2000/1/10  欄位第一次出現七位數日期。

2000/2/29  西元二千年為潤年。

2000/10/10  欄位第一次出現八位數日期。

2000/12/31  西元二千年最後一天。

2001/1/1   西元2001年第一天。

備註:

*每月月底、每季季末均應注意。

*1999/8/21為 GPS (全球定位系統)計時器歸零日。除非完成修正,否則當日許多GPS接受器日期將歸零為1980/1/5,無法發揮定位功能,飛機船隻可能迷航。

相關文章

近期文章

EN

Y2K-Will the Bug Knock Off the Exterminators?

Laura Li /tr. by David Mayer


Some say that the biggest winners in the looming Year 2000 computer crisis will be the lawyers who profit from the resulting litigation, while the biggest losers will be the computer programmers who are stuck with the task of fixing the millennium bug.

Explains one programmer, "If you try to do the job right, you'll work yourself to death. If you don't do the job right, you'll get fired." How exactly does one go about exterminating the millennium bug? Why is it so difficult? Who really understands the predicament in which these programmers find themselves?

To get top executives and business owners to understand the gravity of the Year 2000 (Y2K) problem, experts often emphasize that it is not just a technical problem.

That is entirely correct. It is not just a technical problem, but the technical aspects alone are enough to drive computer experts crazy.

Godzilla on the loose

It doesn't take a rocket scientist to understand the basic problem. In many computer systems around the world, software has been written to store and manipulate dates using only two digits for the year. Now that we're about to enter a new century, these dates have to be changed to four digits. To solve the problem, we just need to hire computer programmers to find the dates and change them all.

Easier said than done, unfortunately. In Computer Crisis 2000, Michael Fletcher uses the example of changing a light bulb to illustrate the nature of the problem. It is not difficult at all to change a single light bulb, but suppose you were given the task of changing all the light bulbs in your entire community? 10 watts, 60 watts, 100 watts; fluorescent tubes, halogen lamps, auto headlights, neon signs, flashlight bulbs, Christmas lights. . . . There are light bulbs everywhere. You don't even know where they all are. Some are in empty homes that you're not allowed into. Some are old-fashioned bulbs that went out of production years ago. And worst of all, you've only been given two weeks to complete your task, with absolutely no possibility of extending the deadline!

Actually, the light bulb example oversimplifies the Y2K problem. Computers are linked together into networks, and networks are linked to other networks. A light bulb doesn't begin to compare with the complexity of a computer. The reason why some people think of Y2K as a virus is that the problem is capable of spreading from one computer to another.

For example, the tax authorities in many countries now allow taxpayers to file electronic returns, but the people filing their returns may or may not be using Y2K-compliant computers. When a bad date is entered into a tax authority's computer system, the system has to be capable of recognizing, isolating, and correcting the date problem, otherwise the defective date can result in erroneous tax calculations, and the system itself can be damaged.

Furthermore, no matter how fancy a light bulb may be, it's still pretty much the same as other light bulbs. Dates, on the other hand, can be recorded in many different ways in a computer. This makes it more difficult to find where they all are. Some may be overlooked.

For the average user, there is no big difference between the various date formats one typically runs across. When you take a close look at computer programs, however, you will find that in some cases the order is day/month/year (DDMMYY), while in others it is year/month/day (YYMMDD), and there are many other combinations of these three elements. For the sake of convenience, some programs record all dates as simple numbers. The number 8796, for example, might refer in some systems to the 8796th day of the 20th century. In other programs, a number might represent the nth day of the current year. Some application programs have their own peculiar date formats, depending on the needs of the company. There are accounting systems, for example, which divide the year into 13 months, each one four weeks long. And here's one for the "don't-know-whether-to-laugh-or-cry" category: Computer programmers have been known to use their child's name to represent the year in which that child was born!

Says Chiang Shu-shang, a Y2K expert at the Corporate Synergy Development Center, "I used to think the millennium bug was just a tiny problem, but it's starting to look like an entire pride of Godzillas lying in ambush."

Unbeknownst to the general public, these Godzillas have already been around for quite a few years. Back in the 1960s, there was a big controversy within the information technology community about how to deal with these monsters.

Short horizons

Because memory capacity was extremely expensive in the 1960s, many software engineers routinely used a single digit for the year. The number 5, for example, meant 1965. Then everyone had to get busy and change these dates when 1970 rolled around.

So why didn't that experience teach people a lesson? The answer to that question shall forever remain a mystery. Some suggest that it is because computers were not widely used in the 1970s. Perhaps the people who wrote software at that time never imagined their programs would still be running in the next century. It could also be argued, perhaps even more plausibly, that the technicians of that time felt optimistically that the problem would take care of itself in due course, as if some all-powerful being would wave a magic wand and make it go away!

Unfortunately, with just 200+ days remaining until the turn of the century, that magic wand is nowhere in sight. Thanks to our procrastination, the millennium bug has become an extremely serious problem with no easy solution.

Jack Chen, Chief Engineer in the Marketing Division at Syscom Computer Engineering Co., spends his days tracking down and eliminating millennium bugs. Every day he must examine thousands of lines of code. Only half in jest, Chen complains that he sometimes can't help exclaiming in frustration, "What idiot wrote this crap?"

But be careful! Our predecessors are not the only ones who will ever deserve criticism for lack of foresight. We may now be suffering the consequences of their mistakes, but we could well end up victimizing future generations with mistakes of our own. Most of the Y2K solutions being implemented today are nothing but stopgap measures designed to postpone the day of reckoning for a few years. Programmers of the 21st century will continue to be plagued by descendants of the millennium bug.

Explains Jack Chen, "The year shouldn't be recorded with two-digit numbers. You need to expand to four-digit numbers. That would be the most complete solution to the problem." To do that, however, all the year-dates in all programs must be converted to a four-digit format, and then all the year-dates in every single file ever created must be changed over as well. Files have to be changed to a different format, and the revised files require more storage capacity. The cost of these changes is prohibitive for many companies. Analysts abroad have estimated that no more than 20% of all companies have opted for this method so far.

There are a number of quick fixes available that cost less money. One of the most common tricks is known as "windowing," whereby a program's baseline year is used as the dividing line between the two centuries. If you're running a bank that was established in 1958, for example, you might pick 50 as the baseline. Any year-dates greater than 50 are assumed to belong to the 20th century, while any year-dates less than that are assumed to belong to the 21st century. 58 automatically means 1958, while 48 means 2048.

With the windowing method, only programs are altered, while data files are left untouched. This method will only work, however, within a range of 100 years. Furthermore, in a large system, different applications might require different dates as the baseline, and as time goes by it could be necessary to shift baselines forward or backward. The effort of maintaining this sort of makeshift system is a great nuisance, but it has thus far proven to be the most popular means of dealing with Y2K.

What about "Y10K"?

Another quick fix takes advantage of the fact that in the Western calendar, every date in the year falls on the same day of the week in year n as it does in year n +28 (i.e., if January 1st fell on Friday this year, it will fall on Friday again 28 years from now, and every subsequent date all the way through December 31st will also fall on the same day of the week as it did this year). This fact allows programmers to push back the clock 28 years-back to the 1970s! If a computer is programmed to add 28 years before producing any output, the result is all the same to the user, who is blissfully unaware of the hoops the computer has just jumped through.

This practice of turning back the clock 28 years (known in the industry as "decrementing") has a peculiar variant in Taiwan, where the Western calendar exists side-by-side with a date system which takes the first year of the Republic of China (1912) as year 1. In other words, people in Taiwan can refer to the current year as either 1999 or the 88th year of the Republic of China. It is simply a matter of personal preference. Some programmers are dealing with the Y2K problem by programming computers to interpret ROC year-dates as Western year-dates. With this fix, the date field for the current year, for example, reads "88" instead of "99," but the number 88 is interpreted to mean 1999. Voila! The millennium bug won't bother anyone for another 11 years! Others arrive at the same result by taking the last two digits of the Western year-date, adding 89, and subtracting 100, i.e., 99 + 89 = 188 - 100 = 88. Once again, this keeps the millennium bug at bay for 11 more years.

If the gravity of Y2K is so clearly understood, why is it that most companies choose these band-aid solutions instead of going for a permanent fix?

You can ask this question until you're blue in the face, but you'll never get an answer. One systems expert even jokes, "If you think we've got a problem now, wait until the year 9999!" If human civilization is still in existence by then and technology has continued to advance all that time, the chances are that computers will be humming away on Mars and points more distant still. Imagine the frustration of our descendants in the far-flung reaches of space as they grapple with the "Y10K" fiasco!

The engineer as archeologist

The "bug catchers" that we depend on to get us through this crisis have got a tough row to hoe.

Wu Tseng-feng, Business Manager for Software Sales and Support at Hewlett-Packard Taiwan, compares the task of "bug busting" to peeling an onion-the more layers you peel away, the more you want to cry. Wu, the Y2K point man for HP Taiwan, confides that the problem has given him an entirely new appreciation for the mysteries confronted by science.

Wu emphasizes, "We don't know what we don't know." We are under pressure because there are so many unknowns.

Customers are counting heavily on providers of services, software, and hardware to guarantee safe passage come January 1st, but Wu warns, "You simply can't give a 100% guarantee for software." Even if you examine every line of code and correct every problem you find, you still can't be sure that a particular program will function properly.

Even though the Y2K crisis has created intense demand for programmers and sent wages skyrocketing, the work is so tedious that many do not consider the money sufficient compensation.

Jack Chen explains, "Every software engineer wants to be working at the bleeding edge, but tracking down Y2K problems is nothing more than a boring check of line after line of code written in out-of-date programming languages such as COBOL and FORTRAN."

James Fu, chairman of Hytec Systems and Consultants Co., reports that his company refuses all of the frequent requests it receives to help companies deal with Y2K.

"The Y2K market is going to disappear on January 1st. Why should I be concentrating on a short-term market like that? And what about all the extra people I'd have to hire? Do I really want to turn right around and fire them?" Fu points out that advances in the software industry occur at a dizzying pace, and if he poured his resources into Y2K, his competitors would leave him in the dust in less than two years. Who wants to make that kind of sacrifice?

Another factor that makes Taiwanese information services firms reluctant to handle Y2K business is the fact that people here are not sufficiently aware of, or concerned about, the millennium bug. It is generally accepted overseas that cleaning up the Y2K problem costs about US$1 per line of code, and that this price will climb as the millennium approaches. According to H.L. Chen, deputy assistant general manager at Computer and Communication Integrated System Inc., "You can only charge about one-third that price in Taiwan." He reports that his company is preparing to seek Y2K business in the United States.

Bearing bad tidings

Information services firms can refuse any job they're not interested in, but in-house programmers have no choice but to tackle the problem.

David Lin, a former Executive Vice President of Yulon Motor Company, spent last year acting concurrently as the director of the company's Information Center. As such, he is keenly aware of the arduous task these programmers face. Yulon decided to respond to the Y2K problem by overhauling its entire computer system. The task is placing a heavy load upon the shoulders of the programmers.

"For a while, we would all take a break every evening at 11:00 for a late-night bowl of noodles or something, then we'd come back and keep at it until we couldn't keep our eyes open any longer. Then we'd stagger back to the company dorm to go to sleep. Our favorite piece of black humor was to say, 'Yeah, we get off work earlier than anybody-3:00 in the morning.'"

Because Y2K measures cost a lot of money without contributing to the development of new products, top executives and company owners tend to look at them as an unwanted burden. They seldom take a close look at the state of their companies' Y2K efforts, but when they do find out that the problem has not yet been solved, they generally get quite angry. In this type of atmosphere, there is an almost universal tendency to avoid delivering unpleasant news to one's superiors.

A programmer at a 2000-employee company in the service sector was sent by his company to listen to a speech on the Y2K issue, and he was shocked at what he learned. His company had done nothing to address its Y2K problem. He found himself in a dilemma about whether he ought to give an honest report on what he had learned.

"It's too late to do anything about it," he thought to himself, "and besides, I don't dare be the one to deliver the bad news, because it might get my boss fired."

Says Chiang Shu-shang of the Corporate Synergy Development Center, programmers at a lot of companies are planning to retire before the end of June. They put a brave face on it, saying that they're going to use the Y2K problem as an opportunity to go into business for themselves, when in reality they're just abandoning ship before the Y2K time bomb blows up in everyone's face.

James Chan, a systems engineer at Hewlett-Packard Taiwan, recounts a joke that has been making the rounds within information technology circles: A programmer could no longer take the pressure of his Y2K work, so he decided to look for a job with some other company. Every company he interviewed, however, wanted to hire him to work on their Y2K problem. With no escape route available, he opted for cryopreservation. Before climbing into the freezer, he set the timer to have himself thawed out after the turn of the century. Unfortunately, no one ever heard from him again, because he forgot to fix the millennium bug in the microchip that controlled his freezer!

Encouragement needed

Austin Lin, who is in charge of the Y2K effort at IBM Taiwan, takes a different attitude toward the situation. In his view, programmers ought to take a more positive view of their work and approach it with a sense of mission.

IBM Taiwan is now hiring new employees to tackle the company's Y2K problem. During the recent lunar new year holidays Lin received a lot of calls from colleagues interested in leaving their current jobs to work at IBM, but he told them all, "I'm sorry, but I don't want you at IBM. What would your company do without you? Who would take over your responsibilities?" In a speech to more than 200 of his colleagues, Lin said, "No matter how much you hate your boss, and no matter how ignorant your boss is, you have to think about your hundreds of co-workers. Their livelihood depends on the hard work that you are putting in. Working on Y2K is like running a marathon. Regardless of whether you win or lose, you've got to keep going to the end."

Austin Lin's words have proved a great inspiration to many. Maybe it would be a good idea if all of us gave a little more recognition to these unsung heroes.

p.22

Outside the sites of Y2K-related lectures, information companies peddle their own solutions to the Y2K problem. (photo by Pu Hua-chih)

p.25

A Y2K Threat Calendar

Date Reason for potential malfunctions

1999/1/1 The transitional year begins; "99" could be a special code in a chip, leading to problems.

1999/4/9 The 99th day of the year, which may appear as 9999; this could be a special code, leading to problems.

1999/9/9 Calendar date 99.9.9; again, if this is a code with some particular meaning in a given chip, problems could result.

1999/12/31 Last day of 1999.

2000/1/1 First day of 2000.

2000/1/3 First business day of 2000.

2000/1/10 First appearance of seven-digit dates.

2000/2/29 Extra day; 2000 is a leap year.

2000/10/10 First appearance of eight-digit dates.

2000/12/31 Last day of 2000.

2001/1/1 First day of 2001.

Notes:

* Pay special attention on the last day of each month and each quarter.

* 1999/8/21: Global Positioning System timers reset to zero. Unless adjusted, many GPS receivers will automatically reset to 1980/1/5, and cease to function; this could, for example, cause planes to go off course.

X 使用【台灣光華雜誌】APP!
更快速更方便!