Budapest, 1999. február 1.

Teendők a 2000 év kapcsán
Telbisz Ferenc

Bevezetés

A 2000 év problémájával foglalkozó írások általában elsősorban
menedzsment szempontból vizsgálják a kérdést: milyen bizottságokat
kell létrehozni, milyen felelősöket kell megbízni, hogyan és milyen
garanciákat kell kérni, ismeretterjesztés, oktatások, képzések
szervezése, stb. Jelen leírásban elsősorban konkrét tennivalókról,
lehetőségekről szeretnénk szót ejteni. Jelen írás nem részletes
útmutató, csupán jegyzékszerűen (checklist) igyekszik felsorolni a
teendőket, ellenőrzési és döntési pontokat és a lehetséges
döntéseket.

A 2000 év problémája

A 2000 év problémája elsősorban a régi, több évtizeddel ezelőtti
programozási gyakorlatból ered, amikor a tárolási igény csökkentése
és az adatrögzítés egyszerűsítése érdekében az éveket a két utolsó
számjegyükkel tárolták és rögzítették. Ilyen tárolási mód mellett pl.
1900 és 2000 nem különböztethető meg. A 2000 évvel kapcsolatos
problémának három eleme van:

A két byte-os évszám tárolás.

A szökőév számítása. A 4-el osztható évek szökőévek, kivéve a százas
évszámokat, amelyek közül csak a 400-al oszthatók szökőévek.
Speciális jelentésű évszámok lehetnek a programokban, adattárolásban,
ez régebben meglehetősen kiterjedt gyakorlat volt. (Ezen dátumok egy
része már valóságos dátummá vált azóta.) Pl. a 99/9/9 dátum egyes
programokban azt jelentette, hogy ezt az állományt örökre meg kell
őrizni, más programoknál azt, hogy 30 nap után automatikusan törölni
kell. A régebbi (IBM) gyakorlat szerint az örökre megőrzendő adatok
megőrzési időpontja 1999, dec. 31. volt, ami 2000-ben már mégis csak
lejár. A 2000 év konformitás azt jelenti, hogy sem a teljesítményt
sem a funkcionalitást nem befolyásolhatja az, hogy 2000-ben, 2000
előtt vagy után vagyunk. (Brit Szabványügyi Hivatal definíciója)
Konkrétan: Egyetlen dátum sem okozhatja a programfutás megszakadását.
A dátumfüggő funkcionalitásoknak konzisztens módon kell viselkedniük
2000 előtt, alatt és után. Minden interfészen és adattárolóban az
évszázad minden adatnál egyértelműen meghatározott legyen vagy
explicit módon, vagy egyértelmű algoritmussal ill. implikációval. A
2000 év szökőévként legyen kezelve.

Hol vannak veszélyek?

Operációs rendszerek és egyéb rendszerprogramok (fordító programok,
adatbáziskezelők, stb.). Különös súlyuk van, mivel széles körben
használtak. Alkalmazási programok. Minél régebbiek, annál nagyobb az
esélye a probléma fennállásának. Számítógépek. Lehetnek általános
célú gépek, vagy speciális célgépek, pl. útvonalválasztók (router),
stb. Beágyazott rendszerek. Technikai, orvosi és egyéb
mérőeszközökben, nyomtató és Fax berendezésekben, járművekben,
háztartási eszközökben, biztonsági rendszerekben, stb mindenütt
lehetnek - és az újabbakban vannak is - processzorok, amelyek évszám
függő adatokat is tárolhatnak vagy használhatnak.

Mit lehet tenni?

Operációs rendszerek és rendszerprogramok.

A gyártókra rá lehet kérdezni, hogy mely változatokra, mit állítanak
a 2000 év kompatibilitásról. Amit garantálnak, célszerű elfogadni.

Amit nem garantálnak, esetleg lehet tesztelni. Tesztelés előtt a
teljes rendszerállapotot el kell menteni, hogy adatvesztés ne legyen.
Közzétenni a gyártók válaszait.

A szervezeteknek fel kell mérni, hogy milyen általános célú szoftver
van a használatukban.

Amit garantáltak, el lehet fogadni.
Amit nem garantáltak, el kell dönteni, hogy mit tesznek vele:
tesztelik a rendszerszoftvert
lecserélik az új, garantált változatra.

Alkalmazási programok

Meg kell vizsgálni a specifikációt, programleírást, adatleírást,
adatbázis struktúrát (ha van ilyen). Ha ezen vizsgálat, specifikáció,
stb. szerint jó, el lehet fogadni. Ha nincs leírás, készítőtől
nyilatkozatot kell kérni (ha lehet). Ha van nyilatkozat és az
kielégítő, el lehet fogadni. Ha nincs leírás, nincs nyilatkozat, vagy
nem kielégítő, legjobb a szoftvert "from scratch" újra elkészíteni.
Katasztrófa tervet kell készíteni. (l. alább)

Gépek

Gyártótól nyilatkozatot kell kérni a 2000 kompatibilitásról.
Ha a nyilatkozat megfelelő, el lehet fogadni.
Ha nincs nyilatkozat:

