Prim Hírek

A következő évezred első óráiban az informatikai rendszerek ezrei kezdenek el rossz adatokkal dolgozni, ami felbecsülhetetlen károkat okozhat. A tanácsadó vállalatok szerint mindez megelőzhető, feltéve, ha az érintettek összesen 600 milliárd dollárt költenek az átállásra. Az ezredforduló egyik sok gondot okozó globális problémája a számítógépes rendszerek átállásából eredő nyilvántartási nehézség lesz. Néhány éve ugyanis a számítógépes szakemberek egyfolytában súgják, sőt ma már egyre inkább kiabálják, hogy a komputeres programok döntő többsége - főképpen az egyedileg fejlesztett szoftverek sokasága - nem tudja majd megfelelő módon kezelni, amikor 1999-ről 2000-re változik az évszám. Bodoróczki Istvánnal, a Radiant Rt. informatikai igazgatójával és Andrasek Csabával, a Sapiens programfejlesztő mérnökével a 2000-es év problémájáról, illetve annak megoldási lehetőségeiről beszélgettünk.

A takarékosság ára: 600 milliárd dollár

Business Online: - Mióta lehet sejteni, hogy az ezredfordulón komoly gondok lehetnek a szoftverek működésével?

Bodorócki István: - A hardveres szakemberek már a nyolcvanas évek végén jelezték, hogy a régebbi, PC/XT kategóriás számítógépek rendszerideje csak az évszám utolsó két karakterét tartalmazza, amiből komplikációk adódhatnak. A 286-os AT-k már az évszámok mind a négy számjegyét tárolták. Mivel az XT számítógépeket még nagyon sokáig használták, ebből adódóan a szoftverfejlesztők nem állhattak át azonnal az évszám négyjegyű kódjára. Már csak azért sem tehették meg, mivel egy III. generációs fejlesztői környezetben (például COBOL, PL1, Algol) megkezdett korábbi fejlesztésben már nem lehetett megváltoztatni a dátum formátumát.

Andrasek Csaba: - Annak idején alapvető fejlesztési elv volt, hogy az elkészítendő program minél kevesebb "erőforrást" használjon, így a programozók legtöbbször - takarékossági okokból - csak az évszám utolsó két karakterét és természetesen a hónap, nap kódjait építették a forrásprogramba. A takarékosságnak most látjuk a kárát - 2000. január 1-jétől ezek a programok 1900-ként fogják kezelni az adatokat. Az úgynevezett értékkészlet 00 és 99 közötti értéket kaphat, ezt kell átkonvertálni egy "string"-be, amely azonban a későbbiekben már nem változtatható négyjegyűre.

B. I.: - Ma már vannak közismert példák. A telefontársaságok számlázóprogramja az évezred utolsó perceiben megkezdett és az újévbe átnyúló beszélgetéseket úgy érzékelheti, mintha mínusz 99 évig beszéltünk volna, tehát lehet, hogy még ők fognak fizetni nekünk! De vannak igazán komoly veszélyek is: egy gyógyszer-, konzerv- vagy élelmiszerraktárban a szavatossági időt a lejárat és az aktuális dátum különbségéből érzékeli a nyilvántartóprogram, így már most is gondot okozhat, ha egy 1997-ben vásárolt, de 2002-ig fogyasztható konzervet kell vizsgálni. Ez esetben ugyanis a "97-02=95" művelet elvégzése után 95 évig fogyaszthatónak érzékeli a terméket a program. Említhetném a közüzemi díjak elszámolását vagy a bankok kamatszámítását is, de akár egy PC-n futtatott könyvtár- vagy videotéka-nyilvántartást is.

B. O.: - Minden program meg fog zavarodni az ezredfordulón?

B. I.: - A hetvenes és nyolcvanas években fejlesztett programok esetében szinte biztosan baj lesz, az ebben az évtizedben készített szoftverek azonban már nem annyira veszélyeztetettek. Az IBM nagygépeire, a mainframekre (például az AS/400-asokra) készített, főként hazai fejlesztésű szoftverek valószínűleg hibázni fognak. Ráadásul az eltelt idő alatt az adatbázis olyan hatalmas méretűre nőhetett, hogy esetleg több millió dátumkódot tartalmaz, és ez bizony erősen megnehezíti a program javíthatóságát.

A. Cs.: - Vegyünk például egy bankot. A pénzintézetekben alkalmazott programrendszerek úgynevezett kritikus alkalmazások, ezért működésük során az átlagnál lényegesen nagyobb megbízhatóságot kell garantálni. Ezekben a rendszerekben - mint az igényes pénzügyi programokban általában - minden adat mellé odaírják a dátumot is. A kritikus alkalmazások ellenére ez leggyakrabban csak két számjegy formájában történik, az előzőekben már említett erőforrás-takarékossági okok miatt.

Nem lehetünk teljes biztonságban

B. O.: - Létezik egyáltalán olyan vállalat, amely garantáltan védett ezzel a problémával szemben?

