Az idén szilveszterkor a világgazdaság történetének legnagyobb problémájával kell szembenézni: 2000. január 1-je lesz a fekete szombat. A problémát előre lehet látni, az egyre fenyegetőbb veszélyt nem lehet elkerülni. A probléma pedig a 2000. év problémája, avagy közkeletű rövidítéssel az Y2K, bár némelyek millenniumhibának (millennium bug) is nevezik.
Régebben a programozók csak az utolsó két számjegyet tárolták az évszámokból, azaz 1925 helyett csak a 25-öt. 1999 végéig ezzel nem is lesz baj, de az utána következő 00 a gép értelmezése szerint az 1900-as év lenne. Nem árt elégszer hangsúlyozni: az Y2K-hoz fogható válság még nem volt az emberiség történelmében. Különlegessége, hogy előre tudható, mikor következik be, hogy hatása az egész világra kiterjed, hogy mi az oka és mit lehetne tenni ellene. És az is tudott dolog: ha mindannyian akarnánk, meg lehetne (meg lehetett volna) előzni a bajokat, de ez – többek között sokak késői ébredése és tehetetlensége miatt – már nemigen lehetséges.
A lehetséges hatások
Tegyük fel, hogy a 2000. év következtében egyszerűen leáll a felhasználók számítógéprendszere. Ez ugyan sajnálatos, de kijavítható hiba lenne. Csakhogy az igazi veszély, ha a rendszerek megszakítás nélkül dolgoznak tovább, csak éppen nehezen felderíthető, hibás információkat tartalmaznak. Több évre kiterjedő biztosítási, demográfiai, kötvénypiaci és ellátási-tervezési projektek már ma is különleges eredményeket produkálnak, hiszen valamely 00-ra végződő dátumból kivonva egy kilencvenes évekbeli számot, az eredmény negatív szám lesz.
A baj nagyobb, mint sokan gondolnák. Először is, nemcsak a nagyszámítógépek programjairól van szó. Számtalan helyen használunk beágyazott rendszereket, erőművekben, telefonközpontokban, betörésriasztókban. Gyakoriak a rendszeres karbantartásra felügyelő készülékek is. Amikor az óra elüti ama éjfélt, ezek a készülékek azt hihetik, hogy a legutóbbi karbantartás óta már 99 év telt el, és mivel ez veszedelmesen sok, egyszerűen leállítják a berendezés működését. A következmények méreteiről – saját bevallásuk szerint – még a legavatottabb szakembereknek is csak halvány elképzeléseik lehetnek. Mivel világunkban minden összefügg mindennel, az első hiba további meghibásodásokat okoz majd. Ha a telekommunikációs rendszerek omlanak össze, követi őket a banki szektor. Ha a bankok összeomlanak, óhatatlanul magukkal rántják a nagyvállalatokat és így tovább. Ezernyi téves riasztás közül a rendőrség és a tűzoltóság nem tudja eldönteni, melyik a valódi.
| A legismertebb javítási megoldások |
|---|
| Évszám kiterjesztése: az évszámadatok tárolása négy számjeggyel. Szoftveres évszámkiterjesztés: az évszámadatokat a szoftver négy számjegyen kezeli. Kompatíbilis kereskedelmi szoftvercsomag: a program frissítése vagy lecserélése kompatíbilis változatra. Évszámok bináris tárolása: a két ASCII számjegy helyett kétbájtos (65 536-ig terjedő) évszámok tárolása. Alkalmazások újrafejlesztése: alkalmazások újraírása az alapoktól fogva, a 2000. évvel kapcsolatos – és egyéb, időszerűvé vált – változtatásokat is beleértve. Évszám eltolása: minden évet, mondjuk, 28-cal eltolunk, így 2000 helyett 1972-t kell tárolni. Kézi megoldások: papír, ceruza és zsebszámológép. |
Kezdeti lépések
Miután a vállalatok vezetői mindezt kellőképpen végiggondolták, ne rohanjanak azonnal a cégek számítástechnikai szakembereihez (már ha van ilyen egyáltalán). Gondolkodjanak hideg fejjel! Feltételezzük, hogy még semmit nem tettek a 2000. év ügyében. Ezzel nem lesznek egyedül, hiszen a felmérések szerint az amerikai cégek mintegy negyven, az európai vállatok majd' ötven százaléka ugyanebben a cipőben jár. Pánikra (még) nincs ok: bár nyilvánvaló, hogy nem lesznek képesek minden feladatot időben elvégezni, azért fel lehet készíteni a vállalatot arra, hogy átvészelje a nagymutató átfordulását. Létezik olyan vélemény is, hogy a késlekedőknek van szerencséjük, mivel nem kellett megküzdeniük a hibás javítóeszközökkel és a kezdő tanácsadókkal...
Első és legfontosabb alapelv, hogy a vállalatnak kell átvészelnie az ezredfordulót. Nem annyira fontos például, hogy az informatikai osztály vagy a számítógéprendszer működőképes legyen (nem látják rosszul, valóban ez van leírva), fontosabb, hogy maga a vállalat talpon maradjon. Arra is szükség lehet, hogy a feladatok egy részét – vagy akár egészét – külső erőkre bízzák.
A következő fontos tudnivaló, hogy mindez alkalmasint nem kevés pénzbe kerül majd, bár ebből is lehet spórolni. Sok okos vállalat rátalált olyan egyszerűsítésekre, amelyek alapján a tanácsadók előzetes becslésénél sokkal olcsóbban oldották meg a gondokat.
A második alapelv az időtényező. Ez nem az az időszak, amikor hétről hétre lehetne tologatni a fejlesztési határidőket. Komoly tervezésre, pontos adatokra kell támaszkodni! Lehet, hogy jelentős anyagi és munkaráfordítással sem lehet időre elkészülni. Ezt előre fel kell mérni, és ebben az esetben rögtön az úgynevezett B-terv megvalósítására kell áttérni. Azt mindenképpen el kell kerülni, hogy az előzetesen jónak tartott projekt miatt a B-tervet már előre elvessék, és csak 1999 novemberében derüljön ki, hogy mégsem sikerül időben befejezni a munkát.
Mivel már nincs idő minden alkalmazás megmentésére, el kell dönteni a fontossági sorrendet. Többféle stratégia lehetséges. Jerry Hermes, a Micro Focus Year 2000, a világ egyik legismertebb informatikai tanácsadó szolgálatának igazgatója háromosztatú megközelítést ajánl: haldokló, halott és rövidesen kipusztuló programok. Egy másik módszer inkább arra összpontosít, mit kell megmenteni: rendben van, nem kell törődnünk vele; alighanem vége, nem érdemes küszködni vele; még menthető. Minden felsővezető számára egyértelmű kell hogy legyen: a harmadik kategóriára kell koncentrálni.
A harmadik lehetőség az egyes elemek fontosságát kategorizálja: nem fontos; reménytelen, bár fontos; fontos és megmenthető. Megint csak a harmadik csoporttal kell foglalkozni. Miután rátaláltak a megmentendő kritikus rendszerekre, tervekre is szükség lesz. Ha a belső erők az ilyen tervezésre nem elegendők, külső tervezőhöz lehet és kell folyamodni, de léteznek erre a célra programcsomagok is.
Léteznek Y2K-ügyekben már járatos felhasználói csoportok is; ők az elmúlt egy-két évben sok esettel találkoztak már. Sőt ingyenes szoftverek is léteznek, némelyikkel nem csupán tesztelni lehet, de bizonyos problémák megoldására is alkalmasak. Egyes rendszerekre, köztük bizonyos PC-kre például készültek olyan segédprogramok, amelyek a megfelelő rendszerhívásokat elcsípve a helyes dátumértéket szolgáltatják vissza. Ez persze csak gyors tűzoltási megoldás, amíg ki nem javítják a problémát. Az ilyen megoldások korlátaival is tisztában kell lenni, és ellenőrizni kell, használatuk nem vezet-e további bajokhoz.
Az ehhez szükséges, alapvetően szükséges lépést nevezzük analízisnek vagy felmérésnek. Minden fontos alkalmazást elemezni kell, hogy rátaláljunk az Y2K-val kapcsolatos hivatkozásokra. Ha valaki mástól vásároltak szoftvert, neki esetleg lehet ötlete a kompatibilitásról és a megoldási lehetőségekről. Ebben az esetben a felmérés megtakarítható, és tovább lehet lépni a megoldás keresésében.
Külső vagy belső tesztelés?
A felmérésben is többféle út választható: saját munka vagy külső segítség. A kétféle megoldás között itt is több különbség van. Amerikai szakértők a téma kimerítő elemzése során arra a megállapításra jutottak, hogy – amennyiben létezik aktív informatikai osztály a vállalatnál – a saját munka általában olcsóbb. Másodszor, amennyiben bizalmas adatokról is szó van, a külső segítséget még jobban meg kell fontolni. Ugyanakkor a belső munkatársak, mivel eredetileg nincsenek felkészülve ilyen különleges feladatokra, további kiadásokat felemésztő továbbképzésre szorulhatnak. A külső segítők eddigi tevékenységét feltétlenül meg kell vizsgálni: elégedettek-e a korábbi ügyfeleik!
A tesztelés az egész folyamat legfontosabb eleme. Igyekezni kell az Y2K feltételeit leghívebben modellező környezetben végeztetni a teszteket. Az adott programok jellegétől függően ez lehet az 1999-2000-es átmenet kipróbálása (sértetlen marad-e a dátumok folyamatossága?), vagy a tipikus jellegű és mennyiségű, 2000-re datált adatok használata. A teszteléshez is számos segédprogram bevethető. A dátumszimulátorok például azt hitetik el a géppel, hogy a ténylegestől eltérő napon futnak.
A B-terv
Mit lehet tenni, ha nem képesek időben befejezni az átalakításokat? Vagy ha sikerül, de a hardver mondja fel a szolgálatot 2000 küszöbén? Akkor lép életbe az alternatív B-terv. (Sok helyen ez az a bizonyos üzleti folyamatterv (Business Continuity Plan).
Az egyszerűség kedvéért vegyünk példának egy néhány főt foglalkoztató üzemet! Újra elhelyezhetők a pénzügyesek irodájában a nyugtatömbök, tollak és ceruzák, a papírszalagra nyomtató számológépek. Bármennyire is különösen hangzik, a számítógépes rendszereket a manuális, papír-ceruzás megoldással lehet a legjobban helyettesíteni. Nagyvállalati környezetben részlegenként, osztályonként meg lehet becsülni, hány embert kellene beállítani a számítógép munkájának helyettesítésére (akár újabb műszakok és nem kevés túlórapénz árán is).
Persze a papíron végzett munkához adatokat tartalmazó papír is kell. Az év legutolsó periódusáról meg kell őrizni minden feljegyzést, hogy szükség esetén legyen mivel dolgozni. Ha lehetséges, legyen meg a novemberi és decemberi bérszámfejtés papíron, hogy megközelítőleg el lehessen készíteni a 2000. januárit, ha a szükség úgy hozza. Mindenképpen nyomtatásban legyen meg minden ügyfél és szállító adata, telefonszáma, címe. Dolgozzuk ki a számlázás, ajánlatok, könyvelés, adminisztráció és minden egyéb számítógépes munkafolyamat helyettesítésének lehetőségét, és ha sikeresen átvészelték a nagy éjszakát, senki se utazzon el azonnal hetekre!
Ha például átmeneti megoldásokat használtak, vagy ilyen szoftvereket alkalmaztak, kezdjék el a végleges javítás (évszámkiterjesztés) elvégeztetésének vagy ilyen szoftverek beszerzésének tervezését! Végeztessék el újra a felmérési fázist minden egyes rendszerre, hogy biztosak lehessenek: minden rejtett hibától megszabadultak!
Sokak véleménye lehet az, hogy elég kilátástalan a helyzet. De minden rosszban lehet valami jó. Sok vállalatnak éppen a 2000. év problémája adja meg a végső lökést ahhoz, hogy megtegye az amúgy is szükségessé vált lépéseket: újabb hardver beszerzése, régebbi alkalmazások újakra cserélése, saját fejlesztésű rendszerek kereskedelmi megoldásokra cserélése, a rendszerek minőségének és megbízhatóságának növelése. Ezek a vállalatok bizonyosan előnyt kovácsolnak az eredetileg hátrányos helyzetből. Az Y2K nem is olyan tragikus, mint amilyennek első pillanatban tűnik.
| Ingyenes Y2K szoftverek | |
|---|---|
| Az Unibol veszélyeztetettséget elemző programja System/36-hoz | www.unibol.com |
| IBM FixPak for PC DOS 7.0 | www.software.ibm.com |
| Novell NetWare 3.12 és 4.1 javítókészlet | www.support.novell.com |
| COBOL veszélyeztetettséget elemző szoftver | www.doitnow.com/~commtec/down.html |
| PC-tesztek | www.schoolhs.demon.co.uk/date2000.htm; www.suvive-2000.com/eval.htm |
| PC BIOS-problémák elhárítása | www.RightTime.com/ |