A TextLib hírlevélnek a honlapon olvashatóval azonos szövegű nyomtatott változata a szoftvertámogatási díjat fizető könyvtárak számára készül.
A második változtatás fő célja a felhasználószámtól függő díjtételek egységesítése. A 11-25 munkaállomással működtetett TextLibek után fizetendő támogatási díj aránytalanul magas a többi csoporthoz képest, indokolt csökkenteni. Ugyanakkor nem szeretnénk - és reméljük, hogy megértik és elfogadják -, ha a szoftvertámogatás rendszerének teljes összege 2001-ben alacsonyabb lenne az ez évinél.
A fenti fejtegetésből következik, hogy a 11-25 felhasználós csoport árcsökkenésének ellensúlyozására a többi kategóriában emelni szeretnénk a díjat. A kis könyvtárakban kismértékű, a nagyobbakban nagyobb mértékű a növekedés, kérjük tekintsék át az alábbi összefoglaló táblázatot:
| Felhasználószám | Könyvtárak száma | 2000-es díj | 2001-es nettó díj | 2001-es bruttó díj | A változás mértéke |
| 1 | 35 | 1.650 | 1.700 | 2.125 | 3,0% |
| 2-5 | 34 | 3.850 | 4.000 | 5.000 | 3,8% |
| 6-10 | 12 | 5.500 | 6.000 | 7.500 | 9,1% |
| 11-25 | 12 | 13.200 | 12.100 | 15.125 | -8,9% |
| 26-50 | 2 | 16.500 | 18.000 | 22.500 | 9,1% |
| 51-100 | 1 | 25.300 | 27.800 | 34.750 | 9,9% |
A szoftvertámogatást igénybevevő kb. 135 könyvtár által együttesen fizetendő díj összege a változások eredményeként csekély mértékben, 1,1%-kal nő. (A táblázat második oszlopának összege azért kevesebb 135-nél, mert ott a Fővárosi Szabó Ervin Könyvtárat és hozzávetőlegesen 40 TextLibes fiókkönyvtárát egyetlen intézményként szerepeltettük.)
Számítunk a megértésükre!
Nagyon hamar kiderült, hogy a naponta kilenctől hatig tervezett beosztás tarthatatlan. Mindenki elfogadta a budapesti helyszínt, de természetesen sokaknak okozott nehézséget a napi utazgatás. Ésszerű indulási és érkezési időpontok megválasztása mellett a fél órával későbbi kezdés és a fél órával korábbi befejezés bizonyult elfogadhatónak. Az órák összevonásával és a szünetek idejének csökkentésével alakult ki a naponta négyszer másfél órás rendszer, tehát a tanfolyam teljes tervezett 32-szer 45 perces időtartama nem csökkent.
Mindkét alkalommal jó termet kaptunk, nagyon jó számítógépekkel. Bár a TextLib DOS program, Windows 98 környezetben dolgoztunk nagyteljesítményű és többnyire új gépekkel. Az apró technikai nehézségek nem voltak akadályai a sikeres lebonyolításnak.
Sokkal veszélyesebb volt az időhiány. Értelmetlenül feszes órarenddel bizonyára végére jutottunk volna a kijelölt témáknak, és hogy ez nem így történt, annak két oka van. Egyrészt többet időztünk a tervezettnél egy-egy fejezetnél, ha élénk volt az érdeklődés, másrészt időnként lassítani kellet, ha a résztvevők ismeretei vagy számítógépes illetve TextLibes gyakorlata azt indokolta.
Nem törekszünk mindenáron e hiba megszüntetésére. El kell fogadni a tanfolyam összes résztvevőjének, hogy ki-ki - ideértve természetesen az előadót is - más területen erősebb vagy gyengébb. Olyan ütemben szabad haladni, ami mindenki számára lehetővé teszi az anyagrész szükséges mértékű megértését. Ezért itt is kérjük a résztvevőket, hogy követeljék majd ezt meg az előadótól!
Elfogadhatatlan az is, ha időhiány miatt olyan anyagrész marad ki, ami akár csak egyetlen egy könyvtáros vagy számítógépes szakember számára lenne fontos. Kérjük tahát azt is, hogy e tekintetben se legyenek elnézőek!
Az elmúlt két tanfolyamon fontos fejezetek maradtak ki időhiány miatt. Az olvasószolgálatból kevesebb, a rendszergazda ismeretek közül több. A meghirdetett témakörök közül éppen a rendszergazdáké a legnagyobb anyag, reménytelennek látszik 32 órába beletuszkolni mindent. Mivel mi - az InfoKer - amúgy is legkönnyebben a rendszergazdáknak tudunk segítséget adni, megkiséreljük az elmaradásnak legalább egyes részeit a hírlevélben pótolni. Most a TextLib üzemeltetésének egy fontos részletével, az elindítás, leállítás és mentés eseményeit rögzítő naplóval foglalkozunk a Mire jó a ...? című fejezetben.
Ez a programváltozat a tartalmi újdonságokon kívül más szempontból is új. A szoftvertámogatási rendszer érdemi előnyöket nyújt mindazoknak, akik igénybe veszik, és fizetnek is érte. A térítési kötelezettség indokolja a szigorúbb ellenőrzést. A támogatási rendszeren kívül maradók ezentúl már nem juthatnak hozzá a TextLib új változataihoz a frissítő készlet lemásolásával. A felújító program ugyanis ellenőrzi a jogosultságot, és csak akkor működik, ha ezen a téren mindent rendben talál. A vizsgálat kiterjed a jogosult felhasználók számára és a pénzért megszerezhető kiegészítő programokra (web szerver, KözElKat szerver) is.
Készült egy program annak érdekében, hogy a jogosultságokban beálló változásokat ne csak a TextLib következő változatának megjelenésével lehessen érvényre juttatni. Ez képes az éppen működő rendszeren végrehajtani a szükséges változtatásokat. További részletek olvashatók erről a Mire jó a ...? címnél.
Csaknem önkényes az a megkülönböztetés, miszerint a TextLibbel könyvtárosok és számítógépes szakemberek dolgozhatnak. Kis könyvtárakban a két feladatot egyetlen személy végzi, és ahol alkalmaznak a rendszergazda feladatokra egy külön szakembert, ott is gyakorta van szüksége könyvtárosi segítségre, amikor egy csak a rendszergazda menüből elérhető, de mégsem számítástechnikai jellegű feladat kerül sorra. Sok ilyen van, a nyomtatás külalakjának beállításától az olvasószolgálati munkában meghatározandó olvasói kategóriákig és állományokig.
Nem válik tehát élesen szét a könyvtáros és a rendszergazda munkája a TextLibben. A rendszer üzemeltetése is rendszergazda feladat - legalábbis elvileg. A gyakorlatban pedig bizonyára rengeteg könyvtáros is végzi.
Tekintsük most az üzemeltetés hétköznapjaiból a leghétköznapibb részt, amikor már megvannak a számítógépek, telepített program van rajtuk, és azt rendszeresen el kell indítani, majd le kell állítani. Az elindításhoz a TextLib rendszerhez tartozó parancsállományokat célszerű használni, az egygépes működésnél a TEXTLIB.BAT-ot, hálózatosnál pedig a TL_SERV.BAT-ot a kiszolgáló és a TL_MUNKA.BAT-ot a munkaállomás üzembe helyezésekor. Egy Windows9x rendszerű gépen ezek a nevek általában ikonná alakulnak, de a parancsállományok létét, tartalmát és működését ez nem befolyásolja.
A hálózati munkaállomások működtetése üzemeltetési szempontból egyszerű, azok ugyanis nem dolgoznak a rendszer adatbázisával, ezzel szemben az egygépes program és a hálózati kiszolgáló igen. Márpedig a TextLibbel végzett munka minden pillanatban az adatbázissal végzett munkát jelenti: meglévő adatok keresését, megnézését, módosítását és újak bevitelét. Sarkalatos jelentőségű tehát az adatbázis sértetlensége és hibátlan működése.
Sokat fáradozik a rendszer azon, hogy a sértetlenség és a hibátlan működés kívánalma teljesüljön: minden adatrekordot ellenőriz az adatbázisba illesztés előtt, rendszeresen meggyőződik a teljes adatbázis épségéről illetve a részek összetartozásáról, továbbá másolatot készít az adatbázisban történt változásokról. Az egygépes program és a hálózati kiszolgáló elindításakor jól látható de gyorsan eltünő nyomai vannak a képernyőn e sokrétű tevékenységnek.
Van azonban egy szövegállomány, amelyik automatikusan megőrzi az adatbázis állapotának ellenőrzéséről készített jelentéseket. Ez a NAPLO.LOG nevet viseli, és általában a \TEXTLIB könyvtárban található az adatbázis mellett. Az állomány tetszőleges szövegszerkesztővel (ilyen pl. a DOS-ból ismert EDIT, a Norton Commander vagy hasonmásainak szövegszerkesztője, a Windows-os WordPad és a Jegyzettömb, vagy egyszerűbb híján a Word, stb.) olvasható, és időről időre bele is kellhet kukkantani.
Ahhoz persze nem elég olvasmányos, hogy szórakozásból olvasgassuk. De a rendszer szabályos és rendellenes működésének nyomai is megmaradnak a naplóban, és a nyomok a jó nyomozónak rengeteget segítenek.
Tudnunk kell azt, hogy a működés milyen mozzanatai íródnak a naplóba. A szabály roppant egyszerű: mindazok, amelyekben a NAPLO.EXE nevű program életre kel. Nem sokszor fordul ez elő, tehát felsorolhatjuk:
A NAPLO.LOG állományt valójában kizárólag a NAPLO.EXE kezeli, jópár féle működésmódjára jellemző bejegyzést készítve. A parancsállományba illesztés egyik célja éppen az, hogy az elvárt tevékenységre utasító kapcsolók biztosan helyesen álljanak. A gyakorlatban csak nagyon ritkán van szükség a NAPLO.EXE önálló futtatására, a parancsállományokkal minden elintézhető.
Vannak a TextLibhez tartozó kiegészítő programok, amelyek az adatbázist módosítják, és a változásokat természetesen bejegyzik az adatbázis naplóba is. Mivel a NAPLO.LOG állományba nem írnak, csak közvetve derül ki létük: az adatbázis napló mérete megnő egy kilépéstől a következő belépésig. Több más mellett ilyenek az import programok (TL_VESZ.EXE, HM_VESZ.EXE) is.
Lessünk bele a szövegbe, és elemezzünk néhány példát!
1. ***** 2000-03-09 15:45 ************************************************** 2. C:\TEXTLIB\EXE\NAPLO.EXE ELL /Tolt /Ment /JD:\textlib\ment 3. 4. NAPLO V1.27 - TextLib napló kezelő InfoKer 1995-99 5. - Napló, adatbázis ellenőrzés és javítás 6. Ellenőrzendő napló : D:\TEXTLIB\MENT\TJ000690.TNF <üres> 7. 8. A napló és az adatbázis rendben.
A szöveget egy véletlenszerűen választott naplóból ollóztuk ki, az egyetlen változtatás az igazihoz képest a sorok megszámozása. A következő magyarázatokban ezekre a sorszámokra hivatkozunk.
A fenti pár sor a leggyakrabban előforduló bejegyzés a naplóban, az adatbázis ellenőrzés hibamentes esete. A program elindításakor és leállításakor is lezajlik a vizsgálat.
Az első sor a bejegyzés kezdetét jelzi, dátum és időpont található benne. Fontos információ, ha jó a számítógép órája. A második sor az a parancssor, ami a NAPLO.EXE-t indította. A kapcsolókból (ELL /Tolt /Ment /JD:\textlib\ment) következtetve nagy valószínűséggel a TEXTLIB.BAT vagy a TL_SERV.BAT volt a kezdeményező, de természetesen gyakorlott felhasználók a DOS parancssorba is képesek pontosan ugyanezt beírni. Egy fontos megjegyzés kívánkozik még ide az utolsó kapcsolóról. A /JD:\textlib\ment az adatbázis mentés helyét jelöli ki, igen helyesen nem az eredeti adatbázis tárolására szolgáló merevlemezen - bár ez csak egy másik bejegyzésből derül ki egyértelműen. A 4. sor legfontosabb eleme a naplózó program verziószáma (V1.27). A telepítéskor és a felújításkor ügyelni kell arra, hogy a rendszerhez tartozó NAPLO.EXE is a helyére kerüljön, hogy összetartozó programok dolgozzanak együtt. Az 5. sor a parancssorba (2. sor) elsőként beírt kapcsoló (ELL) által meghatározott tevékenységet írja le szöveges formában. A 6. sor a napló állomány helyét, nevét és méretét mutatja meg. Annak az adatbázis naplónak a neve, amelyikbe a program a munkaállomásokon éppen zajló eseményeket írja .TNF-fel végződik. Új napló létrejöttekor ez a név .ANF-re változik, és az új lesz .TNF végű. Talán nem magától értetődő az a két következtetés, ami az adatbázis naplók képződésének szabályából adódik: csak kivételes esetben lehet egynél több .TNF valamint sosem lehet azonos névvel .ANF is és .TNF is a mentés könyvtárában. Az utolsó, a 8. sor egy rövid értékelés, minden rendben van, mindennek működni kell.
A hibamentes üzem közben is szükség van olykor beavatkozásra. Abban az esetben, ha az adatbázis napló mérete eléri az előre beállított értéket, a naplózó program az adatbázis mentésére és új adatbázis napló létrehozására tesz javaslatot:
Az aktuális napló túl nagy. Adatbázist kell mentenie! Akar most menteni (igen)?
Ha engedélyt kap rá az "igen" begépelésével, akkor meg is csinálja, ha nem, akkor a következő alkalommal ismét kezdeményez. El szabad halasztani az új adatbázis napló létrehozását, ennek a napló betöltési idejének növekedésén kívül semmiféle hátrányos következménye nincs. Az adatbázis napló méretét a NAPLO.EXE programhoz fűzhető /S kapcsoló szabályozza. A mentés művelete a NAPLO.LOG-ban a következőhöz hasonló szöveg létrejöttét eredményezi:
1. ***** 2000-08-11 07:51 ************************************************** 2. C:\TEXTLIB\EXE\NAPLO.EXE ELL /Tolt /Ment /JD:\textlib\ment 3. 4. NAPLO V1.27 - TextLib napló kezelő InfoKer 1995-99 5. - Napló, adatbázis ellenőrzés és javítás 6. Ellenőrzendő napló : D:\TEXTLIB\MENT\TJ000182.TNF ( 152 Kbyte ) 7. 8. - Adatbázis mentés, új napló létrehozás 9. 10. Lezárandó napló: D:\TEXTLIB\MENT\TJ000182.TNF ( 152 Kbyte ) 11. Új napló: D:\TEXTLIB\MENT\TJ000183.TNF 12. 13. Adatbázis mentés: 2000.08.11 7:51:25 14. Adatbázis másolása: C:\TEXTLIB ==> D:\TEXTLIB\MENT 15. Összesen 32 adatbázis file (32 másolva, 0 ugyanaz) 16. 17. Ajánlott tevékenységek: biztonsági mentés,
A 8. sortól kezdődnek az újdonságok. A parancssor kapcsolóinak megfelelően (ELL /Tolt /Ment) a NAPLO.EXE elsőként ellenőrizte az adatbázist és a naplóját, és mivel azt a beállítottnál nagyobbnak találta, kezdeményezte a mentést. Az engedély birtokában látott a feladatnak, a 10. sor szerint lezárta az adatbázis naplóját, és készített egy újat (11. sor). A 13. sorban látható másodperc pontossággal a művelet időpontja, a 14. sor szövegéből pedig kiderül, hogy a parancssor /JD:\textlib\ment kapcsolója valóban az adatbázis helyétől különbözőt jelöl meg a mentés helyeként. Az egyik a C:, a másik a D: betüjelű merevlemezen található, így egyik fizikai sérülése sem okozhatja az adatbázis pusztulását. A mentés folyamata nem más, mint az ellenőrzötten hibátlan adatbázis lemásolása (15. sor). Végül a 17. sor egy rendszeresen visszetérő javaslat, eszerint célszerű az adatbázisról az eddigin túlmenően még egy mentést készíteni. Ezt az ajánlatot nyugodtan figyelmen kívül lehet hagyni, egyszer talán sort kerítünk azoknak a helyzeteknek az elemzésére is, amikor előnyt jelent a másodlagos mentés léte.
Természetesen nem kötelező megvárni, amíg a mentést a rendszer kéri a felhasználótól, a TL_MENT paranccsal bármikor soron kívül is elmenthető az adatbázis. Ennek jele a 2. sor, a parancssor első kapcsolója, valahogy így:
1. ***** 2000-08-11 07:51 ************************************************** 2. C:\TEXTLIB\EXE\NAPLO.EXE MENT 3. ...
Az eddigi két példától eltérőt ideális esetben nem is lát a rendszer működtetője. A valóságos esetek azonban mások is lehetnek, nézzünk ilyeneket.
Következő példánk egy ritkán előforduló, de mégis fontos eseményt mutat be. Az adatok biztonsága érdekében szinte kötelező az adatbázist és a mentést két külön merevlemezen tárolni. Hangsúlyozzuk a két eszköz fontosságát, nem elegendő a két különböző betüjel, hiszen az takarhat fizikailag egy és csak logikailag kettő merevlemezt is. (A két lemezegység létéről a gépház kinyitásával vagy a számítógép BIOS-ának böngészésével győződhetünk meg, de a 2-3 évnél újabb gépek elinduláskor a képernyőre is kiírják.)
1. ***** 2000-10-09 10:37 ************************************************** 2. E:\TEXTLIB\EXE\NAPLO.EXE ell /Tolt /Ment /je:\mentes 3. 4. NAPLO V1.28 - TextLib napló kezelő InfoKer 1995-2000 5. - Napló, adatbázis ellenőrzés és javítás 6. Ellenőrzendő napló : E:\MENTES\TJ000030.TNF 7. J034(2013): Új adatbázis mentést kell készíteni ! 8. 9. - Adatbázis mentés, új napló létrehozás 10. 11. Lezárandó napló: E:\MENTES\TJ000030.TNF 12. J023(3): A E:\MENTES\TJ000030.TNF napló megnyitási hiba ! 13. Új napló: E:\MENTES\TJ000031.TNF 14. 15. Adatbázis mentés: 2000.10.09 10:37:45 16. Adatbázis másolása: E:\TEXTLIB ==> E:\MENTES 17. Összesen 32 adatbázis file (32 másolva, 0 ugyanaz) 18. 19. Ajánlott tevékenységek: biztonsági mentés,
A példa az adatbázis mentés helyének megváltoztatásáról készült NAPLO.LOG bejegyzéseket mutatja. A művelet kulcsa az új hely megnevezése, legegyszerűbben egy környezeti változó beállításával (célszerűen az AUTOEXEC.BAT-ban):
SET TLPARAM=/JE:\MENTES
A parancssor (2. sor) utolsó kapcsolója jelzi az alapértelmezett helytől való eltérést. Természetesen a valóságban tetszés szerinti helyet meg szabad jelölni a környezeti változó alkalmas kitöltésével. A 7. sor továbbá a 11. és 12. mutatja, hogy az új helyen nincs sem mentés sem adatbázis napló, tehát most mindenképpen menteni kell. A rendszer nem létező hely megadását is megengedi, a rendszergazda hozzájárulásával a szükséges pillanatban létrehozza, és használatba veszi.
Dönteni kell a mentés korábbi helyén maradó állományok sorsáról. Elvi megfontolásból nem szabad kettő mentési hely létét tűrni, legcélszerűbb tehát a helyet megszüntetni. Az ott tárolt adatbázist nyugodtan törölhetjük, hiszen az új helyen már van egy azzal egyenértékű. Az adatbázis naplók (a .ANF és .TNF kiterjesztésű állományok) megtartása csak akkor indokolt, ha valahol (pl. CD-n) van egy adatbázis, amelyre azok még rátölthetők, vagy ha a rögzített események böngészése céljából akarjuk megtartani. Minden más esetben igaz az, hogy a .ANF kiterjesztésű állományokat le szabad törölni, ha nincs már meg a létrejöttüket megelőzően elmentett adatbázis.
Következzen a programhiba, áramszünet vagy a rendszer szabálytalan leállítása - kilépés helyett kikapcsolás - miatt keletkező napló bejegyzés! A rendszer gondosan ügyel az adatbázis épségére, nagy tehát az esélye annak, hogy még ilyenkor sem keletkezik sérülés. A rendellenességet követő elindításkor a következőt láthatjuk:
1. ***** 2000-03-18 10:12 ************************************************** 2. C:\TEXTLIB\EXE\NAPLO.EXE ELL /Tolt /Ment /JD:\textlib\ment 3. 4. NAPLO V1.27 - TextLib napló kezelő InfoKer 1995-99 5. - Napló, adatbázis ellenőrzés és javítás 6. Ellenőrzendő napló : D:\TEXTLIB\MENT\TJ000696.TNF ( 65 Kbyte ) 7. 8. A napló és az adatbázis helyreállítva. 9. (Az elmentett találati halmazok törlődtek!)
A 8. és a 9. sor tartalmazza az újdonságot. Az ellenőrzés sértetlennek találta az adatbázist és a naplóját, de észlelte a szabálytalan kilépés tényét. Kényszerűségből megsemmisítette a találati halmazokat tartalmazó állományt (TL_TMP.TTH), mert annak az épségére szándékosan nem ügyel az adatbáziséhoz mérhető gondossággal.
Természetesen nem lehet mindig ennyire egyszerű egy szabálytalan leállás. Ha megsérül az adatbázis, akkor a korábban még ép adatbázisról készült másolat és a naplói alkalmasak a helyreállításra. Ez akár automatikus is lehet a /Aigen kapcsolóval, de hamarosan kiderül, hogy miért helyesebb itt meghagyni a beavatkozás lehetőségét.
1. ***** 2000-08-30 07:35 ************************************************** 2. T:\TEXTLIB\EXE\NAPLO.EXE ELL /Tolt /Ment 3. 4. NAPLO V1.27 - TextLib napló kezelő InfoKer 1995-99 5. - Napló, adatbázis ellenőrzés és javítás 6. Ellenőrzendő napló : T:\TEXTLIB\MENT\TJ000192.TNF ( 133 Kbyte ) 7. J106(14): Sikertelen adatbázis (indexfile) megnyitás !!! 8. 9. - Napló betöltés 10. Betöltendő napló : 1. TJ000192.TNF 11. 12. Napló: TJ000192.TNF 2000.08.29 7:36:42 (2000.08.28 7:46:43)13. 14. 1 db napló, 526 feldolgozott bejegyzés ! 15. 16. Az adatbázis állapot 2000.08.29 18:17:49 időpontnak megfelelő. 17. Adatbázis másolása: T:\TEXTLIB\MENT ==> T:\TEXTLIB 18. Összesen 32 adatbázis file (32 másolva, 0 ugyanaz) 19. 20. - Adatbázis mentés, új napló létrehozás 21. 22. Lezárandó napló: T:\TEXTLIB\MENT\TJ000192.TNF ( 133 Kbyte ) 23. Új napló: T:\TEXTLIB\MENT\TJ000193.TNF 24. 25. Adatbázis mentés: 2000.08.30 7:48:05 26. Adatbázis másolása: T:\TEXTLIB ==> T:\TEXTLIB\MENT 27. Összesen 32 adatbázis file (1 másolva, 31 ugyanaz) 28. 29. Ajánlott tevékenységek: biztonsági mentés,
Nagyobb a baj az eddiginél, ezt a 7. sor mutatja. A hibakód megfejtésével most nem foglalkozunk, már csak azért sem, mert ezen a helyen rengeteg különböző sorszám fordulhat elő. A TLDOC programmal olvasható dokumentáció "hiba" című fejezetei szólnak az értelmezésükről. Most tehát a rendszer olyan hibába ütközött amelyen nem tud úrrá lenni, így felajánlja a korábban elmentett sértetlen adatbázis és a hozzátartozó naplók egyesítését:
Indulhat a napló betöltés (igen)?
Az "igen" válasz után a 9. sor jelzi a művelet kezdetét, a 10. sor azonosítja a betöltendő naplót, esetleg naplókat. Tartozhat ugyanis több adatbázis napló a mentéshez: minden mentéskor új napló képződik, de naplót lehet mentés nélkül is készíteni. A 12. sorban a feldolgozott napló részletes adatai látszanak, a nevén kívül azonosítóként használt dátumok és időpontok. Betöltés közben a képernyőn minden bejegyzés lényege látszik, a NAPLO.LOG szövegállományba viszont csak a 14. sorban olvasható összegzés kerül be. A 16. sor NAGYON-NAGYON FONTOS a betöltés sikerének megítélése miatt. A napló betöltéséhez vezető hiba felbukkanása előtti legutolsó adatbázis művelet ugyanis a kiírt időpontban zajlott le a program hite szerint. Ebben a pillanatban a \TEXTLIB könyvtárban van egy sérült adatbázis, a helyreállítás eredményeként pedig egy ép a mentés könyvtárban. Hogy az ép adatbázis teljes-e vagy hiányos, az a betöltött napló állapotától függ. Ha a rendszernek kétségei vannak, akkor kérdez:
A fenti időpont alapján ellenőrizze, és ha rendben találja, csak akkor engedje az adatbázis átmásolását! Indulhat az adatbázis átmásolása (igen)?
Az "igen" válasz semmiképpen sem lehet automatikus, hiszen az is előfordulhat, hogy az adatbázis napló sérülése miatt a betöltés nem teljes. Ezért kell a kiírt időpontot összevetni a munka kényszerű befejeződésének időpontjával, és dönteni. A sérült és működésképtelen adatbázisban ugyanis az adatbázis napló esetleg értelmezhetetlen részében található tevékenységek eredménye is benne van, amit a betöltés nem volt képes helyreállítani. Ha a számítógép órája pontos, akkor könnyű megítélni, hogy az adatbázis napló tartalmazza-e a leállásig végzett összes munkát, vagy sem. Az "igen" válasszal a helyreállított adatbázis elfogadása mellett döntünk, így a 17. és 18. sorban olvasható szöveg szerint megtörténik az adatbázis átmásolása a munkakönyvtárba. A 20. sortól kezdve az új napló létrehozásának és egy mentésnek már korábban megismert lépési következnek. Ez volt tehát az a mozzanat, amely miatt nem helyeselhető a /Aigen kapcsoló általános alkalmazása.
A "nem" akkor indokolt, ha a sérült adatbázis tartalma a teljes, nem pedig a napló betöltésével helyreállítotté. A válasz után a helyreállított adatbázis a mentés könyvtárban marad, a program továbbra is működésképtelen. A rendszergazda a munkakönyvtárban levő adatbázis újraépítése után helyezheti ismét üzembe a rendszert. Az újraépítés lépései, ezúttal csak címszavakban:
DBF_PACK /F /X /0 INDEXEL /F TL_MENT
Az esetek túlnyomó részében az adatbázis napló sérülés nélkül ússza meg a leállást, függetlenül attól, hogy áramszünet, programhiba vagy bármilyen más ok miatt került rá sor. Leszögezhetjük tehát, hogy a TextLib az elszállást követő első elindításkor képes automatikusan helyreállítani a sérült adatbázist.
Sokféle hiba történhet az adatbázissal, reménytelen lenne az azok hatására a NAPLO.LOG-ban képződő bejegyzéseket sorra venni. Kijelenthetjük azonban, hogy a hibák előfordulása rendkívül ritka, néhány üzemeltetési szabály betartásával akár évekig ismeretlenek maradnak. Kötelező
Ugyanakkor nem szabad
Tekintsünk azért egyet elrettentésül a ritka hibák közül is! Az adatbázis nem állítható helyre napló betöltéssel, ha a napló ép, de mégsem tartalmazza a sérülést megelőző összes változást.
1. ***** 2000-04-25 17:54 ************************************************** 2. E:\TEXTLIB\EXE\NAPLO.EXE TOLT 3. 4. NAPLO V1.27 - TextLib napló kezelő InfoKer 1995-99 5. - Napló betöltés 6. Első betöltendő napló : 1. TJ001024.TNF 7. Utolsó betölthető napló : 2. TJ001025.TNF 8. 9. Napló: TJ001024.TNF 2000.04.25 15:53:31 (2000.04.09 18:25:24)10. Napló: TJ001025.TNF 2000.04.25 17:50:13 (2000.04.25 17:23:01) <üres> 11. J022(2005): Naplóból kimaradt adatbázis módosítás !!! 12. 13. 1 db napló, 575 feldolgozott bejegyzés 14. 15. Az adatbázis állapot 2000.04.25 17:19:46 időpontnak megfelelő. 16. 17. Ajánlott tevékenységek: adatbázis újraépítés a 'e:\textlib\' könyvtárban
A 2. sorban olvasható első kapcsolóból (TOLT) kiderül, hogy a tevékenység napló betöltés, annak végeztével a 11. sor mutat rá a riasztó helyzetre. A szöveg nem utal a körülményekre, annyi azonban bizonyos, hogy a lezáratlan naplóból kiolvasható utolső bejegyzés időpontjánál későbbi az adatbázisban végrehajtott utolsó módosítás időpontja. A rendszer nem is enged más módot a helyreállításra, mint az adatbázis újraépítését (17. sor).
A NAPLO.LOG állomány a TextLib legelső elindulásától kezdve gyűjtögeti az üzemeltetés tapasztalatait. A napi működéshez kapcsolódó információk mindig a szöveg legvégén olvashatók, általában nincs szükség tehát az egész állomány áttekintésére. Évek óta zajló munka után a NAPLO.LOG mérete akkorára duzzadhat, hogy próbára teszi bármilyen szövegszerkesztő vagy megnéző program képességeit. Szükség lehet ezért a méret csökkentésére. Ennek legegyszerűbb módja az állomány letörlése, vagy átmozgatása az archív adatok tárolási helyére. Amikor a rendszer észreveszi a hiányát, azonos névvel újat hoz létre, és a továbbiakban azt használja.
A TextLibbel dolgozók a program használati jogának megszerzésekor egyedileg készített, névre szóló telepítőlemezt kapnak. Ebben a jogosultságot a könyvtár neve és egy azonosító szám igazolja. Mindkettő látszik a képernyőn is: hálózatos működéskor a szerver képernyő alján, egygépesnél vagy munkaállomáson pedig a bejelentkező ablakban. Az azonosító szám alakja IK1995Tnnnn alakú, ahol nnnn helyén számok állnak, a könyvtár neve pedig a közismertnek feltételezett név. Az azonosító és a név felhasználóként megváltoztathatatlan, a név tehát nem azonos a könyvtár rekordban (rendszergazda menü, Rendszer / Könyvtárunk adatai pont) tárolt névvel.
A szorosan vett azonosítókon túl tartalmaz a program a jogosultsag reszleteire vonatkozó adatokat is, mégpedig a következőket:
A felsorolt jogok nyilvántartása és kezelése az 1.60-as TextLib változat újdonsága, és ettől kezdve a felújítás menetébe is beépül. Az Infoker honlapról korlátozás nélkül letölthető felújító készlet csak a használati joggal rendelkező könyvtárakban működik, és éppen a programba beírt jogosultságok megszabta mértékig változtatja meg a rendszert. Szélsőséges esetben ez akár azt is jelentheti, hogy a felújító program nem indul el, hiszen az új TextLib változatokat díjmentesen csak a szoftvertámogatást igénybe vevő könyvtárak használhatják. Természetesen a működő rendszert nem teheti működésképtelenné a felújítás, a szoftvertámogatási rendszerből kimaradt könyvtárak korábban megszerzett jogai nem korlátozhatók.
Ha csak a felújítás lenne képes a jogosultságokban beállott változásokat követni, az kevés lenne, sürgősebb is lehet annál a dolog. Elkészült tehát a NEVESIT.EXE program, amellyel a korábban felsorolt azonosítókat és jogokat lehet megváltoztatni.
A program használata egyszerű: minden számítógépen le kell futtatni, ahol telepített TextLib rendszer van. Az egygépesnél ez egyetlen számítógép, a hálózatosnál pedig a szerver és a munkaállomások - beleértve az esetleges web szerver gépet is -, illetve a NetWare hálózati kiszolgálóra telepített rendszernél szintén egyetlen számítógép (a kiszolgáló), amit azonban egy NetWare munkaállomásról lehet elérni.
Ez a program nem kerül fel az InfoKer honlapra, mert nem általános célú a használata. Csak külön kérésre, az egyedi beállításokkal készül, és mindig csak egyetlen könyvtárban szabad használni.
Kérjük tisztelt felhasználóinkat, hogy ellenőrizzék az intézményükben működő TextLib rendszert! Amennyiben a nevük vagy a jogosultságuk a programban eltér a valóságostól, kérjék a NEVESIT.EXE programot. Még egyszer hangsúlyozzuk, hogy idegen helyen használni nem szabad, mert az elérhető beállítások kizárólag egyetlen helyen lehetnek helyesek.
A hálózatos TextLib üzenetküldő mechanizmusa a feladott és a megérkezett üzenetek eltéréséből észleli ezt a hibát, és kétféle módon reagálhat. Megpróbálhatja megismételni az üzenetet, vagy érvénytelennek tekintheti. Mivel a hiba következetes, az ismétlésnek nincs értelme, az 1.60-as változatban a hibás üzenetek megsemmisülnek.
Ez a szigor bizonyos helyzetekben a munkaállomás működésképtelenségéhez vezethet. Szerencsétlen dolog, de nincs kiút. A hiba véletlenszerűen képződő helyzetekben végzetesen bukkan fel, a véletlent pedig a Windows 98 és az általa futtatott programok pillanatnyi, átláthatatlan egymásra hatása irányítja.
Jelenleg három megoldás látszik:
A hiba előfordulása önmagában nem bizonyítja a Realtek 8029 jelenlétét. Teljes bizonyosságot az jelent, ha a hálózati kártyán vagy a dobozán olvasható a Realtek 8029 jelzés.
Ezzel gyakorlatilag eltünnek a használati korlátok, és bármilyen munkafolyamat végrehajtása akadálytalanná válik. A legendásan memóriafaló lépések, mint amilyen a többkötetes könyvek honosítása vagy a katalóguscédula-nyomtatás is biztonsággal megtehetők.
Természetesen ezután sem mellőzhető a számítógép saját memóriakezelésének optimalizálása, ahogyan az a TLDOC.EXE programmal olvasható dokumentáció TELWIN95 című fejezetében szerepel. Ennek elmulasztását ugyanis még az 1.60-as TextLib ügyessége sem ellensúlyozhatja.
Az összegzés annyira egyszerű, hogy a munka menetét szükségtelen leírni, csupán a standard forgalmi statisztika elérési helyét adjuk meg a menürendszerben: az [Olvasószolgálat / Forgalmi adatok] pontban található.
Készíthető statisztika egész évre is, ebben az esetben az évszám megadása után a hónapot üresen kell hagyni. Az éves összesítés sorai természetesen nem a napok lesznek, hanem a hónapok.
Fontos tudnivaló, hogy a táblázatba a látogatók száma rovatba pontosabb információ hiányában csak azok a könyvtárlátogatók kerülnek, akik vagy kölcsönöztek vagy hosszabbítottak vagy visszahoztak dokumentumot. Emellett természetesen rengeteg olvasó járhatott "csak úgy" a könyvtárban, a TextLib a jelenlétükről tudomást sem vett. Ha szükséges, a számuk az előző csoport létszámából becsléssel határozható meg, egyszerűen egy tapasztalati szorzó beiktatásával. A szorzó helye a [Rendszer / Könyvtárunk adatai] adatlapnak a [Paraméterek] almezőjében a [Látogató %] mezőben van. Az értelmezés kézenfekvő: a beírt szám a becsült létszám és a számítható létszám aránya százalékban kifejezve. Ha tehát pl. a könyvtár összes látogatóinak száma általában másfélszerese azokénak, akik közülük a felsorolt műveletek valamelyike miatt érkeztek, akkor a [Látogató %] 150 legyen.
Vissza: Hírlevelek TextLib honlap InfoKer honlap