A. Cs: - Senki sem érezheti magát teljes biztonságban, az egyedi fejlesztésű programokat futtatók pedig még kevésbe. Ha az alkalmazó cég tulajdonában van a forráskód, akkor jobb a helyzet, de ekkor sem biztos, hogy megtalálja a fejlesztőt. Ha pedig megtalálja, még akkor sem biztos, hogy az említett "string"-ek lecserélhetők, vagy megéri lecserélni azokat. Leggyakrabban azzal a helyzettel találkozunk, hogy a fejlesztő valamilyen programozási nyelvben elkészítette a programot, azt futtathatóvá tette egy fordítóprogrammal, és a megrendelőnek csak egy "exe" vagy "com" állományt adott át - amit azóta is használnak.

B. O.: - Mi a teendő, azaz hogyan állapítható meg, hogy egy rendszer összezavarodik-e két év múlva?

B. I.: - A legjobb megoldás az, ha az alapprogram és az adatbázis biztonságos elmentése után átállítjuk a központi szerver rendszeridejét például 2001-re, és a program futtatásával szimuláljuk, mi is történik majd három év múlva. A baj csak az, hogy azon rendszerek többsége, amelyeknél a 2000-es év valóban komoly gondot okoz, folyamatos üzemben működik. Éles üzemben viszont "életveszélyes" megkísérelni egy ilyen próbát. Ezeknek a cégeknek csak azt tudjuk ajánlani, hogy kölcsönözzenek egy pontosan ugyanolyan szervert, és a programokat az adatbázisokkal együtt másolják át arra. Ezután kezdődhet a kísérlet. Hozzátenném, hogy minden probléma egyedi, tehát csak a saját program és adatbázis együttes értékelése után mondható ki az ítélet. Az biztos, hogy az esetek többségében csak a programot kell majd újraírni, és a régi adatbázis használható lesz, de előfordulhat az is, hogy az adatbázist is újra be kell vinni a rendszerbe. Ez feladatfüggő, ugyanis míg egy videokölcsönző adatbázisánál nem gazdaságos a fejlesztőt megbízni a teljes konvertálással, egyszerűbb és olcsóbb újra begépelni az adatbázis tételeit. Egy nagyobb rendszernél azonban lehet, hogy olcsóbb a teljes újrafejlesztés, hiszen az adatbázis újbóli bevitele akár éveket is igénybe vehet.

B. O.: - Ha már sikerült felfedezni egy rendszerben a hibát, milyen megoldást ajánlanak kijavítására a szakemberek - és egyáltalán, van-e biztos megoldási stratégia?

B. I.: - Mindenekelőtt meg kell vizsgálni, megvan-e az eredeti forráskód, és elérhető-e a fejlesztő cég. Ha nem, akkor a forráskódot vagy a futtatható állományt elemeztetni kell szakértőkkel, akik javaslatot, költségtervet is készítenek a különböző korszerűsítési változatokra. Cégünk, a Radiant Rt. például az izraeli Sapiens rendszert használja a 2000-es probléma megelőzésére. A Sapiens fejlesztette ki azt a megoldást, amely egy vizsgáló szoftver lefuttatásával feltérképezi a helyzetet, egy másik modullal pedig elvégzi a szükséges korrekciókat. Például egy RS6000-es, UNIX-os rendszernél megvizsgálja: okoz-e gondot, ha 00 van az utolsó két karakterben. Ha nincs meg az eredeti forráskód, a FALCON nevű modul a lefordított, futtatható programokból készít egy C nyelvű forráskódot, amely már módosítható, és a javítások elvégezhetők. Mivel egy komolyabb program fejlesztése akár 50-100 évig is eltarthat, a felhasználóknak már nincs sok idejük a megoldásra. Nagyobb rendszerek esetében a még hátralévő két évben akár 50 fejlesztőre is szükség lehet a programozáshoz. Ráadásul figyelembe kell venni, hogy szép lassan nem csak az idő fogy el, hanem a szakemberek is. Ha egy fejlesztő ért a 2000-es év problémájának megoldásához, azt külföldre csábítják, tehát egyre kevesebb lesz itthon az igazán profi szakértő. Biztosak lehetünk benne, az ezredfordulóhoz közeledve egyre nagyobb összegekbe fog kerülni, hogy felkészüljünk a számítógépes "világvégére".

Az Egyesült Államokban a legnagyobb 500 céget rendeletben kötelezték számítástechnikai rendszere felülvizsgálatára. Nálunk nemrégiben egy jó nevű szállodába hívták a legnagyobb iparvállalatok informatikai vezetőit és rendszergazdáit, ahol egy ingyenes előadássorozat keretében ismertették a 2000-es év problémáját a megoldási lehetőségekkel együtt. Erre az eseményre mindössze hatvanan jöttek el. Reméljük, amikor felismerik az érintettek a veszélyt, még nem lesz késő...