Allokálni kell a forrásokat arra az esetre, ha a gép valóban nem 2000
kompatibilis. Lehet kísérleteket tenni, potenciálisan kockáztatva a
gép egyszer s mindenkorra használhatalanná válását. Célszerű 2000.
jan. 1. 00:00-t megvárni, és akkor megvizsgálni a működőképességét.

Ha jó, akkor lehet tovább használni

Ha nem jó, a félretett forrásból újat kell beszerezni.

Kritikus rendszereknél már most el kell végezni a kiváltásukat 2000
kompatibilis eszközökkel, és a kiváltott rendszereket nem kritikus
helyekre be lehet állítani.

Beágyazott rendszerek

Ugyanúgy kell eljárni, mint a gépeknél. Azonban két lényeges
különbség van. A probléma sokkal alattomosabb, mert processzorok
lehetnek ott is, ahol arra sem a használó, sem a forgalmazó nem is
gondol. Másrészt azonnal katasztrófális következmények is lehetnek,
pl. egy lélegeztetőgép leállása esetén.

Mi a teendő?

Vegyük nagyon komolyan a problémát, mert súlyos következményei is lehetnek.
Felmérést kell végezni, hogy hol, milyen katagóriába tartozó eszközök vannak.

Tájékozódni kell az egyes eszközök kompatibilitásáról (WWW,
kiadványok ismeretterjesztő eszközök, stb.)

Az egyes rendszereknél az eddig elmondottak szerint kell eljárni.

A gyártóra való rákérdezés hivatalos, írásos nyilatkozatot jelent.
Egy web lapon közölt információ tájékozódásra használható, de a
gyártó részéről semmilyen kötelezettséget, vagy garanciát nem jelent.
A felmérési és hibaelhárítási feladatot a szubszidiaritási elv
szerint a lehető legalacsonyabb szintre kell delegálni, hiszen a
helyzet felmérése csak ott végezhető el kellő alapossággal. Az illető
szervezeti egység vezetőjének a felelősségét rögzíteni és
tudatosítani kell. A gyártóktól való nyilatkozatkérést viszont a
lehető legmagasabb szinten célszerű összegyűjteni és elvégezni, a
fölösleges levelezési munka kiküszöbölésére. Jogilag tisztázni kell,
hogy a gyártók nyilatkozata milyen felelősségvállalást jelent, ha nem
megfelelő működés következtében mégis valamilyen kár következik be.
(Ez lényegében állami, jogi, törvényalkotási ill. törvényalkalmazási
feladat.) Minden esetben mérlegelni kell a kockázatot, azt, hogy az
adott rendszer működésének a kiesése mekkora kárt okoz.  A
ráfordítások (pénz, munka, tartalékolás) a kockázattal és a
lehetséges kárral legyenek arányosak.

Katasztrófa elhárítási tervet kell készíteni.

Katasztrófa elhárítás

Minden lényeges, lehetséges adatállományt (egész adattárolókat) év
végén menteni kell, hogy probléma esetén a megoldási módszerek
kipróbálásához az eredeti adatokhoz vissza lehessen térni, legalább
az adatvesztést el lehessen kerülni addig is, amig a megoldást ki nem
dolgozzuk. Probléma esetén "from scratch" célszerű a halaszthatatlan
feldolgozásokkal, adatrögzítésekkel, munkával 2000 kompatibilis
eszközökkel ujraindulni, és közben módszereket kell kidolgozni a régi
adatok integrálására. Kiváltó eszközökről kell gondoskodni (hw, sw,
gépek).

Kritikus rendszereknél a kockázat mértéke szerint előre el kell
végezni a kiváltást. Nem kritikus rendszereknél erőforrást (pénzt)
kell allokálni az esetleges későbbi kiváltásra, a kockázat mértéke
szerint.

Mit ne tegyünk?

Ne túlozzuk el a dolgokat, a ráfordítások álljanak arányban a
kockázattal. Bizonyos, hogy vannak olyan körök, amelyeknek érdekük a
probléma túlhangsúlyozása. Egyrészt azoknak, akiknek a hibaelhárítás,
felkészülés bevételt jelent, másrészt a sajtóban is van hajlandóság a
hirek szenzációvá dagasztására. Ne essünk pánikba se. Gondos
előkészítés esetében is valószínűleg fellépnek problémák, éppen ott,
ahol arra nem gondoltunk, ezeket józanul, higgadtan kell kezelni. Az
időpont kísérleti átállítása szoftver esetében valószínűleg
kockázatmentes, ha a rendszer állapotának a megfelelő (teljes)
mentése előzetesen megtörtént. Azonban egy számítógép hardver (akár
univerzális, akár célgép), valamint egy beágyazott rendszer esetében
a dátum kísérleti átállítása esetén fennáll annak a kockázata, hogy a
rendszer üzemszerű használata többé nem lesz lehetséges, így a
problémát már 2000 január előtt előállíthatjuk. (Ilyen
tapasztalatokról egyesek korábban már beszámoltak.) Nem szerencsés a
probléma elodázása olyan módon, hogy a nagy valószínűséggel nem 2000
kompatibilis gépeknél az órát visszaállítjuk. Ez egy rendszerben,
t.i. a felhasználó környezetben annyi mellékhatást okozhat, hogy a
módszer meglehetősen kétes értékűnek és kockázatosnak tekintendő.