Rendszergazdai tudnivalók

1. Külső programok

1.1. Karbantartó programok

1.1.1. DBF_PACK: Adatfájl tömörítő program

Célja

A TextLib adatfájlok tömörítése, esetleges sérülések kijavítása. Normális esetben nem kell használni. Adatbázis sérülések után sem ezt kell elővenni, hanem naplózással kell helyreállítani az adatbázist. Ennek a programnak a használata csak a legvégső menedék lehet.

NE használja az InfoKer tudta és beleegyezése nélkül! Használata

Különálló program, akkor használható, mikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

Paraméterek

Használat: DBF_PACK [paraméterek] [ds1 [ds2 ...]]

Paraméterek: (a többi paraméter: prgparam

/1 - törli a régi fájlt, az opció nélkül átnevezi.
/r - csak akkor tömörít, ha rossz a fájl.
/t - midenképpen tömörít, az opció nélkül csak akkor, ha tömöríthető a fájl.
/s - tömörítés előtt nem ellenőrzi, hogy van e elég hely a lemezegységen.
/n - nem ellenőrzi a rekordok szerkezetét
/0 - kiüríti a rossz rekordokat
/x - kihagyja, törli a rossz rekordokat
ds(i) - tömörítendő TEXTLIB adatfájl neve

1.1.2. REINDEX: Indexfájl felépítő program

Célja

A TextLib adatfájlok alapján ezzel a programmal tudjuk felépíteni az indexfájlokat. Ezekre a rekordok gyors megtalálásához van szükség.

Általában nincs szükség az indexfájlok újraépítésére, mivel a TextLib használata közben folyamatosan változnak. A következő esetekben lehet csak szükség erre a programra:

Kaptunk valakitől egy adatbázist, de helytakarékosság miatt csak az adatfájlokat küldte el. Ilyenkor az alső használat előtt létre kell hozni az indexfájlokat.
Nem használjuk a TextLib napló szolgáltatását (amit pedig mindenkinek melegen ajánlunk), és megsérült az adatbázis. Ilyenkor csak a DBF_PACK és a REINDEX segít.

Használata

Különálló program, akkor használható, mikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

A program futása félbeszakítható, és a legközelebbi alkalommal folytatható. Akkor viszont ugyanezeket a paramétereket kell megadni, különben nem indul el. Ha paraméter nélkül is hívhatjuk ilyenkor, a megszakításkor érvényes paramétereket fogja használni.

NOVELL hálózat használata esetén az adatbázis indexelése egyszerre több gépről is végezhető. Ez az indexeléshez szükséges időt természetesen jelentős mértékben csökkenti. Természetesen minden gépen más-más indexset-eket kell indexelni.

1.1.3. NAPLO: Naplózó program

Célja

Adatbázis ellenőrzés
Sérült adatbázis helyreállítása
Adatbázis mentés

Használata

A TextLib indító BATCH-ekben használjuk, normális esetben nincs szükség a program ettől eltérő használatára.

NE használja az InfoKer tudta és beleegyezése nélkül! Paraméterek

NAPLO funkció [/funkció] [paraméterek]

Funkció:

Ell - adatbázis, napló ellenőrzés és javítás
Letr - új napló létrehozás
Ment - adatbázis mentés, új napló létrehozás
Tolt - napló betöltés
List - napló listázás

Másodlagos funkció:
engedélyezi a program újraindulását a funkcióval, ha szükséges illetve ha a feltételei adottak. Pl.: NAPLO ELL /TOLT hatására a program ellenőrzést végez, és ha az adatbázist hibásnak találja, napló betöltéssel helyreállítja. .BR. A másodlagos funkció használhatóságát a különböző elsődleges funkciók mellett + jelzi. A másodlagos funkció végrehajtása a Feltétel-től függ.

paraméter	Ell	Letr	Ment	Tolt	List	Feltétel
/Letr	+	-	-	+	-	túl nagy a napló vagy új napló kell
/Ment	+	-	-	+	-	túl nagy a napló és nincs megadva /Letr, vagy menteni kell
/Tolt	+	-	-	-	-	megsérült az adatbázis
/LMT	+	-	-	-	-	/Letr, /Ment és /Tolt együtt

Paraméterek: használhatóságuk szintén az elsődleges funkciótól függ, az alábbiak szerint:

paraméter	Ell	Letr	Ment	Tolt	List	Magyarázat
/P<path>	+	+	+	+	+	path az adatbázis leírás kereséséhez: path>\TLM\DBDESCS.TLM (alapértelmezés: \TEXTLIB)
/D<path>	+	+	+	+	-	path az adatbázis kereséséhez (alapértelmezés: ha /P adott, akkor azonos, ha nem, akkor /P alapértelmezése)
/J<path>	-	-	-	+	+	path napló kereséshez (alapértelmezés: \TEXTLIB\MENT)
/A<path>	-	-	-	+	+	path régi (*.ANF) naplók kereséshez (alapértelmezés: /J szerint)
/M<path>	-	-	+	+	-	path adatbázis mentésnek (alapértelmezés: /J szerint)
/M2<path>	-	-	+	+	-	path biztonsági adatbázis mentés kereséshez (alapértelmezés: nincs)
/regiszt	-	-	+	-	-	csak mentés regisztrálás
/mozgat	-	-	-	+	-	sikeres adatbázis helyreállítás után nem másolja, hanem átrakja az adatbázist (/M<path> --> /D<path>)
/vanm2!	-	-	-	+	-	a biztonsági mentés létét jelzi, ha /M2 nincs megadva
/folyt	-	-	+	-	+	napló folytatás engedélyezése
/regi	-	-	-	+	+	régi (*.ANF) naplók használatának engedélyezése
/L<név>	+	+	+	+	-	LOG fájl neve (alapértelmezés: NAPLO.LOG, hely /D szerint)
/s<méret>	+	-	-	-	-	maximális napló fájl méret kByte-ban (alapértelmezés: 150 kByte, min: 0kbyte)
/Aigen	+	+	+	+	+	automatikus 'igen' minden kérdésre

Hibakódok

2000 - Rossz napló bejegyzés
2001 - Rossz napló típus
2002 - Más napló típus
2003 - Rossz napló fájl
2004 - Rossz adatbázis azonosító
2005 - Rossz adatbázis kor
2006 - Rossz napló azonosító
2007 - Napló megnyitási hiba
2008 - Napló betöltött
2009 - Nincs napló fájl
2010 - Van napló fájl
2011 - Nem lezárt napló
2012 - Rossz napló verzió
2013 - Uj napló kell
2014 - Nagy az aktuális napló

1.1.4. DBCHK: Adatbázis helyesség ellenőrző / javító

Célja

A TextLib adatfájlokon végigmenve ellenőrzi a legfontosabb összefüggések meglétét, mezők helyességét, stb.

Használata

Különálló program, akkor használható, mikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

A program futása félbeszakítható, legközelebb folytatható. Akkor viszont ugyanezeket a paramétereket kell megadni, különben nem indul el. Folytatásnál paraméter nélkül is hívható; ilyenkor a megszakításkor érvényes paramétereket fogja használni.

DBCHK opciók

//kolcs - kölcsönzési információkat ellenőrzi
//kapcs - minden hivatkozást ellenőriz
//space - mező elején/végén nézi a SPACE-eket
//space2 - mező belsejében nézi a több SPACE-t
//ures - üres string mezőket vizsgálja
//uresrec- üres rekordokat vizsgálja
//kotete - kötet nélküli példányok-at vizsgálja
//cimek - főcim, párh.cim, cimadatok ellenőrzése
//reszjel - részjelzés/közös adat megléte kötetnél
//dupla - almező duplázódást ellenőrzi
//felsz - olvasó felszólításai is ellenőrzendők (csak //kolcs esetén)
//minden - minden ellenőrzés
//javit - amit lehet (olvasó, kölcsönzés, tartozás), javít
/Hxxx - csak az xxx azonosítójú dolgozó elmentett halmazán

A //javit paramétert körültekintéssel javasoljuk használni, hiszen ennek során az adatbázis módosul. A javítás előtt célszerű először csak //kolcs paraméterrel futtatni a programot: ha a futás eredményeként készített DBCHK.LOG állományban vannak kölcs, kölcs tartozás, tartozás, user Tartozás vagy előjegy típusú hibák (lásd alább), ezek korrigáltathatók - nem mind! - a program újrafuttatásával //javit opció alkalmazásával (amit értelemszerűen a //kolcs paraméterrel együtt kell használni).

A //javit opció használata előtt célszerű az adatbázist menteni, a futást követően a DBCHK.LOG fájlból tájékozódni, hogy mely hibákat javította a program. Ezt követően célszerű egy újabb (csak //kolcs opció //javit opció nélkül) futtatással meggyőződni, arról, hogy mely hibák maradtak, azaz mely hibák javítása nem sikerült. Ezek javítása csak az adatbázis és a valóság egybevetése után, rendszergazdaként belépve, a megfelelő rekordok mezői egymással összhangban történő javításával lehetséges, és az adatbázis szerkezetének alapos ismeretét feltételezi. Ha nem 100 %-osan biztos abban, hogy mit kell tenni, inkább kérje az InfoKer segítségét!

1.1.5. DREFCHG: Hivatkozó mező megváltoztatása

Célja

A TextLib adatfájlokon végigmenve az összes rekord összes mezőjében lecserél egy rekord azonosítót egy másikra.

Használata

Különálló program, akkor használható, amikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

DREFCHG [miről mire | @fname} [/Hazon] [/teszt]

miről - mely datarefet
mire - milyen datarefre
@fname - az fname fájlban a cserélendők
azon - dolgozó halmazán

Példa:

DREFCHG t3 t302
DREFCHG /H0 @dref.chg

Ha csak egy rekord azonosítót kell lecserélni egy másikra, akkor érdemes ezt a parancssorban megadni. Ha több cserélendő is van, akkor egy fájlban kell felsorolni a miről mire párokat.

Ha nem az egész adatbázisra akarjuk ráereszteni a cserét, akkor be kell lépni a TextLibbe, ott előállítani a megfelelő halmazt, és elmenteni. Kilépve a TextLibből a DREFCHG-nek meg kell adni, kinek az elmentett halmazán dolgozzon (/Hazon - ahol 'azon' a dolgozó azonosítója)

Példa:

Ha az adatbázisban valami okból három 'Budapest' nevű földrajz rekord is van, amiknek a datarefjei t3, t33.2, t43.3, és csak egyet akarunk ezek közül megtartani (t3-at), akkor a budapest.dat fájlba a következő két sort írjuk:

t33.2   t3
t43.3   t3

Ezzel a fájllal futtassuk a DREFCHG-t, igy:

DREFCHG @budapest.dat

1.1.6. DBRUN: TextLib rekord műveletek

Célja

A TextLib adatbázis rekordok listázása, mezők törlése, kitöltése, stb.

Használata

Különálló program, akkor használható, amikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

Hívási mód: DBRUN [param] [param] [...]

/Ppath	path az adatbázis leírás kereséséhez. Def: \TEXTLIB
/Dpath	path az adatbázis kereséséhez. Def: /Ppath
/Rdref	rekordok tartalmát a dref.lst fájlba írja.
/Kdref	törli az adott datarefű rekordot - mindenképp
/K@fájl	törli a fájlban megadott rekordokat - mindenképp
/Xdref	törli az adott datarefű rekordot - ha lehet
/X@fájl	törli a fájlban megadott rekordokat - ha lehet
/Ffld:dref	törli a dref azonosítójú rekord fld mezőjét
/Ffld/rno:dref	törli a mező adott előfordulását
/Sfld:dref=dr	beállítja a dref azonosítójú rekord fld mezőjét
/Sfld/rno:dref=dr	beállítja a mező adott előfordulását
/Sfld1/rno1;fld2/rno2:dref=dr	almező beállítása rno == -1 jelenti az utolso ismetlodest
/Tdref	törli a dref azonosítójú rekord <törölt rekord> pointereit
//noindex	ROSSZ rekordok törléséhez. Ne törölje az indexeket
@fname	a paramétereket fájlból veszi

Példa:

A b7 rekord törlése, ha nem hivatkozik rá más rekord:

DBRUN /Xb7

A torold.dat fájlban megadott rekordok törlése mindenképp:

DBRUN /K@torold.bat

A b7 dokumentum rekord SZERZO (70. sorszám) mezőjének törlése

DBRUN /F70:b7

A b7 rekord törlése

DBRUN /Kb7

A b7 dokumentum rekord SZERZO (70. sorszám) mezőjének beállítása f4-re:

DBRUN /S70:b7=f4

1.2. Adatbázis műveletek

1.2.1. HELPIMP: Help rekordok betöltése

Célja

Az adatbázisba szövegfájlból betölti a help rekordokat. A szövegfájl speciális formájú. A felújító lemezek tartalmazzák mindig az aktuéális helpeket, verzióváltás után érdemes ezeket mindig betölteni.

A program a \TEXTLIB\HELP könyvtárban található !

Használata

HELPIMP fájlnév
HELPIMP @fájlnév

Utóbbi esetben a fájlban vannak felsorolva a betöltendő fájlok nevei, minden sorban egy.

Összes help betöltése

Az összes help betöltéséhez készítettünk egy batch fájlt (ALLHELP), a verzióváltás után ezzel érdemes betölteni a helpeket, ily módon:

CD \TEXTLIB\HELP
ALLHELP.BAT

1.2.2. LELTELOK: TextLib leltár előkészítő program

Funkciója

A leltározás előkészítése a TextLib adatbázisban. A leltározás indításának előfeltétele a program futtatása.

Használata

A programmal a TextLib adatbázisban lévő összes példányt vagy egy találati halmazba gyűjtött kiválaszott példányokat leltározandónak jelölhetünk. Az első esetben semmiféle előkészületre nincs szükség, a második esetben a találati halmazt a TextLibben kell előállítani majd elmenteni. Ezután a LELTELOK futtatásakor a mentést végző dolgozó belépési azonosítóját kell paraméterként megadni.

A program csak közvetlenül a TLSRV leállítása és egy adatbázis mentés (tl_ment) után futtatható. Futás után is azonnal menteni kell az adatbázist - ezt a várhatóan nagy mennyiségű példány rekord módosítás indokolja. A mentés után indítható újra a TLSRV.

LELTELOK.EXE futási ideje a könyvtár állományának nagyságával arányos, ezért nagyszámú példány esetén relative hosszú lehet. Az idő becsléshez támpontként szolgálhat az adatbázis újraindexelési ideje.

Paraméterek

LELTELOK paraméterek

A program általában nem igényel paramétereket. Ha nem az összes példányt kívánjuk leltározandónak jelölni vagy ha nem a szokásos adatbázis környezetben indítjuk, akkor azonban igen.

Megadható paraméterek:

/Hdolg - Ha nem az összes példány rekordot akarjuk leltározni, akkor megadhatunk egy halmazt is. Ekkor a /H paraméter mögé szorosan írva meg kell adni annak a dolgozónak az azonosítóját, aki a feldolgozandó példány halmazt elmentette. Pl: LELTELOK /H0
/Ppath - path az adatbázis leírás kereséséhez: path\TLM\DBDESCS.TLM (alapértelmezés: \TEXTLIB)
/Dpath - path az adatbázis kereséséhez (alapértelmezés: /P szerint)
/Jpath - path napló kereséshez (alapértelmezés: \TEXTLIB\MENT)
/Lnév - LOG fájl neve (alapértelmezés: LELTELOK.LOG, hely /D szerint)
/Aigen - automatikus 'igen' minden kérdésre

Működés

Működése során a program a példány rekordokba bejegyzi, hogy leltározandó. Ha nem adunk meg halmazt, akkor az összesbe, ha megadnuk, akkor csak a halmazban szereplőkre. Ez a módszer használható pl. egy állomány leltározásához.

Kivételt képeznek, tehát nem leltározandók azok a példányok amelyek:

éppen kölcsönzésben ill. letétben vannak (ezeket a TextLib automatikusan leltározottnak tekinti, esetleges elvesztésüket a kölcsönzés keretein belül adminisztrálja). Ezekben a példányokban beállítja - LELTAROZVA:igen, de nem módosítja a LELTDATUM és LELTAROZO mezőket. Ezeket majd a visszavétel állítja be.
selejtezve (törlési jegyzőkönyvön) vannak ill. amelyeket selejtezésre jelöltek ki elvesztés, megsemmisülés miatt

Sikeres futás után a program feljegyzi a "Könyvtárunk adatai" rekordba, hogy a leltár előkészítés megtörtént. A program gondoskodik arról is, hogy az így előállt adatbázis-állapotot menteni kelljen.

A program sikeres futása és a mentés után a TextLibben indítható a leltározás.

A leltározás előkészítése - a LELTELOK program lefutása - után a leltározás lezárásáig újabb leltározás nem indítható.

1.2.3. TART_AKT: Késedelmi tartozásokat aktualizáló program

Célja

A program rendszerkarbantartási időben aktualizálja a késedelmi díjakat, hogy ne kelljen a rendszer futása közben a kölcsönző, visszavevő ill. hosszabbító modulokban az olvasó azonosítása után a tartozásainak aktualizálásával értékes on-line időt tölteni.

Működése

A program az összes olvasó végigjárásával azok valamennyi kölcsönzését elemzi, hogy nem képződött-e késedelmi tartozás, vagy nem változott-e egy már korábban létezett késedelmi tartozás összege. Ha szükséges, létrehozza ill. aktualizálja a tartozást, egyúttal az olvasó rekordján is átvezeti a változás(oka)t. Az olvasó rekordjában mindenképpen könyveli, a tartozások aktualizálásának megtörténtét (akkor is, ha nem képződött ill. nem változott késedelmi tartozás), hogy az olvasószolgálati modulok ne próbálják meg fölöslegesen aktualizálni a késedelmi tartozásokat.

Használata

Különálló program, akkor használható, mikor a TextLib rendszer nem fut. A programnak az általános program-paramétereken prgparam túl nincs(ennek) külön paramétere(i). Ha /? opcióval indítjuk, rövid ismertetést ad magáról.

Célszerű minden olyan könyvtárban használni, ahol többgépes rendszert üzemeltetnek és az olvasószolgálati forgalom jelentős.

Lehetséges alkalmazásai:

naponta történő, időzített automatikus rendszerleállítás után, a mentést végző batch-ben, a rendszer újraindítására szolgáló parancs előtt közvetlenül;
könyvtárnyitás előtt legalább fél órával a TextLib szerver gépen DOS-parancsként indítva.

1.2.4. PUCOL program

Az olvasószolgálati munka során nagy mennyiségben keletkeznek az egyes tranzakciókkal (kölcsönzés, előjegyzés, tartozás, felszólítás) kapcsolatos rekordok. Azt követően, hogy a kérdéses tranzakcióhoz tartozó valóságos folyamatok befejeződnek, a rekordok lezárttá válnak, további tárolásuk már csak az utólagos statisztikai feldolgozás céljából indokolt. Ezek megtörténte után ill. bizonyos idő elteltével a rekordok tárolására már egyáltalán nincs szükség. A rekordoknak az idők végezetéig való tárolása nem célszerű, hiszen bizonyos idő elteltével az adatbázis nagyobbik részét már ilyen rekordok teszik ki, így az adatbázis karbantartásával (mentésével, ellenőrzésével, indexelésével, stb.) kapcsolatos feladatok időigénye értelmetlenül nagyra nő.

Az olvasószolgálattal kapcsolatos, fölöslegessé vált, nagy mennyiségű, régi rekordtól a PUCOL program segítségével lehet megszabadulni. A programot off-line módon, azaz olyankor lehet futtatni, amikor a TextLib rendszert éppen nem használjuk. A program egyetlen paramétere az a dátum, amely előtti rekordok törlését kérjük:

PUCOL dátum

(A dátum megadása ÉÉÉÉHHNN alakban lehetséges, azaz az évszámot négy, a hónapot és a napot 2-2 jegy hosszban kell megadni.)

A program az egyes rekordok közül az alábbiakat törli:

azokat törli, amelyek a paraméterben megadott dátum előtt elévültek;

kölcsönzés rekordok: a paraméterben megadott dátum előtt megtörtént a visszavétel, és sem késedelmi, sem térítési díj típusú rendezetlen tartozás nem kötődik a kölcsönzéshez.
előjegyzés rekordok: - a soha ki nem elégített előjegyzések közül
a kielégített előjegyzések közül azokat törli, amelyeknél az előjegyzés kielégítésére használt példány olvasó számára történt félretételének dátuma a megadott dátum előtti.
tartozás rekordok: csak a rendezett tartozásokat törli, ezek közül is csak azokat, amelyek rendezése a megadott dátum előtt történt meg.
felszólítás rekordok: azokat a felszólításokat törli, amelyeken szereplő egyetlen tétel sem aktuális már, azaz minden a felszólításban érintett kölcsönzött példány vissza lett véve, ill. minden tartozás rendezve lett, és a felszólító levél dátuma a megadott dátum előtti.

1.2.5. ATADAS: Adatbázis átadó program

Célja

Ha az adatbázist más könyvtárnak akarjuk átadni, ki kell irtani belőle a felesleges rekordokat, a megmaradókat pedig megfelelően módosítani kell.

Használata

Különálló program, akkor használható, mikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

ATADAS opciók

/teszt - teszt módban fusson
/nojournal - ha nincs mentésünk az adatbázisról

LOG fájl

A program a futás végén összefoglalót ír az ATADAS.LOG fájlba, hogy milyen rekordokat törölt, és miket módosított.

Rekordok

A program a következő rekordokat irtja ki:

példányok
raktárak, állományok, dok.osztályok, leltárkönyv
dolgozók (kivéve a rendszergazdát), dolgozói csoportok
olvasók, olvasói kategóriák, személyek
paraméter rekordok
levelek
mentett találati halmazok
kölcsönzések, előjegyzések, felszólítások, letétek
tartozások
szerzeményezés dolgai (kínálat, rendelés, stb)
törlési jegyzékek
statisztikák

A megmaradó rekordokból kitörli a következő mezőket:

bevivő és módosító dolgozó
utolsó módosítás dátuma

A KÖNYVTÁR adatait leíró rekordból kitörli csaknem az összes mezőt, mivel azok a könyvtárra jellemzőek. A rekord maga nem törölhető, nélküle nem indulna el a TextLib.

A megmaradó rekordokban kitölti az IMPORT_AZON mezőt. Ha az átadott adatbázisba később az eredeti adatbázisból akarunk importálni, ez nagyon leegyszerűsíti majd a rekordok azonosítását.

1.3. Ellenőrző programok

1.3.1. IT_DIAG: indexfile ellenőrző program

Indexfájlok hibátlanságánal ellenőrzéséhez. Akkor érdemes foglalkozni vele, ha az indexfájlok gyanússá válnak.

1.3.2. DBF_LST: Rekord listázó

Célja

TextLib rekordok listázására alkalmas.

Használata

Különálló program, akkor használható, mikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

DBF_LST [/Ppath] [/Dpath] [/Nx] [Rdref] [/K] [/F|n1..|f1..]

/Ppath - path az adatbázis leírás kereséséhez. (def: \TEXTLIB)
/Dpath - path az adatfájlok kereséséhez. (def:/Ppath)
/K - lista az adatfájlok sorszámozásáról.
/F - lista az összes adat fájlról.
/Rdref - az adott dataref-ű rekordot írja csak ki
/Nx - mit NEM kell kinyomtatni a mezőből:
x = N - a mező nevét
T - mező típusát
I - ismétlődés számot
D - datarefek értékeit
F - dataref-ek feloldásait
S- semmit nem kell
R- datarefek ellenórzésének kikapcsolása
E- rekord ellenőrzés kikapcsolása
n1 n2 ... - listázandó fájl(-ok) sorszáma.
f1 f2 ... - listázandó fájl(-ok) neve.

1.3.3. NDX_LST: indexfile listázó

Célja

TextLib indexfájlok listázása

Használata

Különálló program, akkor használható, mikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

NDX_LST [/r] [/k] n|fname

n - az indexfájl sorszáma
fname - az indexset neve vagy az indexfájl rövid neve
/r - a posting láncot részletezi
/k - lista az indexfájlokról
/quiet - Csak a kulcsokat írja, semmi egyebet
/sdref - Dataref-nek a .xxx reszet nem irja ki
/longkey - a kulcsot teljes hosszban kiirja (egyebkent 58 hosszban)

1.3.4. FINDDREF: Dataref keresése rekordokban

Célja

A TextLib adatfájlokon végigmenve az összes rekord összes mezőjében keresi az adott rekord azonosítókat.

Használata

Különálló program, akkor használható, amikor a TextLib rendszer nem fut. Indítsuk el a programot a megfelelő paraméterekkel, ha nem tudjuk mik azok, akkor /? opcióval.

Használat: FINDDREF mit | @fájl [/Hazon [/teszt]

mit - mely dataref-et keresse
@fájl - fájlban a keresendők
azon - dolgozó halmazán
Pl: FINDDREF t3 FINDDREF @find.txt

Ha csak egy rekord azonosítót kell keresni, akkor érdemes ezt a parancssorban megadni. Ha több keresndő is van, akkor egy fájlban kell felsorolni, soronként egy dataref-et.

Ha nem az egész adatbázisra akarjuk ráereszteni a keresést, akkor be kell lépni a TextLibbe, ott előállítani a megfelelő halmazt, és elmenteni. Kilépve a TextLibből a FINDDREF-nek meg kell adni, kinek az elmentett halmazán dolgozzon (/Hazon - ahol 'azon' a dolgozó azonosítója)

1.4. Export-Import

1.4.1. TL_KULD: TextLib export program

Célja

A TL_KULD program segítségével egy találati halmazt (egy dolgozó elmentett halmazát) exportálhatjuk. A program egy szövegfájlt készít, amit általában egy másik adatbázisba töltünk a TL_VESZ program segítségével. Természetesen ettől eltérő felhasználása is lehetséges.

Használata

A TextLibben gyűjtsük össze egy találati halmazba azokat a rekordokat, amiket exportálni akarunk. Amikor ez megvan, mentsük el ezt a halmaz az eLment gomb segítségével (Vigyázat! Mindig az aktuális elmentett halmazt tudjuk exportálni), majd lépjünk ki a TextLibből.

A TL_KULD program indításakor egyetlen paramétert kötelező megadni, annak a dolgozónak az azonosítóját, akinek az elmentett halmazát exportálni akarjuk (általában a saját azonosítónkat).

Megadhatunk még más paramétereket is (lásd: Paraméterek), de erre elég ritkán van szükség.

Paraméterek

TL_KULD dolgozo [outfájl] [opcio] [opcio] ...

dolgozo - dolgozó kódja (vagy neve)
outfájl - Output fájl neve (def:dolgozo.TCS)
opcio - /Cfájl, /Ppath, /Dpath
/Cfájl - Export leíró fájl (def:TL_KULD.CFG)
/Ppath - Adatbázis szerkezet helye (def:\\TEXTLIB\\TLM)
/Dpath - Adatbázis fájlok helye (def:\\TEXTLIB)
/Nsorok - Hány sor után kezdjen új fájlt (def:100000)

Export leíró fájl

A program egy konfigurációs fájlból tudja, hogy milyen rekordot hogyan kell kiírnia az output fájlba. Abban van leírva, hogy mely rekordokat kell egyáltalán kiírni, és mely rekordnak mely mezőit. Ezt a fájlt először az aktuális könyvtárban keresi a program, ha itt nem találja, akkor megnézi ott is, ahol a TL_KULD.EXE van.

Az Export leíró fájl részletes leírása a expleir.txt (http://textlib.hu/html/rendszer/expleir.txt) fájlban található.

Output fájl

A program outputja TextLib Csere formátumú. Ez egy szövegfájl, amiben az exportált rekordokon kívül a küldéssel kapcsolat információk is megtalálhatók (Hány rekord van a fájlban, ki küldte, mikor, stb).

A TextLib Csere formátum a CSERE.TXT fájlban van részletesen leírva.

LOG fájl

Minden küldésnél a program készít egy ún. LOG fájlt, amibe mindenféle információkat kiír. Pl:

Mikor történt a küldés
Kinek a halmazát küldte, hány rekordot tartalmazott
Mely rekordokat NEM írta ki az output fájlba.
Mely rekordoknak került ki 0 mezője az output fájlba

A LOG fájl részletes leírása a KULDLOG.TXT fájlban található.

História fájl

A program készít egy história fájlt is, amiben az összes export fontosabb adatai fel vannak sorolva (Ki, mikor exportált, hány rekordos találati halmazból hány rekord került kiírásra és hány hivatkozott rekord volt).

A História fájl szerkezete igen egyszerű, magától értetődik. Abban a könyvtárban található, ahol a TL_KULD program, a neve pedig TL_KULD.HST

Hibaüzenetek

- Nincs adatbázis azonosító
A könyvtár adatai közt be kell állítani egy adatbási azonosítót. Erre azért van szükség, hogy a különböző adatbázisból származó rekordok megkülönböztethetők legyenek. Ellenkező esetben két külön adatbázisból kapott b3 azonosítójú rekordot megegyezőnek tekintene a program.

Hibakódok

A program futása után beállítja a DOS-ban az ERRORLEVEL változót. Ebből tudhatjuk, hogy milyen hibával ért véget a program.

0  - minden rendben volt
?? - hibakód

Működés

A program sorra veszi a találati halmaz rekordjait, és megvizsgálja a bennük szereplő hivatkozásokat is. Ha ki kell írnia a hivatkozott rekordokat is, akkor azokat a rekord elé rakja ki. Természetesen a többszörös mélységű hivatkozásokat is kezeli. A rekordnak azokat a mezőit, amik olyan rekordra hivatkoznak, amit nem kell kiírnia, nem írja ki. Azaz: ha egy kapcsolódó mező az A, B és C rekordokra mutató pointereket tartalmaz, de a B rekordokat nem kell a programnak kiírnia, akkor a mezőnek csak az A és C rekordokra mutató értékei kerülnek ki az output fájlba.

A rekord almezőit szintén a rekord elé írja is. Az almezőket 1-től indulva sorszámozza. Ez azért előnyös, mert így az almezők is egyedi 'rekord' azonosítót kapnak.

Lásd még

A DBSTRUCT program segítségével tudhatjuk meg, hogy az adatbázisban milyen adatfájlok, rekordtípusok és mezők vannak.

Várható fejlesztések

-- Más kódkészlet (pl: 852-es) használata

1.4.2. TL_VESZ: TextLib import program

Célja

A TL_VESZ program segítségével egy TextLib csere formátumú fájlban levő rekordokat tudjuk a TextLib adatbázisunkba betölteni.

Használata

A program indításakor egyetlen paramétert kötelező megadni, annak a fájlnak a nevét, amiben az importálandó rekordok vannak. A fájl kiterjesztését nem kötelező megadni, ha az .TCS

Megadhatunk még más paramétereket is (lásd: Paraméterek), de erre elég ritkán van szükség.

Paraméterek

TL_VESZ infile [opció] [opció] ...

infile - Input fájl neve, kiterjesztés elhagyható (default: .TCS)
opció - /Cfájl, /Ppath, /Dpath
/Cfájl - Import leíró fájl (default: TL_VESZ.CFG)
/Ppath - Adatbázis szerkezet helye (default: \\TEXTLIB\\TLM)
/Dpath - Adatbázis fájlok helye (default: \\TEXTLIB)
/Nmax - max ennyi rekord importálandó
/check - rekordok ellenőrzése

Import leíró fájl

Az Import leíró fájl részletes leírása a IMPLEIR.txt fájlban található.

Input fájl

A program inputja TextLib Csere formátumú. Ez egy szövegfájl, amiben az exportált rekordokon kívül a küldéssel kapcsolat információk is találhatók (Hány rekord van a fájlban, ki küldte, mikor, stb).

A TextLib Csere formátum a <CSERE.txt> fájlban van részletesen leírva.

LOG fájl

Minden import alkalmával a program készít egy ún. LOG fájlt, amibe mindenféle információkat kiír. Pl:

Mikor történt az import.
Honnan jöttek a rekordok, hány rekord jött.
Mely rekordokat hagyta ki a feldolgozásból,
Hány új rekord vett fel, hányat módosított, hányat dobott el.

A LOG fájl neve az importálandó fájl neve, .LOG kiterjesztéssel. A fájl részletes leírása a <VESZLOG.txt> fájlban található.

História fájl

A program készít egy história fájlt is, amiben az összes import fontosabb adatai fel vannak sorolva (Mikor mennyit importáltunk).

A História fájl felépítése magától értetődő, TL_VESZ.HST néven abban a könyvtárban találjuk, ahol a TL_VESZ program is van.

Rekordba írt rendszer megjegyzések

Az import során a program több rekord rendszer megjegyzés mezőjébe is ír szövegeket. Ezek kivétel nélkül a # karakterrel kezdődnek. Egy import után a LOG fájl megnézése után ezeket a rekordokat érdemes lekeresni, és megnézni.

#!törlendő - A rekordot törölni próbálta a program, de a hivatkozások miatt ez nem sikerült. Ezek elbontása után a rekord törölhető.
#!megszűnt - A program rájött, hogy a küldő adatbázisban ez a rekord már nem létezik, ezért törölni akarta. Ez nem sikerült. Ha a rekord valóban nem kell már, a kapcsolatok elbontása után törölhető. Az XXXX.nnn alakú rekordazonosítóból lehet tudni, hogy az nnn-nél kisebb sorszámú XXXX.mmm rekordok törlődtek.
#!Üres maradt - A rekordra hivatkoztak, ezért a program létrehozta, de a rekord később sem volt benne az input fájlban. Valószínűleg az input fájl hibás, sérült, rosszul készítették.
#!nnnn!rrr - Egy oda-vissza kapcsolódó rekord elszakadt a párjától. (pl: a kötet a közös adatától). Az nnnn sorszámú mezőjében kapcsolódott az rrr azonosítójú rekordhoz. Ilyen esetben vagy a rekord törlése szükséges, vagy a visszakapcsolása. A megjegyzést ezután ki kell törölni.

Hibakódok

A program futása után beállítja a DOS-ban az ERRORLEVEL változót. Ebből tudhatjuk, hogy milyen hibával ért véget a program.

0  - minden rendben volt
?? - hibakód

Működés

A program beolvassa az input fájlban található rekordokat. Azokat, amikkel nem kell semmit csinálnia (az import leíró fájlból tudja) eldobja. A többit pedig a megadott utasítások szerint feldolgozza. Menet közben számolja, hogy hány új rekordot vett fel, hányat módosított, és hányat hagyott érintetlenül.

A problémás rekordokat kétféle módon kezeli:

LOG fájlba kiírja, hogy melyik rekorddal milyen baja volt.
rekordba berak egy MEGJEGYZESt, ami alapján a rekord később visszakereshető lesz. A megjegyzések általános formája: ##szöveg:dátum

Lásd még

A DBSTRUCT program segítségével tudhatjuk meg, hogy az adatbázisban milyen adatfájlok, rekordtípusok és mezők vannak.

Várható fejlesztések

Más kódkészlet (pl: 852-es) használata

1.4.3. HM_KULD: Hunmarc export program

Célja

A HM_KULD program segítségével egy találati halmazt (egy dolgozó elmentett halmazát) exportálhatjuk Hunmarc formátumban.

Használata

A TextLibben gyűjtsük össze egy találati halmazba azokat a rekordokat, amiket exportálni akarunk. Amikor ez megvan, mentsük el ezt a halmazt az eLment gomb segítségével majd lépjünk ki a TextLibből.

Figyelem!
Több elmentett halmazból mindig az aktuálisat tudjuk exportálni.

Figyelem! Az export végrehajtásához a dokumentum típusú rekordokat (pl. könyv kötet, audiovizuális kötet, disszertáció, stb.) szükséges és elégséges a találati halmazba összegyűjteni. A dokumentum által hivatkozott személyek, testületek, földrajzi nevek, sorozati adatok, stb. automatikusan bekerülnek a HunMarc rekordba.

A HM_KULD program indításakor egyetlen paramétert kötelező megadni, annak a dolgozónak az azonosítóját, akinek az elmentett halmazát exportálni akarjuk (általában a saját azonosítónkat).

Megadhatunk még más paramétereket is (lásd: Paraméterek), de erre elég ritkán van szükség.

Paraméterek

HM_KULD dolgozo [outfile] [opcio [opcio] ...

dolgozo - dolgozó kódja (vagy neve)
outfile - Output fájl neve (def:dolgozo.HM)
opcio - /Cfájl, /Ppath, /Dpath
/Cfájl - Export leíró fájl (def:HM_KULD.CFG)
/Ppath - Adatbázis szerkezet helye (def:\\TEXTLIB\\TLM)
/Dpath - Adatbázis fájlok helye (def:\\TEXTLIB)

Export leíró fájl

Figyelem!
Az output fájl karakterkészletét is az export leíró fájlban lehet megadni. Ha ext nem tesszük, akkor az MNB CD (ez a 852-es) karakterkészletét használja a program.

Output fájl

A program outputja Hunmarc formátumú, a mezőkbe került szövegek kódkészlete az export leíró fájlban megadottnak felel meg. A TextLib karaktereket a program <HM_CHAR> szerint konvertálja a HunMarc szövegállományba.

Figyelem!
Amennyiben az output fájl karakterkészletének a CWI-t adta meg, tartalmi veszteséggel kell számolnia, ugyanis a TextLibben értelmezett, de CWI-ben nem értelmezett karakterek a konvertálás során elvesznek.
A TextLib és HunMarc rekordok közötti mező-mező megfeleltetést <HM_MEZO> írja le.

LOG fájl

Minden küldésnél készít a program egy ún. LOG fájlt, amibe mindenféle információkat kiír. Pl:

Mikor történt a küldés
Kinek a halmazát küldte, hány rekordot tartalmazott
Mely rekordokat NEM írta ki az output fájlba.
Mely rekordoknak került ki 0 mezője az output fájlba

A LOG fájl részletes leírása a <KULDLOG.txt> fájlban található.

História fájl

A História fájl szerkezete igen egyszerű, magától értetődik. Abban a könyvtárban található, ahol a HM_KULD program, a neve pedig HM_KULD.HST

Hibakódok

A program futása után beállítja a DOS-ban az ERRORLEVEL változót. Ebből tudhatjuk, hogy milyen hibával ért véget a program.

0  - minden rendben volt
?? - hibakód

Működés

A program sorra veszi a találati halmaz rekordjait, és a rekord mezőiből, valamint a hivatkozott rekordok mezőiből elkészít egy Hunmarc rekordot.

Lásd még

A DBSTRUCT program segítségével tudhatjuk meg, hogy az adatbázisban milyen adatfájlok, rekordtípusok és mezők vannak.

1.4.4. HM_VESZ: HunMarc import program

Célja

A HM_VESZ program segítségével egy HunMarc formátumú fájlban levő rekordokat tudunk a TextLib adatbázisunkba importálni.

Használata

A program használatához egy paramétert kötelező megadni: az importálandó HunMarc rekordokat tartalmazó állomány nevét. Megadhatunk még más paramétereket is (lásd: Paraméterek), de erre elég ritkán van szükség.

Paraméterek

HM_VESZ infile [opció] [opció] ...

infile - a HunMarc fájl neve
opció
/Cfájl - az import leíró fájl neve (default: HM_VESZ.CFG)
/Ppath - az adatbázis szerkezet leírás helye (default: \TEXTLIB\TLM)
/Dpath - az adatbázis fájlok helye (default: \TEXTLIB)

Import leíró fájl

A program egy konfigurációs fájlból tudja, hogy milyen rekordot hogyan kell kezelnie. Abban van leírva, hogy mely rekordokat kell eldobnia, újként felvennie, módosítani. Az egyes rekordok kezelésének módja is itt van megadva (mely mezővel mit kell csinálni). Az import leíró szövegállomány szerkezete azonos, tartalma pedig lehet azonos a TextLib adatbázisok közötti importot végrehajtó TL_VESZ.EXE program import leíró állományával. Ezt a fájlt először az aktuális könyvtárban keresi a program, ha itt nem találja, akkor megnézi ott is, ahol a HM_VESZ.EXE van. Az Import leíró fájl részletes leírása a <IMPLEIR.txt> fájlban található.

Input fájl

A program inputja HunMarc formátumú. Ez egy szövegfájl, szerkezetét az Országos Széchenyi Könyvtár által Budapesten 1994-ben kiadott "HunMarc: a bibliográfiai rekordok adatcsere formátuma" című kiadvány írja le. A szabvány nem köti meg a HunMarc állományban alkalmazható karakterkészletet, a HM_VESZ.EXE program egyelőre négyféle készlet fogadására készült fel:

az MNB CD rekordjaiban találhatóra,
az OSZK által floppyn szolgáltatott, az állomány nevének utolsó karakterében egyest tartalmazó rekordokban találhatóra (pl. KB51011.MNB).
az OSZK által floppyn szolgáltatott, az állomány nevének utolsó karakterében .... tartalmazó rekordokban találhatóra (pl. KB5101..MNB). (OSZK 852)
CWI kódkészletű rekordokra.

Az import szövegállomány kódkészletének megadását az import leíró fájl felépítését ismertető <IMPLEIR.txt> állományból ismerheti meg. A használható elnevezések: MNBCD, OSZK1, OSZK2 és CWI. Ha nem adja meg, az alapértelmezés MNBCD lesz. Az import szövegállomány karaktereit a program <HM_CHAR> szerint konvertálja a TextLibbe. A HunMarc és TextLib rekordok közötti mező-mező megfeleltetést <HM_MEZO> írja le.

LOG fájl

Minden import alkalmával a program készít egy ún. LOG fájlt, amibe mindenféle információkat kiír. Pl:

Mikor történt az import.
Honnan jöttek a rekordok, hány rekord jött.
Mely rekordokat hagyta ki a feldolgozásból,
Hány új rekordot vett fel, hányat módosított, hányat dobott el.

A LOG fájl neve az importálandó fájl neve, .LOG kiterjesztéssel. A fájl részletes leírása a <VESZLOG.txt> fájlban található.

História fájl

A program készít egy história fájlt is, amiben az összes import fontosabb adatai fel vannak sorolva (Mikor mennyit importáltunk). A História fájl felépítése magától értetődő, HM_VESZ.HST néven az adatbázis könyvtárában találjuk.

Rekordba írt rendszer megjegyzések

Az import során a program több rekord rendszer megjegyzés mezőjébe is ír szövegeket, minden esetben #HM kezdetűt. Magyarázatukat <hm_megj> tartalmazza. Egy import után a LOG fájl megnézése után ezeket a rekordokat érdemes lekeresni, és megnézni.

Hibakódok

A program futása után beállítja a DOS-ban az ERRORLEVEL változót. Ebből tudhatjuk, hogy milyen hibával ért véget a program.

0  - minden rendben volt
?? - hibakód

Működés

A problémás rekordokat kétféle módon kezeli:

a LOG fájlba kiírja, hogy melyik rekorddal milyen baja volt.
a rekordba berak egy MEGJEGYZESt, ami alapján a rekord később visszakereshető lesz. A megjegyzések általános formája: ##szöveg

Lásd még

A DBSTRUCT program segítségével tudhatjuk meg, hogy az adatbázisban milyen adatfájlok, rekordtípusok és mezők vannak.

1.4.5. MOKKABA

Hunmarc export - MOKKA-ba küldéshez

Célja

A MOKKABA.BAT segítségével egy találati halmazt (egy dolgozó elmentett halmazát) exportálhatjuk HunMarc formátumban, hogy az a MOKKA-ba küldéshez a lehető legjobb legyen.

Használata

Használata megegyezik a HM_KULD programéval, mivel ez a batch is azt a programot hívja. A különbség csak a default konfigurációs fájl (mokkaba.cfg) és a default log fájl (mokkaba.log).

1.4.6. MOKKABOL

Hunmarc export - MOKKA-ból érkezett rekordokra

Célja

A MOKKABOL.BAT segítségével egy HunMarc formátumú fájlban levő rekordokat tudunk a TextLib adatbázisunkba importálni.

Használata

Használata megegyezik a HM_VESZ programéval, mivel ez a batch is azt a programot hívja. A különbség csak a default konfigurációs fájl (mokkabol.cfg) és a default log fájl (mokkabol.log).

HunMarc rekordok

Fontos, hogy ha MOKKA-ból töltönk le rekordokat (pl. a WEB-es felületről), akkor azokat HunMarc bináris formátumban, lehetőleg ALA/ANSEL karakterkészletben töltsük le. A mokkabol.cfg ennek megfelelően van beállítva.

1.4.7. TL_VESZ.CFG és a HM_VESZ.CFG

A TL_VESZ.CFG és a HM_VESZ.CFG olyan fegyver, amellyel az import lefolyását szinte tetszőlegesen befolyásolhatjuk, a beállítások végtelen lehetősége pedig garantálja, hogy a betöltendő rekordok és a fogadó adatbázis egy hibátlan egységet alkothasson. Egy tényező mégis gátat szabhat törekvésünknek, az pedig a csereállomány, az importálandó rekordok állományának minősége.

Amennyiben a betöltendő szöveg hiányos vagy hibás, akkor az gyakran már az import végén kiderül, és elkerülhetetlenül nyoma marad az adatbázisban is. A betöltés befejeződésekor gyakran léthatunk az alábbi szöveghez hasonlót a képernyőn vagy a .LOG szöveg végén:

!! Fel nem oldott hivatkozás:113 !! (Rendszer megj. alapján kereshető)

A figyelmeztetés oka, hogy a program 113 esetben kapcsolatot épített volna ki két rekord között, de a párok egyik tagját nem találta meg a betöltött zövegben. Tehát pl. egy többkötetes könyvnek vagy a közös adata vagy valamelyik kötete hiányzik, pedig a hivatkozás szerint léteznie kell. A hiányzó rekordokat az import üresen létrehozza, és a rendszer megjegyzés mezőbe beírja a hibát:

#HM:üres maradt
#!üres maradt

Az első a HunMarc, a második a TextLib rekordok hibájának következménye. A jelenség megszüntetéséhez az exportba kell beleavatkozni, amit a HunMarc állományoknál általában nem tudunk megtenni. Tegyünk egy kis kitérőt a probléma részleteinek áttekintésére!

Kiindulópont a rekordok kapcsolata. A TextLib adatbázisban rengeteg féle rekord tud egymással kapcsolatba kerülni, mindazok, amelyek bevitelekor a mezőbe beszúrással kell folytatni a munkát: közös és kötet, kötet és példány, kötet és szerző, kötet és sorozat, testület és névváltozata, olvasó és kategóriája, szóval akár százával sorolhatnánk. A HunMarcban ez a dolog sokkal egyszerűbb, csak közös és kötet, kötet és analitika valamint közös és/vagy kötet és sorozat kapcsolat létezik. A kapcsolatok lehetséges számától függetlenül akkor működhet jól az import program, ha az összekapcsolandó rekordok mindegyike megvan vagy a csereállományban vagy a fogadó adatbázisban. A feltétel teljesülését az export garantálhatja, ha minden összekapcsolni kívánt rekordot elhelyez a csreállományban. Látható tehát, hogy a TextLib export-import műveletében a kulcs a mi kezünkben van.

Más a helyzet a HunMarc rekordokkal, a csereáálományt készen kapjuk (vesszük), megváltoztathatatlan tartalommal. Ezekben a fájlokban háromféle olyan hiba szokott előfordulni, ami a kapcsolatok felépülésének elmaradásához vezet:

Hibás a bibliográfiai szint megjelölése
A HunMarcban egy külön jel fejezi ki a bibliográfiai szintet, hogy a rekord sorozat, közös adat, kötet vagy analitika. Hibás a jelölés, ha pl. egy sorozat rekordot kötetként ábrázolnak a csereállományban. Az import kínjában a kötet és sorozata kapcsolat helyett egymástól független kötetet és közös adatot hoz létre, és készít egy üres sorozat rekordot is - hiszen a hivatkozás szerint erre szükség van -, ami üresen is marad, mert a téves szint jelölés miatt a rekord nem található meg.
Hibás a rekordazonosítók megadása
Elemi feltétel, hogy a hivatkozás helyén és a hivatkozott rekordban az azonosító pontosan ugyanaz a karaktersorozat legyen. Ha ez nincs így, akkor az import program képtelen megtalálni egy pár egymáshoz tartozó tagjait. A legutóbb vizsgált HunMarc állományban pl. a hivatkozás helyén a
```
787 0
$w 796630
```
szöveg, a hivatkozottban pedig
```
001 000000796630
```
szerepelt azonosítóként. Az emberi szem jól érzékeli a szándékot, de a programnak ez sajnos kevés.
Hiányzik a kapcsolódó rekord
Az OSZK rekordszolgáltatása a forrás adatbázis változásait tartalmazza. Így könnyen előfordulhat a csereállományban egy olyan közös rekord, amelyik 6 kötetre hivatkozik, és azok közül csak egyetlen kötet van meg, az éppen most új. A közös azért szerepel, mert megváltozott, belekerült egy hivatkozás a 6. kötetre, a kötet pedig új. Hiányzik viszont a csereállományból öt kötet, amelyek a korábbi importok során már bekerülhettek a fogadó adatbázisba. Nincs is semmi baj a régi előfizetőknél, csak azoknál, akik mostanában próbálnak bekapcsolódni.

A vásárolt, kapott, szerzett, stb. csereállomány minőségéről nem egyszerű meggyőződni. Segíthet a HUNDIR.EXE nevű program, ami HunMarc rekordokat olvasmányos formára alakít, és abban a szabvány ismerői már könnyen eligazodnak. Még könnyebb meglátni a hibát a fogadó adatbázisban. Egyrészt a rendszer megjegyzés mezőbe íródó szöveg alapján kereshetők az üresen maradt rekordok, másrészt a hivatkozás helyén a mezőben három kérdőjel látszik.
Eddig az importot befolyásolhatatlanul meghatározó elemről, a csereállományról esett csak szó, ideje rátérni a címben ígért témára. A TL_VESZ.CFG és a HM_VESZ.CFG egyszerű szövegállomány, leggyakoribb helye a \TEXTLIB\EXE könyvtár, feladata a TextLib valamint a HunMarc formátumú csereállományok betöltésének vezérlése. Ez a vezérlés nagyon sok mindent jelent, nézzük először röviden:

szabályozza a karakterkonverzió módját,
dönt a betöltés céljáról,
meghatározza a cédulanyomtatás miatt adatbázisba került jelek sorsát,
kijelöli a betöltendő adatfájlokat és/vagy rekordtípusokat,
meghatározza az érkező és a bent levő rekordok összehasonlításának szempontjait,
szabályozza az adatbázisba kerülés módját.
kijelöli a betöltendő mezőket

Az import végeredményét a vezérló állomány tartalmának módosításával szélsőséges határok között változtathatjuk. A betöltendő állomány és a fogadó adatbázis tartalmának ismeretében sem mindig egyszerű feladat olyan .CFG-t készíteni, amelyik éppen az elvárt végeredményhez vezet. Közismert hiba a rekordok indokolatlan többszöröződése vagy eltűnése, és az összetartozó rekordok elszakadása vagy a nem összetartozók összekapcsolódása.

Rengeteg rossz .CFG van forgalomban, és azok közül több is az InfoKertől származik. Ezek speciális célokra jók lehetnek, de sok helyzetben biztosan adatbázis hibákat okoznak. Két szabályt feltétlenül be kell tartani az importáláskor:

Egy kész .CFG állományt csak alapos átnézés után szabad használni!
A betöltés végén az adatbázist és a műveletet naplózó .LOG szöveget részletesen ellenőrizni kell! Legtöbbször már a betöltött és a beérkezett rekordok számának eltéréséből is levonhatók következtetések.

Induljunk tiszta lappal, készítsünk egy TL_VESZ.CFG állományt az elejétől kezdve! Szükségünk van egy egyszerű szövegszerkesztőre, mint amilyen pl. az EDIT a DOS-ban, a Jegyzettömb vagy a WordPad a Windowsban. Sok formai szabályt be kell tartanunk, az érdemi részek rögzített készletből választható kulcsszavak, amelyekben egyetlen "helyesírási" hiba sem lehet. Ha az import program nem képes értelmezni a szövegünket, akkor kiírja az elsőként talált hibás sor számát, és leáll.
A .CFG állományban elhelyezhetünk saját magunk számára megjegyzéseket, az erre a célra szánt sorokat kezdjük # karakterrel. A legelső nem megjegyzés sor tartalma kötelező:

TextLib Import leiro file - InfoKer 1995

A karakterkonverzió módja

A csereállomány egy szöveg, amely a kibocsátó szándéka szerinti kódkiosztásban ábrázolja a karaktereket. Főként a diakritikus jellel írt betűknél számít a kódkiosztás ismerete, ez ugyanis a feltétele annak, hogy a betöltés után az eredetivel azonos betűkép jelenjen meg a TextLibben. Az import program többféle konverzióra képes, elbánik a csereállománnyal ha az CWI, MNBCD vagy OSZK1 kódolású. (A TextLib export eredménye mindig CWI kód, a HunMarc rekordoké pedig MNBCD - egy módosított 852-es - vagy OSZK1 lehet. E kettő között könnyű különbséget tenni: az OSZK1 a diakritikus jeleket külön karakterhelyen ábrázolja, így minden ékezetes betű kétkarakteres, és olvashatatlan.)
Mivel nincsenek a szövegeknek olyan ismérvei, amelyek alapján a program teljes biztonsággal azonosíthatná a kódolást, nekünk kell megadni a TL_VESZ.CFG vagy HM_VESZ.CFG állományban a karakterkonverzió módját a 2. sorban (a három közül természetesen csak egyet):

Kodkeszlet:CWI
Kodkeszlet:MNBCD
Kodkeszlet:OSZK1

A betöltés célja Az importot vezérlő szövegben (általában TL_VESZ.CFG vagy HM_VESZ.CFG) háromféleképpen rendelkezhetünk a betöltés céljáról:

törlés (az exportált rekordokat a fogadó adatbázisból törölni kell)
bevitel (az exportált rekordokat be kell vinni a fogadó adatbázba)
módosítás (az exportált rekordokkal módosítani kell a fogadó adatbázist)

A betöltés célját meghatározó sorként a következők egyike használható a .CFG-ben:

Cel:T
Cel:B
Cel:M

Mindhárom esetben fontos alapelv, hogy az érkező és a már bent levő rekordok azonosságát vizsgálni kell, ezt pedig az import program természetesen meg is teszi. Az összehasonlítás eredményétől függ a művelet, a változatokat a következő táblázat foglalja össze:

.	Törlés	Bevitel	Módosítás
A művelet, ha azonosak	törlés	-semmi-	módosítás
A művelet, ha különbözők	-semmi-	bevitel	bevitel

Látható, hogy az importot alapvetően befolyásolni képes a megjelölt cél, az esetek túlnyomó részében mégsem nehéz a választás, hiszen a módosítás a leggyakoribb feladat. A program alapértelmezett működésmódja is ez, a cél megadásának hiányában módosítást végez.

A speciális jelek sorsa Ezek a speciális jelek valóban nagyon speciálisak, kizárólag HunMarc állományokban fordulnak elő. Azokban a könyvtári rendszerekben, amelyek a TextLibbel ellentétben képtelenek szabványos katalóguscédula nyomtatására, a program hiányosságát gyakran a nyomtatáshoz szükséges jelek mezőbe rögzítésével szüntetik meg. Így kerül a szabályosan leírt adat mögé a " /", a " :", a " ;", stb. Ezeket - mivel teljesen fölöslegesek - az import program levágja, ha akarjuk. Erre szolgál a

Teljesmezo:I
Teljesmezo:N

bejegyzések egyike a .CFG következő sorában. "I" jelenti, hogy szükségünk van a teljes, csonkítatlan mezőre, meg kívánjuk tartani a speciális jeleket is, "N" pedig azt, hogy nem. Nem követünk el hibát, ha a

Teljesmezo:N

sort mindig beírjuk a .CFG-be, TextLib importnál fölösleges, de nem zavar, HunMarc betöltésnél pedig vág, ha van mit.
Eddig négy érdemi sora van a tervezett .CFG-nek, valahogy így:

TextLib Import leiro file - InfoKer 1995
Kodkeszlet:CWI
Cel:M
Teljesmezo:N

Ha ebben valamit elrontunk, hibaüzenetet kapunk a betöltés elindításakor, és a program le is áll. A felsorolás hibaüzenetei mind a .CFG bevezetőjében elkövetett betűhibákra mutatnak:

!!   1.HIBA (313): Rossz leíró fájl / c:\textlib\exe\tl_vesz.cfg (1. sor)  !!
!!   1.HIBA (318): Rossz 'Kodkeszlet:' sor / CVI (2. sor)  !!
!!   1.HIBA (319): Rossz 'Cel:' sor / N (3. sor)  !!
!!   1.HIBA (344): rossz 'Teljesmezo:' sor / M (4. sor)  !!
!!   1.HIBA (314): Rossz sor / Tejesmezo:N (7. sor)  !!

Az eddigiekben a művelet egészét befolyásoló, általános érvényú szabályokat írtunk le. A továbbiakban már figyelembe kell vennünk a csereállomány és a fogadó adatbázis tartalmát, hogy akár mezőnként rendelkezhessünk a bekerülés módjáról. Induljunk ismét egy picit messzebbről!

A betöltendő adatfájlok és rekordtípusok A TextLibbel dolgozók sok hasonlóságot találnak az eltérő célokra szolgáló űrlapok között. Rokonai egymásnak a különböző dokumentumtípusok beviteli formátumai a képernyőn, és még az eltérő bibliográfiai szinthez tartozók is gyakran hasonlítanak egymásra. A könyv kötet beviteli ablak rengeteg mezője visszaköszön egy másik dokumentumtípusnál, pl. a térkép részegységnél és annak egy másik bibliográfiai szintjénél, a térképek közös adatánál is. A hasonlóság oka az, hogy ezek az űrlapok bár sokfélék, de egyetlen közös logikai szerkezeten alapulnak, amit a TextLib rekordtípusnak nevez. Ugyanabba a rekordtípusba tartoznak tehát az azonos adategyüttessel leírható rekordok, mint pl. a sokféle dokumentumtípusé, a különböző osztályozásoké vagy tárgyszavaké, stb. (Természetesen nem kötelező minden űrlapon szerepelni a rekordtípus összes mezőjének. Pl. a kötetnek van közös adata és példánya, ellenben a közösnek nincs. Van viszont kötete, ami a kötetnek nincs, és sorolhatjuk százával a példákat.)
Ha tudjuk, hogy egy kitöltött űrlap tartalmából a TextLib adatbázisában rekord lesz, akkor érthetővé válik egy újabb fogalom, az adatfájl. Ez nem más, mint a rekordok tárolási helye. Az eltérő tárolási hely alapján tud a program különbséget tenni az azonos rekordtípushoz tartozó, tehát egymáshoz nagyon hasonló felépítésű adategyüttesek között. Az eddigiekből nem következik, de természetesen igaz, hogy nem kötelező több adatfájl rekordjainak logikai felépítését összevonnni egy rekordtípusba. Pl. az ALKOTO rekordtípusba kizárólag az azonos nevű, tehát szintén ALKOTO adatfájl rekordjai tartoznak.
Az adatcsere programok ismerik a két fogalmat, így nekünk is ismernünk kell, ha e fontos képességet ki akarjuk használni. Az export és import műveletében a program válogatni tud kiküldéskor és betöltéskor is a rekordok között. Ehhez jó kiindulópont a rekordtípus vagy az adatfájl. Szabadon dönthetünk, hogy mivel foglalkozzon és mivel ne az adatcsere. Elhatározásunkat a .CFG-ben írjuk le a következőhöz hasonló módon:

&r DOKUMENTUM
&d DOK
&d KOTET
&d AUDIOKOTET

A bevezető "&" karakter kötelező, mögötte az "r" rekordtípust, a "d" pedig adatfájlt jelent. Amennyiben a .CFG tartalmaz "&r" vagy "&d" kezdetű sort, akkor azt az utána megnevezett adatfájlra vagy rekordtípusra vonatkozó parancsnak tekinti, miszerint törődni kell vele. Megfordítva: az export sem és az import sem figyel azokra a rekordokra, amelyek a felsorolt adatdfájlok vagy rekordtípusok között nem szerepelnek, hanem azokat egyszerűen kihagyja a műveletből.
A fenti példák sorai kizárólag az írásmódot tekintve helyesek, semmiképpen sem következhetnek a valóságban közvetlenül egymás után. Bármelyik sor csak lényeges kiegészítésekkel együtt válik értelmessé, természetesen azokról is lesz szó a későbbiekben.

Az első sor szerint minden olyan adategyüttessel van tennivalója az adatcserének, amelyik a dokumentum rekordtípusba tartozik. Márpedig ebből elég sok van:

Könyv közös adat
Könyv kötet
Tanulmány
AV közös adat
Audiovizuális
AV részdokumentum
Időszaki kiadvány
Cikk
Cikk közös adat
Térkép közös adat
Térkép
Térkép részdokumentum
Disszertáció közös adat
Disszertáció
Kotta közös adat
Kotta kötet
Kotta részdokumentum
Kutatásjelentés közös adat
Kutatásjelentés
Szabadalom
Szabadalmom részdokumentum
Egyéb dokumentum közös adat
Egyéb dokumentum
Egyéb részdokumentum
Program közös adat
Program
Program részdokumentum
Kézirat közös adat
Kézirat
Szabvány
Szabvány részdokumentum

Amennyiben a közös kezelés nem felel meg - és hogy miben, arról az összehasonlítás szempontjainál lesz szó - akkor minden egyes adatfájl rekordjairól külön rendelkezhetünk, ahogy ezt a példa 2-4. sora mutatja. A program ésszerűen kezeli a kivételeket: ha adatfájlra érvényes leírást készítünk, akkor a program a szerint jár el. Így a példában a DOK (könyv közös adat), KOTET (könyv kötet) és az AUDIOKOTET (audiovizuális kötet) adatfájl rekordjait másképp kezelheti, mint az egyéb DOKUMENTUM rekordtípusba tartozó rekordokat. Amennyiben pedig az első sort elhagyjuk, akkor az összes DOKUMENTUM rekordtípusba tartozó adategyüttes közül csak a DOK, a KOTET és az AUDIOKOTET rekordokat veszi tekintetbe az adatcsere.

Fontos tudni, hogy TextLib rekordok importjához a rekordokba beépült, almezőnek nevezett szerkezeti elemek leírását is el kell készíteni. A legfontosabb ilyenek az alábbiak:

&r CIMADAT
&r PARHCADAT
&r ETO_ALM
&r KOZREMUKODO
&r KIADAS
&r NYOMTATAS
&r SOROZATLEIRAS
&r MELLEKLET

A rekordtípusok és adatfájlok ismeretében aprólékosan szabályozhatjuk az export-import műveletébe bevonandó rekordok körét. A rekordtípus általában a nagyobb bugyor, az adatfájl pedig a kisebb. A .CFG-ben használható nevek az adatbázisszerkezet leírásából (DBSTRUCT.EXE) választhatók.
Végezetül egy példa arra, hogy egy adatfájl és egy rekordtípus neve lehet azonos is. Az első sor rekordtípust jelent, így a .CFG tetszőleges dokumentumtípus példányára vonatkozik. A 2. sor a PELDANY (könyv példány) adatfájl rekordjairól rendelkezik, a 3. (AUDIOPELDANY) az audiovizuális dokumentumok, a 4. (IDOPELDANY) pedig az időszaki kiadványok példányairól.

&r PELDANY
&d PELDANY
&d AUDIOPELDANY
&d IDOPELDANY

Az összehasonlítás szempontjai Ahogy az import program egymás után dolgozza fel a rekordokat, mindegyikről döntést kell hoznia, mi történjen vele. Korábban részletezett két tényező, az import célja és az adatfájlról és/vagy rekordtípusról leírt rendelkezés alapjában befolyásolja a történést. Most azonban újabb szemponthoz érkeztünk.

A fogadó adatbázis tartalmának is meghatározó a szerepe. Az importtól a célként megjelölt viselkedést várjuk el, a kijelölt rekordokat törölje vagy módosítsa, és csak akkor vigyen be újként valamit, ha az még nincs meg a mi adatbázisunkban. A helyes viselkedéshez a fogadó adatbázisban keresni kell az érkezővel azonos reköordo(ka)t, és a találat ténye továbbá az import célja együtt határozza meg a további tennivalókat. A kereséshez pedig előre kiválasztott mezőket használ a program, és azok tartalmának összehasonlítása után dönt az egyezőségről.
Az összehasonlítás szempontjainak meghatározásánál tehát a cél az egyértelműség: mutatkozzon két rekord azonosnak, ha valóban az, és lássék különbözőnek, ami különbözik. Nem akarhatjuk, hogy újkent bekerüljön az adatbázisunkba az, ami már ott is megvan, es persze azt sem, hogy az érkező rekord átírjon egy meglevőt, holott semmi közük egymáshoz. Mint kiderül majd, ez egy csöppet sem egyszerű feladat. Követhetünk el hibát mindkét irányban, és készítünk is .CFG-t, ami ezt bemutatja.
A vezérlő állományban aprólékosan szabályozhatjuk, hogy mit vizsgáljon az import program, amikor két rekordot összehasonlít. Szinte tetszőleges mezőket jelölhetünk ki, azoknak a tartalmát veti egybe a program páronként az érkező és már meglévő rekordokban. Az erre vonatkozó utasítást az "Azonosito" szóval kell kötelezően kezdeni, és ahogy a következő példa is mutatja, mindig az adatfájl és/vagy a rekordtípus megjelölésével együtt érvényes.

&r PELDANY
Azonosito:VONALKOD

A nagyon egyszerű leírás szerint a PELDANY rekordtípus rekordjainak - azaz bármelyik dokumentumtípus példányainak - kereséséhez és összehasonlításához egy mezőt használ az import, az Azonosító (VONALKOD) nevűt. Biztonságosan elegendő ez, hiszen a TextLibben a példányok Azonosító mezője kötelező és egyedi. Minden olyan adatfájl vagy rekordtípus esetében elintézhetjük ilyen egyszerűen az azonosítást, amelyben létezik egy egyértelmű azonosító. Ilyen pl. a többféle osztályozás és tárgyszó, sokféle rendszerelem (jog, keresőkérdés, rendezési formátum, nyomtatási formátum, stb.), stb.
Haladjunk összetettebb esetek felé, már csak azért is, mert a példányok importja ritka feladat. A következő példa rögtön az import program egy jellegzetességére is rámutat, ami sajnos gyakran adatbázis hibához vezet.

&r FOLDRAJZ
Azonosito:MEGNEVEZES

Ránézésre ez sem bonyolult, mégis érdemes foglalkozni ezzel a több .CFG-ben is előforduló hibás sorral, ami a rekordok többször tárgyalt sokszorozódásához vezet (Lásd a 4. hírlevelet, "A besorolási adatok egységesítése" címnél is!). A hiba kiindulópontja az a tény, hogy a földrajz rekordokban a Megnevezés mező nem egyedi, vagyis a rendszer megengedi több azonos nevű földrajzi hely bevitelét. Nyilvánvalóan helyes 3 db "Veszprém" léte egy adatbázisban, ha az egyiknél a Típus mező üres, a másiknál "megye", a harmadiknál pedig "vármegye" értékű.
Amikor azonban egy importálandó rekordban a földrajzi név "Veszprém", akkor a program a fogadó adatbázisban három azonos nevűt fog találni, ha a fenti útmutatásnak megfelelően keres. Megoldhatatlan helyzetbe kerülünk, és kétféle döntést hozhatunk:

- Az érkező új a meglévők bármelyikével azonos - az összehasonlított tartalomban valóban az -, válasszunk ki közülük egyet, bármelyiket.
- Az érkező új a meglévők egyikével sem azonos, mert valószínüleg a látszat ellenére a régi három sem az. Hiszen ha azonosak lennének, akkor nem kellene belőlük három.

A két rossz választás közül a program a második mellett dönt, mert megvan az esélye annak, hogy a rekordok valóban különböznek, csak az összehasonlítás rossz. Ha belegondolunk, ez így is van. Javításként egészítsük ki az azonosító mezők sorát!

&r FOLDRAJZ
Azonosito:MEGNEVEZES TIPUS

Ettől az összehasonlítás egyértelművé válik, mert az érkező rekord azzal azonos a három "Veszprém" közül, amelyikkel a Típus mezője is az. És csak akkor keletkezik a negyedik "Veszprém", ha a Típus más. Az elmondottakból következik, de a biztonság kedvéért szögezzük le: az azonosítőként megnevezett mezők mindegyikének páronkénti egyezése feltétele két rekord azonosságának, megengedve bármelyik - de semmiképpen nem az összes - kitöltetlenségét is. Részletezve: azonos két földrajz rekord, ha

a Megnevezés és a Típus mindkettőben kitöltött és azonos,
a Megnevezés mindkettőben kitöltött és azonos, a Típus viszont kitöltetlen,

A harmadik változat - a Típus mindkettőben kitöltött és azonos, a Megnevezés viszont kitöltetlen - elfogadható lenne, ha a Típus indexelt mező lenne, azaz lehetne az értéke alapján keresni, a 4. változat pedig értelmetlen, mert ha mindkét mező kitöltetlen, akkor nincs is mit keresni a vizsgálathoz a fogadó adatbázisban.
Sajnos pusztán a .CFG módosításával nem lehet megszüntetni a rekordok korábban elkezdődött sokszorozódását. Ha már van kettő, a típusában is azonos földrajz rekord, akkor az érkező harmadiknál az előbb leírttal azonos eldönthetetlen helyzet áll elő, és folytatódik sokszorozódás. Hogy ne így legyen, a .CFG átírása előtt az adatbázist kell módosítanunk, meg kell szüntetni az azonos rekordokat. Ennek módszere a 4. hírlevélben "A besorolási adatok egységesítése" címnél olvasható.
Láthatjuk tehát, hogy egy mégoly jellemzőnek hitt mező sem elegendő egymagában az azonosításhoz. Találnunk kell mindenképpen kiegészítő(ke)t, hogy a sokszorozódás hibáját eleve kizárjuk.
A TextLibben előforduló rekordok túlnyomó többségének egyszerű megtalálni az azonosítás céljára megfelelő mezőit. A kevés kivétel között legfontosabb a sokféle dokumentumtípus. Az ok egyszerű: nincs a dokumentumoknak egyetlen igazán jellemző mezője, hanem több együttesen alkot egy kifejező egységet. Az ISBN és az ISSN a szabályt erősítő kivétel, már ha egyáltalán van a dokumentumnak. Így a dokumentumok azonosítása a legnehezebb feladat, eddig nem használt fegyverek bevetése nélkül nem is lehetne megoldani. Nézzük!

&r DOKUMENTUM
Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO
Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM

Az első, ami feltűnik, a két azonosító sor. Ez megengedett dolog, sőt, a maximum akár négy is lehet. Az egymást követő sorok egymással "vagy" kapcsolatban állnak, ha tehát az import program az első alapján nem talál az érkezővel azonos rekordot a fogadó adatbázisban, akkor továbblép, és megpróbál a második alapján keresgélni, és így tovább. Bármelyik feltételcsoport igaznak bizonyul, a továbbiak vizsgálata elmarad. Nem nyilvánvaló, de logikus következtetés adódik a "vagy" kapcsolatból: ha több azonosító sort készítünk, akkor azokat nagyjából egyforma szigorú szempontrendszer alapján kell felépítenünk.
A második új elem a példában a "/" jel. Az import programot ez arra utasítja, hogy csak az előtte felsorolt mezők alapján hajtsa végre a keresést. Az így megtalált rekordokat azután természetesen a többi mező szerint is összehasonlítja az érkezővel, tehát a jel használata az azonosítás végeredményét nem befolyásolja. Abban az esetben mégis nagyon célszerű a használata, amikor be akarunk vonni a szempontok közé olyan mezőket, amelyek bár fontosak az azonosság megítélésében, de rengeteg rekordban egyformák. Ilyen pl. a dokumentumok Megjelenési éve (MEGJEVE). A "/" jel elé írva a mező bekerül a keresés szempontjai közé, és mivel sokezernyi megfelelés várható, sokáig tart. Gyorsabban fut a program, ha a jel mögé írjuk az ilyeneket. A "/" jel ürügyén ismét egy kis kitérőt célszerű tenni. A TextLib adatbázis-szerkezetének ismeretében rögtön szembetűnik valami: az első azonosító sor egyetlen jel előtti mezője, a DOK (Közös adatai) nem indexelt, nem lehet tehát kereséshez felhasználni. A TL_VESZ.EXE program kerülő úton mégis képes egy ilyen - nem ismételhető kapcsolódó - mezőből kiindulva megtalálni az összehasonlítandókat. De csak a TL_VESZ.EXE, a HM_VESZ.EXE nem, HunMarc rekordok betöltésekor a .CFG fenti sora hatástalan marad.
Mindegyik azonosító sorba legfeljebb 8 mezőnevet írhatunk, és azok között indexeltnek vagy kapcsolódónak is szerepelni kell. Annak híján ugyanis a TextLib képtelen lenne keresni, és akkor nem lenne mit mivel összehasonlítani. Észre is veszi a program ezt a hibát, ahogy az imént említett néhány más szabály megszegését is:

!!   1.HIBA (320): Rossz mező / REZSJELZES (11. sor)  !!
!!   1.HIBA (330): Túl sok azonosító mező (max 8) / (9. sor)  !!
!!   1.HIBA (331): Túl sok 'Azonosito:' sor (max 4) / (14. sor)  !!
!!   1.HIBA (332): Nem adott meg indexelt mezőt / (11. sor)  !!
!!   1.HIBA (334): Másodszori definíció / (20. sor)  !!

Térjünk vissza a dokumentumok azonosításának problémájához! Elsőként érdemes megfontolni, hogy tudunk-e a típus tagjaira - azaz mindenféle dokumentumra - egyaránt érvényes leírást készíteni. Ez semmiképpen sem végleges döntés, mert ahogy korábban már szó volt róla, bármikor szerkeszthetünk saját feltétel listát bármelyik adatfájlra külön is. A fenti példa egy jó mintája a közös leírásnak, ami rögtön megoldja a dokumentumtípusokon belüli bibliográfiai szint kezelését is. Bár a két sorban ugyanazok a mezőnevek olvashatók, a céljuk és a működésük eltér egymástól.
Az elsőben egyetlen mező a Közös adatai (DOK) után azonnal a "/" jel következik, eszerint tehát ez a keresés kizárólag a közös adattal rendelkező dokumentumokra, azaz a többkötetesek köteteire vonatkozik. Amennyiben az érkező kötetnek azonos a közös adata egy fogadó adatbázisbelivel, akkor a Kötetjelzés, a Megjelenés éve, a Főcím, a Párh. címadatok, a Címadatok, az Alcím, egyéb címadat és a Szerzők mező összehasonlítása után eldöl, hogy új vagy már meglevő kötet érkezett-e. Kihasználtuk a megengedett nyolc mezőnevet, ennyi alapján biztonságosan azonosítható két dokumentum, még akkor is, ha több üres mező is van a felsorolásban.
A második sorban az azonosítás vezérelemei a címek, ez a felsorolás tehát főként a közös adatokhoz és az egykötetesekhez való. Nem csökkentjük a mezők számát, mert veszélyes lenne. Bár ezt a sort nem a többkötetesek kötetei számára terveztük, mégis meg kell felelnie azoknak is, hiszen az első azonosító sor nemleges válasza után mindenképpen a második következik a kötetek számára is. Képzeljünk el egy kötetet, amelyik az első sorban már a közös adatok vizsgálatakor nem felel meg, mert az - mármint a közös rekord - nincs benne a fogadó adatbázisban. Amennyiben a második sorból abban a hiszemben húznánk ki a szempontok közül a közös adatokat (DOK) és a kötetjelzést (RESZJELZES), hogy a köteteket már elintéztük az elsőben, akkor furcsa kellemetlenségek történhetnének. Az érkező rekord ugyanis felülírhatna egy sok adatában azonos, de másik közöshöz tartozó kötetet, vagy - ismét csak a sokféle adat azonosságát feltételezve - a saját közös adatának kötetévé tehetné a fogadó adatbázis valamelyik egykötetesét. A kitűzött célt, a mindenféle dokumentumtípus többféle bibliográfiai szintjéhez tartozó dokumentumának összehasonlíthatóságát a két sor együtt valósítja meg,
Látszólag biztonságosabbá teszi az összehasonlítást, ha minél több mezőt használunk szempontként. Látnunk kell azonban a hosszú felsorolásából keletkező veszélyt is. Ez pedig a különböző adatbázisok eltérő adattartalmából fakad. Már egyetlen plusz kitöltött mező is megbuktathatja az azonosságot: pl. a fogadó adatbázis rekordjában van címadat, az érkezőben pedig megjegyzésben vannak a gyűjtemény darabjai, és oda az egyezés.
Bizony jó lenne a dokumentumok összehasonlításához egyetlen egyértelmű azonosítót hsználni! Valahogy így:

&r DOKUMENTUM
Azonosito: ISBN
Azonosito: ISSN

Egyszerű és nagyszerű minden olyan esetben, amikor biztosan van az érkező dokumentumoknak ISBN-je. Mert amelyiknek nincs, az mindenképpen új rekordnak fog bizonyulni, ha nincs több azonosító sor. Márpedig az 1976. előttieknek nincs, meg az újaknak is hibás néha, van tehát bizonytalanság ezzel is. Egészítsük ki!

&r DOKUMENTUM
Azonosito:ISBN FOCIM

Ezzel mindent elrontottunk. Most már elegendő két ISBN nélküli dokumentum főcímének egyezősége a teljes azonossághoz, márpedig ez nagyon puha feltétel. Egyértelmű azonosító mellé ne írjunk más feltételt! Illetve... Ha muszáj megtenni, használjuk a "/" jelet. Akkor ugyanis csak az ISBN-ek létének és azonosságának kiderülte után foglalkozik a program a főcímmel.

&r DOKUMENTUM
Azonosito:ISBN / FOCIM

Az eddigiek összegzéseként készítsünk egy nem biztosan, de nagy valószínűséggel jól használható mintát TextLib adatbázisból származó csereállomány dokumentumainak összehasonlításához.

&r DOKUMENTUM
Azonosito:ISBN
Azonosito:ISSN
Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO
Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM

A HunMarc formátumú rekordok esetében kétségbeejtőnek tűnik a helyzet, ha hiányzik az ISBN és az ISSN is. A 3. sor hatástalan, és a 4. is az egy többkötetes cím nélküli kötetének betöltésekor.
Van azonban egy mostanáig eltitkolt fontos szabály az összehasonlításban, ami felülbírálja az eddig leírtakat: egy rekord önmagával minden körülmények között azonos. Egy forrásként használt adatbázisból - lehet az a szomszéd könyvtár vagy az Országos Széchényi Könyvtár rendszeres szolgáltatása - többször is megkaphatjuk ugyanazt a rekordot, hiszen minden jelentős változtatás után újra kiküldi a szolgáltató. Az adatbázis azonosító és a rekordazonosító együttesen egyértelműen azonosítja a rekordot, és az import program a .CFG-ben tett rendelkezéstől függetlenül az érkező rekordot azonosnak tekinti saját maga korábbi változatával.
Márpedig a HunMarc állományokban a közös-kötet kapcsolatot éppen az adatbázis azonosítóval ábrázolják, így ezek betöltésére is általában megfelel a fenti minta. Elméletileg előfordulhat, és hibához is vezet, ha egy adatszegény kötetet - pl. csak a kötetjelzés és a közös adat ismert - úgy importálunk, hogy ugyanaz már saját adatbevitelből eredően megvan az adatbázisunkban. Ilyenkor számíthatunk a kötet megduplázódására.
Tekintsük át, érdemes-e adatfájlonként külön azonosító szakaszt készíteni a .CFG-ben a sokféle dokumentumtípus számára. Egy esetben nyilvánvalóan igen. Akkor, ha az import műveletében szűrni is akarjuk az érkező rekordokat. Pl. kizárólag audiovizuális dokumentumok betöltéséhez hagyjuk el a

&r DOKUMENTUM
Azonosito:...

szakaszt, ellenben soroljuk fel a megcélzott adatfájlokat:

&d AUDIODOK
Azonosito:...

&d AUDIOKOTET
Azonosito:...

&d AUDIOANAL
Azonosito:...

Mivel csak az audiovizuális dokumentumok importjához talál leírást a program a .CFG-ben, minden mást kihagy, valóban szűrőként viselkedik tehát ez a pár sor.
Egy másik lehetséges oka az adatfájlonkénti leírásnak az egyszerűsítés lehetne. Talán könnyebb áttekinthető szabályokat alkotni, ha nem akarunk annyi mindent egy csapásra megoldani. Az audiovizuális közös adatokra (AUDIODOK) a dokumentumoknál megismert egyik sor kis átalakítással elegendőnek látszik. Nyugodtan kihagyhatjuk a DOK Közös adatai és a RESZJELZES Kötetjelzés mezőt, mert ilyenek a közös rekordban nincsenek. Helyettük vonjuk be a KOZREMUKODO Közreműködők mezőt:

&d AUDIODOK
Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO KOZREMUKODO MEGJEVE ALCIM

Az audiovizuális részegységgel már nem könnyű elbánni. Próbáljuk a fentről ollózott másik sort használni!

&d AUDIOKOTET
Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO

Jó ez a többkötetesek köteteihez, de nem jó a magányos kötetekhez. Kellene legalább még egy sor, és akkor ugyanott vagyunk, mint a rekordtípus egészét szabályozó leírás készítésekor voltunk. Leszögezhetjük tehát, hogy adatfájlonként elkülönülő szabályrendszert kizárólag szűrés céljára indokolt felállítani.
Foglaljuk össze az érkező és bent levő rekordok összehasonlításának lényegét!
A vizsgálat legelső mozzanata, hogy a betöltő program az érkező rekord importazonosítója alapján keres. A .CFG szabályrendszere akkor lép működésbe, ha ez a keresés eredménytelen marad.
A .CFG-ben négy sorban adhatunk meg azonosító mezőket, mindegyikben nyolcat. A program egymás után dolgozza fel a sorokat, amíg meg nem állapítja a rekordok azonosságát. Új lesz az érkező rekord, ha egyik sor alapján sem állapítható meg egyezés, vagy ha több azonos is van a fogadó adatbázisban. Az azonosság feltétele a felsorolt mezők mindegyikének páronként egyező tartalma. Igaz az egyezés, ha a mezők azonos tartalommal kitöltöttek vagy ha üresek. Az összehasonlításba bevonni kívánt rekordok keresésénél az üres mezők természetesen figyelmen kívül maradnak. Az azonosító mezők felsorolását a "/" jellel kettéválaszthatjuk. A program csak a jel előtti mezőket használja kereséshez, így a keresést felgyorsíthatjuk és/vagy egyértelműsíthetjük. Még egyszerűbben: két rekord azonos, ha egyetlen rekord két adatbázisban előforduló két változata, vagy ha az összehasonlításra kijelölt mezőinek a tartalma azonos.
Az összehasonlítás szempontjainak kidolgozásában az elvi megfontolások mellett gyakorlati segítséget is kaphatunk. Jó lenne meggyőződni az azonosítás megbízhatóságáról, miközben a rekordok ezrei ömlenek be a fogadó adatbázisba, de erre sajnos nincs mód. A betöltés befejeztével azonban az egyesített adatbázis tartalmán kívül a folyamat mozzanatait leíró TL_VESZ.LOG vagy HM_VESZ.LOG nevű szövegállomány is fontos információkkal szolgál. (Lásd a 7. hírlevélben !) Ennek a szövegállománynak a tartalmát a .CFG-be írt kiegészítéssel kibővíthetjük az összehasonlítás pontosságának könnyebb megítélése céljából. A vezérlő utasítás alakja a következő:

&r DOKUMENTUM
Azonosito:...
Hasonlo:...

A "Hasonlo:" kezdetű sor az újdonság. Felépítése az azonosító sorokkal csaknem megegyezik, a különbség, hogy kizárólag indexelt mezőket - legfeljebb nyolcat - adhatunk meg a hasonlóság felderítésének céljára. A megadott szempontok alapján a fogadó adatbázisnak az érkezőhöz hasonló rekordjairól listát kapunk a .LOG állományban. E lista alapján dönthetünk arról, hogy enyhíteni vagy szigorítani érdemes az azonosítás feltételeit. A hasonló rekordok gyűjtése természetesen nem befoéyásolja a fő célt, az érkező és bent levő rekordok összehasonlítását. Pl. a dokumentumok importját vezérlő szövegrészt az alábbi módon egészíthetjük ki:

&r DOKUMENTUM
Azonosito:ISBN
Azonosito:ISSN
Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO
Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM
Hasonlo:ISBN
Hasonlo:FOCIM CIMADAT PARHCADAT SZERZO

A hasonlóságot felderítő soroknak csak akkor van értelme, ha az eredményét fel is használjuk az egyesített adatbázis tartalmának ellenőrzésében. Ha nem, akkor a program futásának lassításán kívül semmi más következménye nincs, nyugodtan kitörölhetjük a .CFG beli összes előfordulását.

Az adatbázisba kerülés módja Túljutva az összehasonlítás bonyodalmain a program tennivalója két ágra bomlik:

Új rekord bevitele következik, ha az érkező rekorddal azonos egyetlen egy sincs, vagy éppen ellenkezőleg több is van a fogadó adatbázisban.
Az egyetlen azonosnak talált rekord módosítása következik, ha a .CFG elején beállított cél a fogadó adatbázis módosítása volt.

Az új rekord bevitele egyszerű feladatnak látszik, kerüljön be az adatbázisunkba úgy, ahogy van. Az importot vezérlő leírásban egy paranccsal még ezt az átvételt is finomítani tudjuk, a rekord tetszőleges mezőit kizárva a műveletből.
Több megfontolást érdemel az azonos rekordok esete, az esetleges módosítás. Az összehasonlításra kiválasztott azonosító mezőket az import program páronként egyező tartalmúnak találta az érkező és egy már meglevő rekordban, ezek alapján született a döntés. De mi van, mi legyen a többi mezővel? Lehet az érkező és a bent levő rekordnak is plusz tartalma a másikhoz képest. Nézzünk egy egyszerű példát:

Bent levő                              Érkező

FOCIM: A magyar nemzet megszületése    FOCIM: A magyar nemzet megszületése
SZERZ_KOZL: Kristó Gyula               SZERZ_KOZL: Kristó Gyula
KIADAS:                                KIADAS:
   1.XMEGJ_HELYEK: Budapest               1.XMEGJ_HELYEK: Budapest
     KIADOK: Kossuth                        KIADOK: Kossuth
                                       NYOMTATAS:
                                          1.XMEGJ_HELYEK: Budapest
                                            KIADOK: Kossuth
                                          2.XMEGJ_HELYEK: Szekszárd
                                            KIADOK: Szekszárdi Ny.
MEGJEVE: 1998                          MEGJEVE: 1998
OLDALSZAM: 210, [3] p.                 OLDALSZAM: 210, [3] p.
MERET: 20 cm                           MERET: 20 cm
ISBN: 963-09-3990-8                    ISBN: 963-09-3990-8
KOTES: fűzött                          KOTES: fűzött
AR_TERJFELT: 990,- Ft                  AR_TERJFELT: 990,- Ft
BIBL_MEGJEGYZES: Bibliogr.: p. 207-
    [211]. és a lábjegyzetekben
SZERZO:                                SZERZO: Kristó Gyula
   1.NEV: Kristó Gyula
     EVEK: 1939
NYELV: magyar                          NYELV: magyar
ETO_ALM:                               ETO_ALM:
   1.ETOSTRING: 943.9"08/12"              1.ETOSTRING: 943.9".../12"
     FO: Magyarország története
     TARGYIDO: "08/12"
   2.ETOSTRING: 316.356.4(=945.11)        2.ETOSTRING: 316.356.4(=945.11)
     FO: nemzet / szociológia
     ETNIKAI: magyarok
SZAKJELZET: 943.9
CUTTER: K 95
PELDANY:
   1.VONALKOD: 001000062185N
   2.VONALKOD: 001000051089O
ETO2_ALM:
   1.ETOSTRING: 9(439)"08/12"
     FO: történelem
     FOLDRAJZ: Magyarország
     TARGYIDO: 0800/1299
   2.ETOSTRING: 307(439)"08/12"
     FO: társadalmi tudat
     FOLDRAJZ: Magyarország
     TARGYIDO: 0800/1299
   3.ETOSTRING: 309(439)"08/12"
     FO: társadalomtörténet
     FOLDRAJZ: Magyarország
     TARGYIDO: 0800/1299

A két rekord azonosító mezője (ISBN) megegyezik, de másutt vannak eltérések, és azok kezelésére a program ötféleképpen képes:

Tekinthetjük jobbnak az érkező rekordot a sajátunknál, és rendelkezhetünk úgy, hogy az mindenképpen írja felül a miénket. Ebbe az elfogadásba beletartozik az is, hogy a nálunk kitöltött, de az érkezőben üres mezők kiürülnek a mi rekordunkban is. A példában ez a Megjegyzés, az alkotó éVek, az ETO jelzetelemek, a Szakcsoport, a Cutter, a Példányai és a TO mezőt érinti. A mindkét rekordban kitöltöttek közül is az érkező érvényesül, ilyen a példában az ETO első ismétlődése. A parancs: ATVESZ
Tompíthatjuk az érkező rekordok fölérendeltségét úgy, hogy csak a kitöltött mezők uralkodását engedjük meg, a kitöltetlenek helyett pedig a mi rekordunk tartalmát tekintjük jónak. A példában ez az előző pontban felsorolt mezők megmaradását eredményezi. A parancs: MODOSIT
Tekinthetjük jobbnak a saját rekordunkat, ekkor csak az üresen hagyott mezőink töltődhetnek az érkező rekordból, a kitöltöttek mindenképpen változatlanul maradnak. A példában ilyen a Nyomtatás mező. A parancs: KITOLT
Az ismételhető mezők kezelésében az eddigi módszerek mellett még egyet kínál a program: nem ragaszkodik sem a saját sem pedig az érkező rekord kizárólagosságához, hanem összesíti a kettőt. A példában az ETO mezőnek az egyesítés eredményeként három ismétlődése lenne. A parancs: VEGYIT
Tekinthetjük érdektelennek vagy fölöslegesnek az érkező rekord egy-egy mezőjét, és rendelkezhetünk úgy, hogy az semmiképpen se töltődjön be a fogadó adatbázisba. Ez a parancs - ahogy korábban utaltunk rá - hat az újként érkező rekordokra is, nemcsak az érkező-bent levő párosokra. Jó példa erre, ha a küldő adatbázis dokumentumainak Ismertetés/kivonat mezőjét nem akarjuk átvenni. A parancs: ELDOB

A mezők kijelölése Az előbb felsorolt parancsok önmagukban használhatatlanok, csak a rekord egy vagy több mezőjének megnevezésével együtt érvényesek. Vagyis szinte tetszőleges részletességgel megadhatjuk, hogy az érkező rekord mezőit átvenni kell-e illetve eldobni, vagy a meglevőket kitölteni, módosítani illetve vegyíteni az újakkal. Ezek után a dokumentum rekordtípus importját vezérlő leírás immár teljessé válik:

&r DOKUMENTUM
Azonosito:ISBN
Azonosito:ISSN
Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO
Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM
Kitolt:/MIND /RENDSZER
Vegyit:ETO_ALM
Eldob:KIVONAT

A kiegészítő rész három sora közül természetesen az 1. a kulcs, a másik kettő csak finomítás, kiegészítés. Azonnal fűzzünk néhány megjegyzést is az újdonságokhoz:

A "/MIND" és a "/RENDSZER" egymástól föggetlen két összefoglaló elnevezése egy tetszőleges import rekord mezőinek. "/MIND" a rekord összes mezőjét jelenti, kivéve a rendszer mezőket, "/RENDSZER" pedig a rendszer által automatikusan kezelt mezőket (KULSOAZON, IMPORTAZON, BEVITEL, BEVIVO, UTOLSOMODOSITAS, MODOSITO, stb.)
A parancs után csupán szóközökkel tagolt felsorolás is következhet a mezőnevekből.
Amennyiben egy mezőről több parancs is rendelkezok, akkor azok közül az utolsó marad hatásos. A
Kitolt:/MIND /RENDSZER parancs a dokumentum összes mezőjéről rendelkezik már, de a Vegyit:ETO_ALM Eldob:KIVONAT parancs az ETO (ETO_ALM) és az Ismertetés/kivonat (KIVONAT) mezőre új szabályt határoz meg, és az érvényesül a betöltéskor.
Az "Eldob" parancs használata kapcsolódó mezőknél furcsa végeredményhez vezethet. Pl. példányokat is tartalmazó dokumentumok importjakor az
Eldob:PELDANY sor következtében a bekerülő dokumetumok Példányai mezője természetesen kiürül, de ez a tény nem befolyásolja a példány rekordok importját. Azt a .CFG-ben a példányokra vonatkozó rendelkezés szabályozza. A következő minta használata után betöltődnek a példányok is, de hiányozni fog a kapcsolat a dokumentummal, ami nem lehet cél.
```
&r DOKUMENTUM
Azonosito:ISBN
Azonosito:ISSN
Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO
Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM
Kitolt:/MIND /RENDSZER
Vegyit:ETO_ALM
Eldob:PELDANY

&r PELDANY
Azonosito:VONALKOD
Kitolt:/MIND /RENDSZER
```
Kapcsolódó mezőket tehát általában nem érdemes az "Eldob" parancs mögött felsorolni, a kapcsolt rekordra vonatkozó rendelkezés - a példában a "&r PELDANY" kezdetű szövegrész - szándékos kihagyása oldja meg jól a feladatot.

Végül nézzünk egy gyakorlatban is használható .CFG állományt dokumentumok betöltéséhez. A vezérlő állomány egyaránt alkalmas TextLib és HunMarc rekordok importjára (Lásd a "DOK /" kezdetű sorra vonatkozó korábbi megjegyzést is!), mindenféle dokumentumtípushoz és segédrekordokhoz.

#
# Dokumentumok es kapcsolataik betoltesehez
#
TextLib Import leiro file - InfoKer 1995
Kodkeszlet:CWI
Cel:M
Teljezmezo:N

&r DOKUMENTUM
Azonosito:ISBN
Azonosito:ISSN
Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO
Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM
Kitolt:/MIND /RENDSZER
Vegyit:BIBL_MEGJEGYZES PELDANY

&r PELDANY
Azonosito:VONALKOD
Kitolt:/MIND /RENDSZER

&r IDOSZAM
Azonosito:KOTETE / SZAMOZAS KELTEZES MEGJEVE EVFOLYAM
Kitolt:/MIND /RENDSZER

&r CIMADAT
Kitolt:/MIND /RENDSZER

&r PARHCADAT
Kitolt:/MIND /RENDSZER

&r ALKOTO
Azonosito:NEV NEVKIEG EVEK
Hasonlo:NEV
Kitolt:/MIND /RENDSZER

&r TESTULET
Azonosito:NEV IDOSZAK SORSZAM SZEKHELY
Hasonlo:NEV
Kitolt:/MIND /RENDSZER

&r ETO_ALM
Kitolt:/MIND /RENDSZER

&r ETO2_ALM
Kitolt:/MIND /RENDSZER

&r SPEC_OSZT
Azonosito:KOD
Kitolt:/MIND /RENDSZER

&r TEZAURUSZ
Azonosito: KULCS
Hasonlo: KULCS
Kitolt:/MIND /RENDSZER

&r FOLDRAJZ
Azonosito:MEGNEVEZES TIPUS
Kitolt:/MIND /RENDSZER

&r KOZREMUKODO
Kitolt:/MIND /RENDSZER

&r KIADAS
Kitolt:/MIND /RENDSZER

&r SOROZATLEIRAS
Kitolt:/MIND /RENDSZER

&r SOROZAT
Azonosito:FOCIM PARHCADAT ISSN
Kitolt:/MIND /RENDSZER

&r MELLEKLET
Kitolt:/MIND /RENDSZER

&r MU
Azonosito:EGYSCIM SZERZO KELETKEZESIIDO
Kitolt:/MIND /RENDSZER

&r PARH_SZAMOZAS
Kitolt:/MIND /RENDSZER

1.4.8. HUNDIR program

HunMarc fájlok olvasható formában történő kiírásához használható.

Használata

Használat: HUNDIR in [/n] [/n-m] [/oout]

in - input fájl neve
n - n-edik rekordtól írja csak ki, Pl: /23
n-m - n-ediktől az m-edik rekordig. Pl: /34-56
out - output fájl neve, def: standard output

Formátum

A rekordokat a következő formában jeleníti meg:


    mezőazonosító
      almezőazonosító érték
      almezőazonosító érték
      ...
    ...

A mezőazonosító egy 3 jegyű szám szokott lenni, az elmezőazonosító pedig #x alakú, ahol x egy betű vagy egy számjegy.

Ilyenekkel fogunk tehát találkozni:

020
   $a 963-375-130-6
   $j fîuzčott
 080  0
   $a 894.511-312.5
 100 10
   $a Nemere
   $j Istvâan
   $d 1944-
 245 12
   $a Lazarus doktornîo
   $c Melissa Moretti
 260
   $a [Budapest]
   $b Anno,
   $c 2000
 300
   $a 245 p.
   $c 20 cm

Példa:

Az mnb5123.iso fájl első 20 rekordjának kiiratása a képernyőre:

HUNDIR /1-20 mnb5123.iso

A teljes fájl tartalmának kiiratása az mnb5123.lst fájlba:

HUNDIR mnb5123.iso /omnb5123.lst

1.5. Segédprogramok

1.5.1. DBSTRUCT: Adatbázis szerkezet program

Célja

A TextLib adatbázis szerkezetének megtekintése. Megnézhetjük milyen adatfájlok, rekord típusok, indexfájlok, stb vannak az adatbázisban. Az egyes rekord típusokhoz tartozó mezőkről és azok indexelési módjáról is felvilágosítást kaphatnuk.

Érdemes egyszer kinyomtatni az adatbázis szerkezetét, hogy mindig kéznél legyen. Valószínűleg a rendszergazdán kívül senkinek sem lesz rá szüksége.

Az adatbázis szerkezet leírásánál használt fogalmak és jelek: Dataset: a TextLib adatállományai a lemezen, egy-egy set több adatfájlt foglalhat magába
A leírásban a datasetek sorszáma és neve szerepel.

Példa:

3. TL_SDATA

Indexset: a TextLib indexállományai a lemezen, egy-egy set több indexfájlt foglalhat magába
A leírásban az indexsetek sorszáma és neve szerepel.

Példa:

2. TL_REND

Rekordtípus: az adatrekordok logikai felépítésének leírása. Azonos rekordtípusba tartozó adatrekordok kerülhetnek különböző adatfájlba (pl. a különböző típusú dokumentumok logikai leírására egyaránt a DOKUMENTUM rekordtípus szolgál). A leírásban a rekordtípusok sorszáma és neve szerepel.

Példa:

53. DOKUMENTUM

Adatfájl: az adatrekordok tárolási helye. Az adatfájl sorszáma és azonosítója után a rekordtípus, az adatfájl karakteres "sorszáma", majd a neve következik.

Példa:

49. KOTET(DOKUMENTUM),b Könyv kötet

Rekordazonosító: egy adatrekord tárolási helyének leírója (ezt látja megnézéskor a képernyő ablak felső szegélyén). Két része: az adatfájl legfeljebb kétkarakteres "sorszáma" és a rekordsorszám. Indexfájl: az indexkulcsok tárolási helye. Az indexfájl sorszáma, azonosítója és neve szerepel a felsorolásban.

Példa:

37. OLVNEV Olvasók nevei

Rekordtípusok egyenként:

Példa:

53.rek.típus: DOKUMENTUM
A rekordtípus leírásában az adatrekordot felépítő mezők és almezők szerepelnek.
Mező: a rekord építőeleme, általában a képernyőn megjelenő űrlap egy sora.
Almező: szerkezettel rendelkező mező, önmaga is mezőkre és almezőkre tagolódik. A rekordtípustól abban tér el, hogy a tárolási helye nem egy adatfájl, hanem egy adatrekord.
Főmezői: a főmezők képviselik a rekordot minden olyan esetben, ha nincs megadva más. Főmezői: FOCIM CIMADAT PARHCADAT Mezők egyenként: a mező sorszáma, azonosítója és típusa látható. PL:
48. FOCIM(Rstr)
Mezősorszám
Azonosító
Mezőtípus: a sokféle mezőtípus elé írt "R" az ismételhetőség jele. A "Rsub" mezőtípus almezőt jelent, mögötte az almezőt befogadó adatfájl azonosítója és sorszáma látható.
Ha a mező indexelt, akkor az indexfájl azonosítója, sorszáma és az indexelési mód is szerepel a leírásban.
Pl: Index:CIMSZO(50), szavas "<-->" jel annál a mezőnél látható, amelyen keresztül a rekord kétirányú kapcsolatban áll egy másik rekorddal. Pl. a DOKUMENTUM rekordtípus DOK mezeje a kötet közös adataira mutat, az pedig a KOTET mezején keresztül mutat vissza:

Rekordtípus: DOKUMENTUM             DOKUMENTUM
 Adatfájl:    KOTET                  DOK

            -?????????????????Ş    -???????????????????Ş
            -Rekord1          -    -Rekord2            -
            +?????????????????+    +???????????????????+
            -                 -    -                   -
            -89 DOKUMENTUM_DOK-<-->-87 DOKUMENTUM_KOTET-
            -                 -    -                   -
            -                 -    -                   -
            -                 -    -                   -
            L?????????????????-    L???????????????????-

A DBSTRUCT programmal készített listán pl. ez látható: <-->DOK(48) DOKUMENTUM_KOTET(53_87) - ha KOTET(49)
A fenti sor szavakkal: A mező rámutat a DOK (48) adatfájl egy rekordjára, amelyben a DOKUMENTUM (53) rekordtípushoz tartozó rekord a DOKUMENTUM_KOTET mezején (87) keresztül mutat vissza, amennyiben a kiinduló rekord KOTET (49) adatfájlba tartozik.

Indexfájlok egyenként: A leírásban az indexfájl sorszáma, az azonosítója, a neve, a befoglaló indexset neve (Iset), az indexkulcs típusa (Kulcstip), a rekordhivatkozás típusa (Dreftip), az indexelési mód (IdxMód), az összehasonlító tábla sorszáma (Tbl), az indexfájl jellemzői (Status), és a belekerülő mezők felsorolása szerepel. Pl: 74.indexfájl: SZERZOJE Szerzője Iset:TL_BIBL Kulcstip:str Dreftip:dref IdxMód:teljes Tbl:8 Status: (0006) Postingos Kapcsolódó MU_SZERZO(51_48), indirekt DOKUMENTUM_SZERZO(53_70), indirekt

A TextLib programban (egyelőre) vannak olyan helyek, ahol a rendszergazdának adatfájl vagy rekordtípus-sorszámot kell megadnia. Ilyen például a felhasználói jogok definiálása.

Használata

Egyszerűen indítsuk el a programot a megfelelő paraméterrel. Ha nem tudjuk, hogy mik a paraméterek, akkor a /? opcióval kiírja őket a program.

A program a képernyőre ír, ha fájlba akarjuk menteni az eredményt, akkor irányítsuk át az output-ot a DOS lehetőségeit használva: .BAT DBSTRUCT paraméter > outfile

Lásd még:

2. Rendszer beállítások

2.1. Alapadatok

2.1.1. Könyvtárunk adatai

A könyvtár adatait csak a rendszergazda módosíthatja, az ő menüjében a Rendszer / Könyvtárunk adatai menüpontból kiindulva. A következő ablakot láthatja:

Nevünk: A könyvtár neve. Ez jelenik meg a munkaállomásokon, ez kerül a kimenő levelek fejlécébe, stb. Kitöltése kötelező.

Számlázási cím: Megrendelő levelek nyomtatásakor ezt a címet írja a program a levélbe. Kitöltése kötelező.

Szállítási cím: Csak akkor kell megadni, ha különbözik a Számlázási cím-től.

Paraméterek: A könyvtár által kezelt dokumentumokhoz való hozzáférés körülményeit az "átlag"-olvasó vonatkozásában szabályozó adatokat jelenti; elkülönült adatcsoportként való szerepeltetését az indokolja, hogy nemcsak a könyvtár egészére, hanem megfelelő szempontok szerint osztályozott részeire (állományok, dokumentum-osztályok) ill. a felhasználók megfelelő csoportjaira, az ún. olvasói kategóriákra, sőt ezek kombinációjára is megadhatók ilyen paraméterek (lásd <PARAMS.txt>).

Adatbázis azonosító: Kitöltése csak akkor szükséges, ha exportálni akarunk az adatbázisból. Ilyenkor egy mindenki másétól különböző azonosítót kell megadni. A GT tagoknak osztottak ki ilyen azonosítókat, az FSZEK adatbázisa pl. a 00100-as.

VKOD maszk: Azok a könyvtárak használhatják, akik megvették azt a TexTLib kiegészítést, ami a bejövő vonalkódok egy részét ki tudja hagyni. Más könyvtárakban ez a mező nem is látszik.

Rekord fix adatok tárolása: Itt lehet megadni, hogy a rekordok tárolásakor milyen plussz információk kerüljenek be a rekordba.

Megőrzendő módosítók: A rekord utolsó módosítóit is tárolja a TextLib. Maximum azonban annyit, amennyit itt megadtunk. Kezdeti értéke: 5

2.1.1.1. Default adatok

Olvasói Jogok: Jog rekordokat (<jogok.txt>) szúrhatunk be ide. Ezzel minden olvasónak tudunk jogot adni valamihez (pl: nyomtatás), nem kell egyenként minden olvasóhoz hozzárendelni.

2.1.1.2. Pénzügyi kontroll

2.1.1.3. Feladatkiosztás

Funkciók: Itt tudjuk bejelölni, hogy egyes alrendszerek közül a könyvtár melyeket szándékozik használni. Bármikor be lehet állítani egy alrendszer használatát, de kikapcsolni csak olyankor lehet, mikor nincs semmi függőben az adott alrendszeren belül (a program figyelmeztet, ha igen).

Vásárlás Azonosító: Az előszerzeményezés alrendszer használatakor meg lehet a vásárlási listák automatikusan generálandó azonosítóinak a formáját. Ha ezt nem adjuk meg, nem fogunk tudni vásárlási listát készíteni.

Rendelés Azonosító > Ha használjuk a rendelés alrendszert, akkor kötelező megadni a rendeléskor automatkusan generálódó azonosítók formáját.

Reklamálások száma> A rendelés alrendszer használatánál meg kell adni, hogy a könyvtár egy megrendelés esetén hányszor reklamál, mielőtt lemondja a megrendelést. Az egyes szállítóknál ettől eltérő érték is beállítható.

Reklamálási időközök> A rendelés alrendszer használatánál meg kell adni, hogy a könyvtár milyen időközönként reklamál, ha a megrendelésre nem kap visszajelzést. Az egyes szállítóknál ettől eltérő érték is beállítható.

2.1.1.4. Speciális dolgok

Egyedi indexek: Az itt megadott sorszámú indexfájlokba történő bevitel előtt a program egyediséget ellenőriz. Ha az indexfájl valóban egyedi, akkor a rekordot nem is lehet tárolni.

Pl: szóljon a program, ha olyan leltári számot adunk meg, ami már létezik (ha ezek általában egyediek). Vagy pl. alkotó bevitelnél szóljon, hogy van már ilyen nevű alkotó.

2.1.2. Munkaszüneti napok

Minden hónaphoz megadható, hogy mely napokon nincs nyitva a könyvtár. A program ezt több helyen automatikusan kezeli. Kölcsönzéskor például úgy határozza meg a határidőt, hogy ne essen olyan napra, amikor a könyvtár nincs is nyitva. A napok közé a szokásos ismétlés jelet kell bevinni, például az ALT-; billentyűkombinációval.

A program mindig azt tételezi fel, hogy az aktuális hónap utáni hónapokra az ezévi, a korábbi hónapokra pedig a jövő évi adatok vannak megadva. Például 1995. júnisban a július-december hónapot 1995. évinek, de a január-május hónapot már 1996. évinek gondolja. Mivel nem valószínű, hogy 1-2 hónapnál nagyobb intervallumokat kell kezelni, ezért elég negyed- vagy félévente aktualizálni az adatokat (ami a rendszergazda dolga).

2.1.3. Könyvtár hozzáférési paraméterek

2.1.4. Dolgozó

2.1.5. Dolgozói csoport

2.1.6. Állomány

2.1.7. Dokumentumosztály

2.1.8. Olvasó

2.1.9. Olvasói kategória

2.1.10. Személy

2.1.11. Raktár

2.1.12. Partner könyvtár

2.1.13. Partner kategória

2.2. Rendszereszközök

2.2.1. Nyomtatási formátum

Ha nyomtatni akarunk, két különböző dolgot kell definiálnunk: az egyik a nyomtató típusának, bekötésének (soros port, novell nyomtató,...) megadása (bővebben: <nybeall.txt>), a másik pedig a nyomtatási formátumnak a megadása.

A TextLibben a nyomtatási formátum ugyanolyan rekord, mint az összes többi. Ilyen rekordoknak a beviteléhez és módosításához általában csak a rendszergazdának van joga.

A nyomtatási formátum megadása két fő részből áll. Egyrészt meg kell adnunk a nyomtatni kívánt lapok adatait (méret, hasábok száma, rekordok előtt, között, után nyomtatandó szövegek, stb), valamint meg kell adni azt a nyomtató modult (InfoKer által készített modulok, pl: TH_CEDUL, TH_LPRN, vagy az output nyelven megírt, és lefordított modulok), ami a nyomtatást végzi. Ez a modul határozza meg, hogyan jelennek meg az adatok (milyen mezőket kell kiírni egy rekordból, és azokat hogyan).

A Lapméret mezőben adhatjuk meg, hogy a nyomtatón hány sor és hány oszlop kerüljön egy lapra. Ha üresen hagyjuk, akkor 65x78-as lapok készülnek. A Beljebb mezőben megadható, hogy hány karakter pozícióval kell minden sort beljebb kezdeni. A Hasábszám mező azt adja meg, hogy hány hasábba akarunk nyomtatni. Ha nem adjuk meg, akkor 1 hasábos lesz az output. A Cédula mező annak a megadására szolgál, hogy cédula nyomtatás esetén hány soros cédulák készüljenek. Ha a mögötte található darab mezőt is kitöltjük, akkor minden cédulából annyi darab készül (közvetlenül egymás után).

A Fölötte és Alatta mezőbe beírt szövegek minden kinyomtatandó rekord fölött és alatt megjelennek. Ide írhatunk speciális jeleket:

A Példányszám mezőben azt lehet megadni, hogy a nyomtatandót hány példányban akarjuk kinyomtatni. A Köztük mezőben megadott szöveget szeretnénk az egyes példányok közé. Ez pl. akkor hasznos, ha az olvasónak kinyomtatjuk, hogy miket kölcsönzött, és két példányt akarunk nyomtatni, hogy az olvasónak és a könyvtárnak is legyen. (Ha a nyomtató tud több példányos nyomtatást, akkor persze az az egyszerűbb, de pl. a hőnyomtatók nem tudnak ilyet)

A Fejléc és Lábléc a minden lap tetejére és aljára nyomtatandó szöveg megadásának helye. A fejlécben az & karakter helyett a lapszám jelenik meg. SHIFT/ENTER itt is használható ha több soros szöveget akarunk bevinni.

Több hasábos nyomtatás esetén a hasábok elé, közé és után írandó szöveget adhatunk meg a hasábok Előtt, Között és Után mezőben.

Nyomtató modulokat az output nyelv segítségével lehet létrehozni. Meg kell írni a rekordok megjelenítését végző programot, majd le kell fordítani a megfelelő programmal, ami létrehozza a nyomtató modult.

Természetesen a leggyakrabban szükséges feladatokhoz vannak előre elkészített nyomtató modulok, amiket nyugodtan használhatunk. Ezek:

TH_CEDUL - cédula formátumok
TH_LPRN - lista nyomtatáshoz (főleg példányokhoz)
TH_CPRN - minden mezőt kinyomtat
TH_SYS - rendszer adatrekordok nyomtatásához (levél,help,...).
TH_EGYEB - levelek, helpek, tezaurusz, eto.
TH_OLV - olvasói formátum
TH_SLST - rendezési kulcsok nyomtatása

OLV_SZAM - olvasók összeszámlálása (statisztika)
Ez a modul egy olvasó rekordokat tartalmazó találati halmaz kinyomtatására szolgál. Kétféle összesítést végez: állományonként és olvasói kategóriánként összeszámolja az érvényes és a lejárt olvasójeggyel rendelkező olvasókat, és kinyomtatja a csoportok létszámát.

DUPLIST - Duplikátumok megtalálásához.
Rendezett halmazt kell vele nyomtatni, és kiiírja azokat a tételeket, amikből egynél több jött a rendezett halmazban egymás után. Pl. földrajz rekordok név szerint rendezve. Igy meg lehet találni azokat, amikből több azonos nevű is van. Egyes rekordokról több mindent is kíír (földrajz, alkotó, példány), a többiről csak a rendezési kulcsot.

A duplikátumok kezeléséhez készült azóta egy ennél jobb eszköz: Duplázódások megszüntetése (http://textlib.hu/html/duplum.htm). Ennek használatát javasoljuk inkább!

A nyomtató modulok által kinyomtatott szövegek tartalmát paraméterek megadásával módosítani lehet. Vannak pareméterek, amelyeket minden nyomtató modul megért, és vannak egy adott modulhoz tartozó paraméterek is.

Paraméter	Mire jó
/SYS	minden rekord elé néhány sorba kiírja a rendszermezők (bevivő,módosítók,rendszer megjegyzés,...) tartalmát.
/BIBNO	a Bibliográfiai megjegyzés mezőt ne nyomtatassa
/PLDNO	a példányok adatait ne jelenítse meg a kötet előtt
/TEZNO	nem kellenek a tárgyszavak
/SZAKNO	szakcsoport és Cutter nem kell az elejére
/SZAKJOBB	szakcsoport és Cutter jobb oldalra igazítva
/SZAK2	SZAKJELZET helyett a SZAKJELZET2 jelenjen meg
/OSZTNO	nem kellenek az osztályozások (ETO)
/TONO	nem kellenek a TO jelzetek
/TALPNO	egyáltalán nem kell a cédula talp
/BESORNO	besorolási adatok nem kellenek
/PLDVEG	példány adatok a cédula végén legyenek
/PLDALL	példány adatoknál az állomány is jelenjen meg
/MASTALP	a talpat más formában írja ki (Mt.,Ut.,Tft.)
/UKAZON	a cédula jobb felső sarkában megjelenik az UK azon
/ANAL	cédula aljára az analitikákat is kinyomtatja
/RENDSZO	rendszót generál
/KOZRE1	a CIMADAT-beli közreműködőket nem nyomtatja
/RAKTJEL1	a dok. elején a példány adatokból csak a rakt jelzetet, yomtatja ki (ha van, akkor az akt. jelzetet)
/RAKTJEL2	mint az előző, de akt.rakt.jelzetet nem veszi figyelembe
/TORZSPLD	példány adatok más formában: leltszám: ár (raktjelzet)(akt.raktár: jelzet)
/KOZOSPLD	közös adat esetén minden kötetet minden példányának adatait a cédula elejére ki kell írni.
/ANALKIAD	analitika nyomtatásnál a forrás dokumentum megjelenési adatait is kiírja.
/KIEMELT	rendezett halmaz nyomtatása esetén kiírja a rendezési kulcsot a cédula előtt (csak amikor változik).
/SORALCIM	a sorozat alcime is jelenjen meg a cédulán
/SZAMOZ	sorszámozza a tételeket
/KOZTAURUSZ	a Köztauruaszt is kinyomtatja
/INTERNET	az Interneten mezőt is írja ki

Paraméter	Mire jó
/SZAKBAL	A szakcsoport és Cutter nem a jobb felső sarokban, hanem a bal oldalon jelenik meg.
/NAPRANE	Ne írja ki, hogy hány napra kölcsönözhető a könyv!
/VARHATO	Kiíródik, hogy mikorra várható vissza a könyv.
/MASHOLNEM	Csak a saját könyvtár példányait írja ki, beleértve a fiókok példányait is, a KSZR településieket nem.
/MASFIOKNEM	Csak a saját könyvtár példányait írja ki, a fiókok példányait nem.
/MASLISTA	A részletesen nem mutatott példányoknak csak a lelőhelyét listázza.

Paraméter	Mire jó
num	0,1,2,3 lehet, kötelezően az első paraméter. A hivatkozó mezők részletezésének mélysége.
0	a rekord mezőit kinyomtatja, a hivatkozott rekordokat nem.
1	a rekord adatait kinyomtatja, a hivatkozott rekordokat is, de az onnan hivatkozottakat nem.
2	a rekord, hivatkozott rekordok, és az onnan hivatkozott rekordok nyomtatása.
/MEGJ	Rendszer megjegyzéseket is nyomtassa ki
/SYSALL	Minden rendszer mezőt nyomtasson

Paraméter	Mire jó
/SYS	minden rekord elé néhány sorba kiírja a rendszermezők (bevivő,módosítók,rendszer megjegyzés,...) tartalmát.
/HEADER	fejlécet nyomtat
/VONALKOD	kinyomtatja a vonalkódot is
/SZERZO	kinyomtatja a szerzőt (ha nincs, az első szerzőségi közlést) is
/AR	kinyomtatja a példány beszerzési árát is a leltári szám után
/OSSZAR	kiírja a kinyomtatott példányok árának összegét (és a példányok számát)
/SORSZAM	sorszámozza a tételeket
/TORL_JEGYZ	törlési jegyzék formátumban nyomtatja a listát
/LETETI	letéti lista formátumban nyomtatja a listát
/RAKTARI	raktári lista formátumban nyomtatja a listát
/ATHELYEZESI	áthelyezési lista formátumban nyomtatja a listát
/RAKTNO	nem nyomtat raktárt
/RAKTJELNO	nem nyomtat raktári jelzetet
/EVNO	nem nyomtatja ki a megjelenési évet
/KIEMELT	rendezett nyomtatáskor a rendezési kulcs minden változásakor kiemelt kulcsot nyomtat (pl: példányok állomány szerinti rendezése)
/CUTTER	kinyomtatja a szakcsoportot és a Cutter jelzetet
/EGYSOR	mindenképpen egyetlen sort nyomtat egy tételről
/BEKERULT	kinyomtatja az állomanybavétel dátumát
/SZALLITO	kinyomtatja a szállító nevét
/SZAMLASZAM	kinyomtatja a számlaszámot
/CSOPLELT	kinyomtatja a csoportos leltári számot
/FORRAS	kinyomtatja a beszerzési forrást
/KOLCS	kinyomtatja a példány kölcsönözhetőségét
/TELEPULES	kinyomtatja a könyvtárát (KSZR rendszer)
/DUPLASORTAV	dupla sortávolságot hagy
/LELTSZAM:nn	A leltársi szám milyen hosszban nyomtatódjon
/VONALKOD:nn	a vonalkód milyen hosszban nyomtatódjon
/RAKTJEL:nn	a raktári jelzetek milyen hosszban nyomtatódjon
/RAKTAR:nn	a raktár milyen hosszban nyomtatódjon
/CUTTER:nn	a Cutter milyen hosszban nyomtatódjon
/HATAROLO:X	X (pl. pontosvessző) legyen a mezők közti elválasztó. Ezt használjuk, ha excelbe akarjuk az adatokat betölteni. Pl.: /HATAROLO:;

Paraméter	mire jó
/TEZKAPCS	A tárgyszó rekordok kapcsolatait is kinyomtatja

Paraméter	Mire jó
/HATAROLO:X	X (pl. pontosvessző) legyen a mezők közti elválasztó. Ezt használjuk, ha excelbe akarjuk az adatokat betölteni. Pl.: /HATAROLO:;
/DB:N	Miniumum darabszám. Ha csak egyetlen rendezési kulcsot nyomtatunk, akkor számít. Csak a legalább N-szer előforduló kulcsokat írja ki (egyszer).

Paraméter	mire jó
/DREF	a rekordazonosítót írja ki a sor elejére
/URESKIIR	az <üres> szöveget írja ki, ha nem jött létre rendezési kulcs
/ZSAKBA	a kiírt dupla rekordokat a zsákba másolja
/SEMMI	csak a rekordazonsítót írja ki, a rendezési kulcsot nem

2.2.2. Rendezési formátum

A TextLib rendszerben a rendezést a találati halmazok (Lásd <halmaz.txt>!) nyomtatásánál használhatja. A rendezéshez állítson elő a halmazban felsorolt rekordokból az alábbi leírás szerint besorolási adatokat és besorolási tételeket, azokat a rendszer egy rendezési tábla használatával sorba állítja. Ily módon a bibliográfiai tételek betűrendbe sorolásának szabályait meghatározó MSZ 3401-81 szerinti rendezést végezhet el. (Kivétel az összetett családnevet tartalmazó besorolási adat, ebben a családnév nem egy besorolási elem, hanem több.)

A rendezési formátumok előállítását csak a rendszergazdától erre jogot kapott könyvtárosok végezhetik el.

Rendezési formátum keresése

Korábban elkészített rendezési formátumot kereshet meg az alábbi űrlap használatával:

Rendezési formátum bevitele

A besorolási tételek előállításának szabályait a rendezési formátumban meghatározandó rendezési kulcsok adják meg:

A rendezési formátum neve alapján hivatkozhat majd egy halmaz nyomtatásánál a rendezés szabályaira, megjegyzésként tetszőleges magyarázatot fűzhet hozzá. A rendezési kulcs egy besorolási adat képzésének szabályát írja le, egy besorolási tétel több besorolási adatból -rendezési kulcsból- állhat össze:

A név a rendezési formátumban mutatja, hogy milyen besorolási adatokból épül fel a tétel, a besorolási adat előállítási módját pedig a Mező vagy a Kulcs kitöltésével írhatja elő. Egy besorolási adat képzéséhez csak az egyiket választhatja, és gondoskodnia kell arról, hogy a találati halmazban szereplő esetleg különböző rekordok mindegyikére legyen szabály. E helyre tehát egy lista kerülhet, ami a besorolási tétel soron következő besorolási adatának képzési szabályát adja meg a halmaz minden rekordtípusára. Amennyiben a halmaz valamelyik rekordjáról több leírást is készít, csak az első lesz érvényes.

A Mező kitöltésekor a rendezendő rekord egy mezejének karaktersorozattá alakításáról nyilatkozhat, a Kulcs kitöltésekor több mezőből készül egy karaktersorozat. Ezek részleteit a Mező kiválasztó illetve a Kulcskészítés című ablakban írhatja le.

Ha a rendezés Iránya Csökkenő mezőt megjelöli, akkor növekvőből csökkenővé változik az aktuális besorolási adatra nézve. Elérheti tehát, hogy az egymás után következő besorolási adatok ellentétes irányba rendeződjenek.

Ha egy tétel valamelyik besorolási adata hiányzik (pl. szerző nélküli dokumentum), a TextLib az üres besorolási adatot előre sorolja. Az üres Elmarad mező megjelölésével ez megváltozik, az üres helyére csúszik az utána következő besorolási adat (pl. a dokumentum címe).
Ha üres Elmarad jelöletlen:

Egy mezőből egy besorolási adat

A rendezendő rekord egy mezejének karaktersorozattá alakítását szabályozhatja az alábbi adatlap kitöltésével:

Az Adatfájl és a Rekordtípus közül csak az egyiket adhatja meg, ez megszabja, hogy a találati halmaz mely adatfájlhoz vagy rekordtípushoz tartozó elemeiből készüljön e leírás szerint besorolási adat. Mindkettőre a DBSTRUCT-ból kiolvasható sorszáma alapján hivatkozhat.

A Mező tartalmából készül a besorolási adat karaktersorozata. Hármat adhat meg, az első nem üres fog megjelenni. Ha van közöttük hivatkozó mező, akkor megadható a Hivatkozott, amiben egy ugyanilyen Mező kiválasztó űrlapon leírhatja a hivatkozott rekord megjelenítésének szabályát. Ha nem adja meg, akkor beépített mechanizmus szerinti, úgynevezett főmezős megjelenítés történik. A mezősorszámokat DBSTRUCT segítségével találja meg.

A megadott mezők között lehet ismételhető is. A Permutálás mező megjelölése eredményeként az összes ismétlődés szerint készül besorolási adat, tehát a besorolási tételek száma is sokszorozódik. Ellenkező esetben csak az első ismétlődés jelenik meg. Pl. ha szerzők és ezen belül kiadók szerint kell rendezni, és van 5 szerző és 4 kiadó, akkor 20 (megjelölt Permutálás) illetve 1 (megjelöletlen) besorolási tétel képződik.

A rendezendő rekord több mezejének egy karaktersorozattá alakítását szabályozhatja az alábbi adatlap kitöltésével:

A Max. részek mezőbe írt érték korlátozza az egy besorolási adat összeállításához felhasználható részek számát.

A kulcskészítéshez használható kulcsrészek leírása a mező kiválasztáshoz hasonlóan folyik.

A Mező tartalmából készül a besorolási adat karaktersorozatának egy része. Hármat adhat meg, az első nem üres fog megjelenni. Ha van közöttük hivatkozó mező, akkor a Hivatkozások megadására a fenti Kulcskészítés űrlapon kerül sor. Ha nem adja meg, akkor beépített mechanizmus szerinti, úgynevezett főmezős megjelenítés történik. A mezősorszámokat DBSTRUCT segítségével találja meg.

A megadott mezők között lehet ismételhető is. Az elkészülő besorolási adatrészben az ismétlődésszámot a Max. ismétlődések mező kitöltésével szabályozhatja, ennek hiányában az összes ismétlődés bekerül.

Az Előtte, Utána és Közte konstans szöveget tartalmazhat, ami a mezőből keletkezett szöveg előtt, után, illetve az ismétlődések között jelenik meg.

A Helyette mezőbe írt szöveg fix része lesz egy besorolási adatnak, ha egyetlen mezősorszámot sem tölt ki.

A rendezési helyettesítési jelek (lásd bill.txt!) használatával tudja módosítani a rendezést azokban az esetekben, amikor a helyes mezőtartalom helytelen rendezési sorrendet eredményez. Ilyen lehet pl. a római számok vagy a betűvel leírt számok esete. Rendezési helyettesítési jelek használatával leírhatja a módosítani kívánt szövegrész rendezési helyettesítőjét:

A példa egy olyan rendezési formátum elkészítését tartalmazza, amelyben a rendezés kulcsai a kötet szerzője, címe és kiadási éve. A szabadalom típusú dokumentumnál a SZERZO helyett a TULAJDONOS szerepel, a cím többkötetes mű esetén tartalmazza a közös címet és a kötetjelzést is. Rendezési formátum készítésére csak akkor van módja, ha kapott jogot a rendszergazdától.

2.2.3. Kiadvány formátum

A kiadvány készítés alatt egy olyan nyomtatást értünk, ahol a (valamilyen szempont szerint rendezett) tételek nyomtatása után még egy vagy több index is generálódik, és ezek is kinyomtatódnak. A kinyomtatott tételek egyedi sorszámmal vannak ellátva, az indexben erre való hivatkozás történik.

A kiadvány készítése egy előre létrehozott találati halmazzal történhet.

Neve:	Név
rendezés Iránya:	jelöletlen
üres Elmarad:	megjelölt
Névelős:	jelöletlen
A "Mező" mezőben válasszon beszúrást, így a "Mező kiválasztó" ablakba jut!
Neve:	Szerző neve
Rekordtípus:	53 (DOKUMENTUM)
Mező	70 (SZERZO)
Permutálás:	megjelölt

Neve:	Tulajdonos neve
Adatfájl:	110 (SZABKOT)
Mező:	113 (TULAJDONOS)
Permutálás:	megjelölt

Neve:	Közös cím - kulcs
rendezés Iránya:	jelöletlen
üres Elmarad:	megjelölt
Névelős:	megjelölt
A "Mező" mezőben válasszon beszúrást, így a "Mező kiválasztó" ablakba jut!
Neve:	Közös cím - mező a közöshöz
Rekordtípus:	53 (DOKUMENTUM)
Mező:	89 (DOK)
Permutálás:	jelöletlen

Neve: Közös cím - mező a közösben
Rekordtípus:	53 (DOKUMENTUM)
Mező:	48 (FOCIM), 50 (PARHUZAMOSCIM), 52 (CIMADAT)
Permutálás:	jelöletlen

Neve:	Kötetjelzés - kulcs
rendezés Iránya:	jelöletlen
üres Elmarad:	megjelölt
Névelős:	megjelölt
A "Mező" mezőben válasszon beszúrást, így a "Mező kiválasztó" ablakba jut!
Neve:	Kötetjelzés - mező
Rekordtípus:	53 (DOKUMENTUM)
Mező:	88 (RESZJELZES)
Permutálás:	jelöletlen

Neve:	Cím - kulcs
rendezés Iránya:	jelöletlen
üres Elmarad:	megjelölt
Névelős:	megjelölt
A "Mező" mezőben válasszon beszúrást, így a "Mező kiválasztó" ablakba jut!
Neve:	Cím - mező
Rekordtípus:	53 (DOKUMENTUM)
Mező:	48 (FOCIM), 50 (PARHUZAMOSCIM), 52 (CIMADAT)
Permutálás:	jelöletlen

Neve:	Kiadási év - kulcs
rendezés Iránya:	jelöletlen
üres Elmarad:	megjelölt (nincs jelentősége)
Névelős:	jelöletlen
A "Mező" mezőben válasszon beszúrást, így a "Mező kiválasztó" ablakba jut!
Neve:	Kiadási év - mező
Rekordtípus:	53 (DOKUMENTUM)
Mező:	49 (MEGJEVE)
Permutálás:	jelöletlen

Kiadvány formátumot a rendszergazda definiálhat (és azok a dolgozók, akiknek ehhez ő jogot ad). Kiadvány formátumot a rendszergazda a Rendszer / rendszerelemek Bevitele / kiAdvány formátum menüpontból indulva adhat meg. A többi dolgozó (a rendszergazda is) a kiadvány készítés indítása után feltűnő ablakban a Formátum> mezőbe beszúrással.

A kiadvány formátum definiálása nagyon hasonlít a nyomtatási formátum definiálásához. (Lásd:nyform.txt) Annyival több annál, hogy definiálni kell az indexek készítéshez és nyomtatásához szükséges dolgokat. Itt most csak azokat a részeket ismertetjük, amik a nyomtatási formátumnál nem szerepeltek.

Indexelő modul mezőben annak a modulnak a nevét kell megadni, ami az indexeket készíti el. Ilyen jelenleg csak egy van (INDEXGEN), de hamarosan definiálhatóvá tesszük az indexek generálását az output nyelv segítségével.

Index kiíró modul mezőben az indexeket kiíró modul nevét kell megadni. Egyelőre ebből is csak egy van (INDEXPRT), de ez is definiálható lesz.

Az INDEXGEN modul a következőket kezeli (ha semmit nem adunk meg, akkor csak egy közös index készül):

Paraméter	mire jó
/CIM	készül külön cím index
/SZERZO	készül külön szerző index
/TARGYSZO	készül külön tárgyszó index
/KOZOSNEM	ne készüljön közös index
/ANAL	az dokumentum analitikáiba is belemegy, abból is készül index Ha itt megadjuk, akkor érdemes a nyomtató modul paraméterei közt is megadni, hogy ki is nyomtatódjanak az analitikák.

Az index nyomtatásakor más hasábszám használható, mint a tételek nyomtatásakor. Ezt az index Hasábok mezőben lehet megadni.

Megjegyzés: a Fölötte mezőben ne felejtsünk el megadni valami szöveget, ami tartalmazzza a % jelet, különben nem lesznek sorszámok nyomtatva a tételek előtt, és ilyenkor az index (ami a tételszámokra hivatkozik) elég nehezen használható.

A kiadvány készítést minden dolgozó az Egyéb / kiAdvány készítés menüpontból érheti el.

Az ablak művelet mezőjében mindig láthatjuk, hogy mi történuk éppen. Kezdetben ez adatmegadás-t mutat.

Először meg kell adnunk azt a Halmaz-t, amit használni akarunk. A lokális menüből a Beszúrás menüponttal (F9) választhatunk a meglevő halmazok közül.

A Formátum mezőbe a kiadvány formátum kerül. Itt is F9-re kapunk listát a meglévő kiadvány formátumokról. Azoknak a dolgozóknak, akiknek joguk van kiadvány formátum bevitelére, az expand ablakban látszik a Bevitel gomb is.

Amelyik mezőt már kitöltöttük, azt meg lehet részletezni (ALT/F9). A Halmaz esetében a halmaz elemeit tekinthetjük meg, a Formátum-nál pedig a kiadvány formátum adatait. Ha olyan dolgozó teszi ezt, akinek van joga változtatni a kiadvány formátumokon, az tud módosítani is.

A mezők kitöltése után (ekkor a művelet mezőben az 'indítható' szöveg jelenik meg) használhatóvá válik a Rendben gomb, amivel el lehet indítani a a kiadvány készítést. Ekkor először a nyomtató állapot ablak tűnik fel. Ebben kell beállítani, hogy hova és hogyan akarunk nyomtatni. Ez a beállítás a kiadvány készítés sajátja, a rendszerben egyébként is meglevő nyomtató beállítást nem befolyásolja.

Ebben az ablakban mindig az a default beállítás, hogy fájlba akarunk nyomtatni, és nem akarunk mustrát. Ezt természetesen meg lehet változtatni. Ha az ablakból a Mégsem gombbal lépünk ki, természetesen nem megy tovább a kiadvány készítés. Ellenkező esetben azonban elindul.

Ha fájlba irányul a nyomtatás, akkor az első teendő, hogy meg kell adnunk a fájl nevét. Ha ezen túlvagyunk (és nem kértünk mustrát), akkor a művelet mezőben követhetjük, hogy hol tart a program. Itt először a 'rendezés' szöveg jelenik meg. Ha elkészült a rendezett halmaz (és nem 0 elemű), akkor következik a 'nyomtatás'. Ha ez is elkészült, akkor az 'index készítés' következik. Az 'index nyomtatás' után pedig megjelenik a 'Kész' üzenet.

Kiadvány formátumot direktben (nem kiadvány készítés közben) keresni csak a rendszergazda tud, a Rendszer / Rendszer adatok keresése / kiAdvány formátum menüponttal:

Az általunk készített index generáló modul az INDEXGEN többféle indexet is tud gyártani. Közöset, cím szerintit, szerző szerintit, tárgyszó szerintit. Ezek közül a közös index az, ami nem egészen egyértelmű. Ebbe az indexbe a következő alakú bejegyzések kerülnek:

2.2.4. Keresőkérdés

A TextLib rendszerben lehetőség van a keresőnyelv használatára. Ennek segítségével lehet azokat a bonyolult kérdéseket megfogalmazni, amiket az ablakos keresésben már nem lehetett feltenni. A nyelv lehetőséget ad keresésre az indexeken, halmazok projektálására, szűkítésére, valamint lehetővé teszi halmazműveletek elvégzését is.

A keresőnyelven megírt programokat - nevezzük ezeket keresőkérdésnek - el lehet tárolni, legközelebb betölteni, szerkeszteni, futtatni. Minden felhasználónak lehetnek saját keresőkérdései. Ezen kívül lehetőség van arra is, hogy a rendszergazda definiáljon olyan keresőkérdéseket, amiket mindenki fel tud használni.

A keresőkérdés helyettesítheti a projekciót. Definiálhatunk ugyanis olyan keresőkérdést, aminek egyetlen paramétere van, egy halmaz. Az ilyen keresőkérdést használhatjuk projekcióként.

Szinte mindenkinek (olvasó, könyvtáros, rendszergazda) a főmenüjében a Keresés menüpont alatt megtalálhatók a következő menüpontok, amiknek a segítségével a keresőkérdéseket kezelheti:

Ebben az ablakban a felhasználó a saját keresőkérdéseit szerkesztheti, futtathatja, elmentheti és betöltheti:

Keresőkérdések futtatása (Kész kérdések)

Sok olyan keresőkérdés lehet, amire mindenkinek szüksége van. A rendszergazdának lehetősége van arra (Rendszer/Bevitel/Keresőkérdés menüpont), hogy ilyeneket definiáljon, és ezeket minden könyvtáros és olvasó használhassa.

A keresés/kész Kérdések menüpont kiválasztása után megjelenik az alábbi ablak:

Ha a kérdés tartalmaz paramétereket, akkor megjelenik egy ablak, amiben a paraméterek értékeit kell megadni. Ha a keresőkérdés tartalmaz NEVEZD utasításokat, akkor a paraméter megadásakor még expand-ot is lehet kérni.

Ha a keresés sokáig tart, akkor a képernyő alsó sorában kapunk információt arról, hogy hány tételt nézett már végig a program, és ebből hány találat képződött.

Ha elindítottuk a keresést, de még nem ért véget, akkor a Kilép menüpont kiválasztásával tudjuk abbahagyni a keresést. Természetesen rákérdez a program, hogy valóban ezt akarjuk-e csinálni.

A rendszergazda a kersőkérdés bevitelekor igazából két dolgot is definiálhat: keresőkérdést vagy projekciót (esetleg mindkettőt egyszerre). A projekció ezentúl a keresőkérdés egy speciális esete lesz, az az eset, amikor éppen egy paramétere van a keresőkérdésnek, és az egy halmaz. (pl: SZUKITS kotet es dok &%1).

Proj.név: Ha projekciónak is akarjuk használni a keresőkérdést, akkor ezt a mezőt kell kitölteni. Ha ezt a mezőt kitöltjük, akkor csak olyan keresőkérdést fogad el a program, amiben csak egy darab halmaz paraméter szerepel.

Olv.név: Az olvasó ezen a néven fogja látni a keresőkérdést. Ha üresen hagyjuk, akkor egyáltalán nem fogja tudni használni.

A két mező közül legalább az egyiket ki kell tölteni, e nélkül nem lehet a keresőkérdést tárolni.

Keresőkérdés: Ebbe a mezőbe kell beírni a keresőkérdést. Tárolás előtt ez mindig lefordítódik, és csak akkor lehet tárolni, ha nincs benne hiba.

Próba A gomb megnyomására a program lefordítja a keresőkérdést, és ha nem volt benne hiba, akkor le is futtatja. Ha voltak találatok, akkor megjelenik a találati halmaz. A halmaz megnézéséből kilépve ez a halmaz automatikusan törlődik is.

Ebben az ablakban a felhasználó a saját keresőkérdéseit szerkesztheti, futtathatja, elmentheti és betöltheti:

Keresőkérdések futtatása (Kész kérdések)

A keresés/kész Kérdések menüpont kiválasztása után megjelenik az alábbi ablak:

Ha a keresés sokáig tart, akkor a képernyő alsó sorában kapunk információt arról, hogy hány tételt nézett már végig a program, és ebből hány találat képződött.

Olv.név: Az olvasó ezen a néven fogja látni a keresőkérdést. Ha üresen hagyjuk, akkor egyáltalán nem fogja tudni használni.

A két mező közül legalább az egyiket ki kell tölteni, e nélkül nem lehet a keresőkérdést tárolni.

Keresőkérdés: Ebbe a mezőbe kell beírni a keresőkérdést. Tárolás előtt ez mindig lefordítódik, és csak akkor lehet tárolni, ha nincs benne hiba.

2.2.5. Általános statisztika

Az általános statisztika segítségével egy tetszőleges módon előállított halmaz elemeire készíthetünk (két dimenziós) statisztikákat. Megadhatjuk, hogy mik legyenek a statisztika oszlopai, és sorai.

A statisztika használata igen egyszerű, ellentétben a statisztikai szempontok, és bontások definiálásával. Ez utóbbiakat természetesen csak a rendszergazda végezheti.

Az általános statisztika készítésekor felhasználhatjuk az állomány statisztikai (lásd: <all_stat>) szempontokat is. Fordítva ez természetesen nem érvényes.

Statisztika használata

A főmenü Egyéb/sTatisztika menüpontjának kiválasztásakor az alábbi alakú képernyőn adhatók meg az igényelt statisztika paraméterei:

Korábbi statisztika elővétele, nyomtatása

Ha olyan nevet adunk meg, ami már létezik, akkor azt az eredmény rekordot betölti. Ezt ki tudjuk nyomtatni, akár különbözö paraméterekkel is. Az Eredmény: mezőt részletezve megnézhetjük a statisztika rekordot, és változtathatunk is rajta, ami a nyomtatásra is hatással van. Törölhetjük is, ha már nincs rá szükség.

Egyéb NEM mező: Elhagyandó az EGYÉB oszlop. A statisztika rekordban mindig benne van, csak kinyomtatni nem kell.

Oszlopok: 1. szélessége mező: Az első oszlop szélessége megadható. Ha pl. könyvcímeket tartalmaz, akkor érdemes nagyobbra venni, mint a default 20 karakter.

Sorok: Összesítő NEM mező: Megadható, hogy kell-e az egyes kiemelt tételek után összesítő sor. Ha kipipáljuk ezt a mezőt, akkor minden statisztika sor valóban egyetlen sor lesz (nem kettő, ami a default).

Minimum db.: mező: Megadható minimum darabszám. Csak azok a sorok nyomtatódnak, amikben ennél több a kiírt oszlopokba kerülő értékek összege. Ennek igazából csak akkor van értelme, ha az EGYÉB oszlopot elhagyjuk, mert ha nem, akkor minden sorban pontosan ugyanannyi az oszlopok osszege.

Új statisztika készítése

Ha nincs még az adott néven készült statisztika, akkor kell csak megadnunk a következő mezőket:

Statisztika eredménye

A statisztika a következő formában nyomtatódik (például egy 'Nyelv' szempont szerinti lista, állományok szerinti bontásban):

Az elején az a név jelenik meg, amit a statisztika készítéskor megadtunk. Ezt követi a készítés és nyomtatás dátuma, a szempont (Nyelv) és a bontás (Állomány).

A statiszika minden sora igazából két sor. Az első példányszám, a második pedig a szempont definíciójánál megadott mező értékek összege (pl: példány árak). A második sor elhagyható, ha a statisztika eredmény rekordban, vagy a statisztika készítés előtt a statisztika bontás rekordban az Sorok: [ ] Összesítő NEM mezőt kipipáljuk.

A statisztika nyomtatása 160 oszlopos és 18 soros lapokra történik. Ha a statisztika szélessége még ennél is nagyobb, akkor a sorok törnek. File-ba nyomtatás után a megtört sorokat egy tetszőleges editorban egyberagasztva kaphatjuk meg a teljes táblázatot (amit kinyomtatni nem fogunk tudni, legfeljebb darabokban).

2.2.5.1. Statisztika szempont

Statisztikai szempont definiálása

A statisztika szempontjait a rendszergazda definiálja a főmenü Rendszer / rendszerelemek Bevitele / Statisztikai szempont menüpontjának választásával:

A Neve mezőben értelemszerűen a szempont nevét kell megadni (pl. dokumentumtípus, nyelv, kiadási év, olvasói kategória, stb). Ezzel a névvel lehet majd a szempontra a statisztika készítésekor hivatkozni.

Az éRték mezőben adhatjuk meg, hogy mit kell a statisztika számítás során összegezni. Ha itt nem adunk meg semmit, akkor csak a rekordok számlálása történik meg; példányok esetében a mező alapértelmezett értéke a beszerzési ár.

A statisztika definiálásakor lehet megadni azt is, hogy milyen rekordokra van értelmezve a statisztika. Egy olvasókat számláló statisztikát készíteni példány rekordokból álló halmazon nem lenne túl szerencsés. Az Adatfájlok és Rekord típusok mezőkben sorolhatjuk fel, hogy milyen rekordokra van értelmezve a statisztika. Ha egyik mezőben sem adunk meg semmit, akkor PELDANY rekordtípust tételez fel a program.

Ha az ÖSszegzés mezőt bejelöljük, a statisztika készítésekor az adott szempont szerinti statisztika sorainak végén a szempont egyes értékei után egy "Összes" fejlécű oszlopban a sorösszeg is kinyomtatásra kerül.

Ha az Értékek Száma ismert, a Mező mező nem értelmezett. Kötelező viszont az ÉrtékKészlet. Itt kell megadni a szempont értékeit, azt az ismert, véges számú osztályt, amelybe az adott szempont szerint sorolni lehet a példányokat. Ilyen szempont például a "dokumentumtípus" vagy a "tartalom fő jellege", általánosságban minden olyan szempont, ahol előre ismert számú és értékű lehetséges értéke van a szempont szerinti osztályozásnak.

Ha az Értékek Száma nem ismert (ilyen pl. a szállító, a nyelv vagy a kiadási év) az ÉrtékKészlet mező nem értelmezett. A Mező viszont kötelező. Ennek megadásával a szemponthoz asszociált mezőt, azaz azt a mezőt kell ilyenkor specifikálni, ami alapján a besorolás történik.

Ha a Mező vagy az Értékkészlet mezők egyikét kitöltöttük, akkor az Értékek száma mezőt már nem tudjuk változtatni. Ha mégis ezt akarjuk, akkor az előbb említett mezők tartalmát ki kell törölni.

Ha az olvasókat akarjuk kategóriák szerint megszámolni, akkor jön jól egy ilyen statisztika.

Ha a kölcsönzéseket akarjuk olvasói kategóriák szerint megszámolni, akkor érdemes egy ilyen szempontot készíteni:

Ha a kölcsönzéseket akarjuk a példányok állománya szerint megszámolni, akkor érdemes egy ilyen szempontot készíteni:

2.2.5.2. Statisztikai bontás

Definiálhatók statisztika bontási szempontok is. Ezek segítségével szabályozhatjuk, hogy a statisztika egyes soraiba mi kerüljön. Definiálhatunk pl. "Állományonként", "Számlaszám", "Törl.jegyz", "Raktár" nevű bontást. De készíthetünk két 'mélységű' bontást is, pl: "Állomány/számlaszám" néven.

A statisztika bontás definiálása szinte teljesen megegyezik a rendezési formátum (lásd: rendezes) definiálásával. Itt is az a feladat, hogy megadjuk: egy rekordhoz mi módon kell elkészíteni a bontási (rendezésnél: rendezési) kulcsot. Pl: az "Állományonként" nevű bontásnál egyszerűen a példány rekorodok Állomány mezőjet kell megadni.

A statisztika készítéskor a statisztika sorai pontosan azok lesznek, amik a bontás alkalmazásakor előállnak (pl: az "Állományonként" bontásnál az állományok nevei).

A statisztika szempontjait a rendszergazda definiálja a főmenü Rendszer / rendszerelemek Bevitele / Statisztika bontás menüpontjának választásával:

A bontási Kulcsok általában egyetlen elemet tartalmaz, ami azt adja meg, hogy mik lesznek a statisztika egyes sorai. Megadhatunk két kulcsot is (pl: Állomány, Számlaszám), ilyenkor az első kulcsokat kiemelten kezeli a statisztika nyomtatás (külön sorban jeleniti meg), és a második kulcsokból képződnek a statisztika sorai. Ezzel a módszerrel készíthető pl. lista Állományok szerinti bontásban a számlaszámokról.

Az Oszlopok: 1. szélessége mezőben az első oszlop szélességét adhatjuk meg, ha nem felel meg a default 20 karakteres szélesség.

A Sorok: Összesítő NEM mező kitöltése esetén az elkészült statisztika nyomtatásakor az összesítő sorok nem nyomtatódnak ki. Ezt a kész statisztika rekord változtatásával később is módosíthatjuk, mivel ugyanez a mező megvan abban is.

A Minimum db.: mezőben azt adhatjuk meg, hogy csak azok a sorok nyomtatódjanak ki, amikben a kinyomtatandó oszlopokba került értékek összege legalább ennyi. Ennek főleg akkor van értelme, ha az EGYÉB oszlop elhagyását kértük nyomtatáskor.

Ha van már egy korábban lekeresett halmazunk, a Próba gomb megnyomásával megtekithetjük, hogy milyen kulcsok képződnek az egyes rekordokból. Ily módon gyorsan kiderül, ha valamit nem jól definiáltunk.

Példák statisztikai bontás definiálására

Példányokról készülő statisztikát lehet a számlaszám (csoportos leltárkönyv) szerint is bontani. Ennek főleg állomány statisztika készítésénél van értelme, ez lesz a gyarapodási lista.

Ezt a bontást használhatjuk pl. állomány statisztika összesítő nyomtatásakor. Ez a bontás így definiálva nem csak példányokra jó, hanem kölcsönzésekre is. Utóbbi esetben a kölcsönzött dokumentum állományát adja meg. Nem kell tehát külön bontást csinálni, ami a példányok állományát adja, és egy másikat, ami a kölcsönzött példányok állományát adja.

Ezt a bontást használhatjuk szinte mindig, ha olvasók kategóriája szerint szeretnénk a statisztika sorok bontását. Ily módon definiálva nem csak olvasók, hanem kölcsönzések (kölcsönző olvasó), és tartozások (tartozó olvasó) kategóriáját is meg tudja adni. Ez azért jó, mert elég egy bontást definiálnunk, és azt többféle statisztikához is fel lehet használni.

2.2.6. Rendszerhasználati jog

A rendszergazda feladata, hogy jogokat definiáljon, és ezeket a dolgozókhoz rendelje. A jogok is rekordokban vannak tárolva, a többi rekordhoz hasonlóan lehet őket létrehozni és módosítani.

A jogok segítségével oldható meg az is, hogy ugyanazt a rekordot különböző dolgozók (olvasók) más-más ablakokkal tudják megnézni.

A jogokat egyelőre két szinten tudjuk használni. Azokat a jogokat, amiket minden dolgozóra (vagy olvasóra) ki akarunk terjeszteni, a Rendszer adatai közé kell felvenni (Default dolgozói jogok, Default olvasói jogok). Azokat a jogokat pedig, amiket csak egy-egy dolgozónak akarunk adni, annak a dolgozónak a jogai közé kell beraknunk (dolgozó módosítása). Terveink között szerepel, hogy csoportokhoz is lehessen jogokat rendelni.

A rendszergazdának nem kell jogokat adni, neki úgyis mindig mindenhez joga van. Az Adatfájl modulok-at pedig nem érdemes változtatnia, mert más modulokban esetleg nem tud bármit elvégezni.

2.2.6.1. Adatfájl modulok

Minden adatfájlra megadható, hogy milyen modullal (ablakkal) lehet ebbe az adatfájlba tartozó rekordokat:

Egyelőre csak az InfoKer által készített modulok közül lehet választani. Aki más adatlapot szeretne egyes adatfájlokhoz használni, az InfoKer-től rendelheti meg. Későbbi terveink között szerepel egy olyan program, amivel az adatlapok szabadon definiálhatók.

Ha a négy modul közül csak egyet akarunk megváltoztatni, akkor a többi háromba írjuk be a 'default' értéket.

Jog megadásával megváltoztathatjuk az alapértelmezett megnézési formátumot. Egy keresés végén a találatokat megnézés módban ablakosan nézve alapértelmezetten az ablak űrlapos formáját látjuk. A változtatás az űrlapos formát változtathatja meg, pl. dokumentumok esetében cédula formává.

Jogok adásával az alapértelmezettől többféle cél érdekében eltérhetünk, pl:

A megnézési formátum megváltoztatásához a dolgozó űrlapjának két mezőjét kell módosítani:

2.2.6.2. Adatfájl jogok

Minden adatfájlra megadható, hogy mihez van joga a felhasználónak. A következő lehetőségek vannak (természetesen több is választható egyszerre):

Az ÖSSZES adatfájl használatára vonatkozó megengedő illetve tiltó jogot adhat meg az alábbi módokon:

Ha sorszámnak -1 értéket ír be, akkor a bejelölt jogok az összes adatfájlra érvényessé válnak, a jelöletlenek a máshol beállított vagy alapértelmezés szerinti érvényességgel változatlanok maradnak.

Ha sorszámnak -2 értéket ad, akkor a jelöletlen jogok az összes adatfájlra törlődnek, a bejelöltek a máshol beállított vagy alapértelmezés szerinti érvényességgel változatlanok maradnak.

Ha egy dolgozónak meg akarjuk tiltani, hogy bármit is töröljön vagy módosítson, akkor egy jog definiálásánál a következőket állítsuk be: Adatfájl sorszáma legyen -2, és csak a Megnézhet, Nyomtathat, Bevihet mezőket jelöljük be.

2.2.6.3. Rendszer jogok

2.2.6.4. Nyomtatási jog

A nyomtatási jog megadásakor a következő lehetőségek közül kell azokat bejelölni, amikhez a felhasználónak majd joga lesz. Ha egyet sem jelölünk be, akkor sehova sem nyomtathat.

2.2.7. Projekció

!!! Ez a projekció megadási lehetőség meg fog szűnni! Helyette a
!!! keresőkérdés használható, amit sokkal egyszerűbb megadni.
!!! Használata megegyezik a régi projekcióval
!!! Lásd: <kerkerd.txt>

A projekció egy olyan (több lépésből álló) művelet, ami egy találati halmazból egy másik találati halmazt képez. Egyes rekordokra adott a "Keresés" és a "Részletezés" lehetősége. Vagyis meg tudjuk keresni mondjuk egy adott szerző könyveit, és a konkrét könyv esetében meg tudjuk nézni szerzőit. A projekció arra való, hogy egy halmaz elemeire is meg tudjuk tenni ugyanezt. Azaz: a halmazba gyűjtött szerzők könyveit kereshessük, vagy a halmazba lekeresett könyvek szerzőit gyűjtsük össze. A projekció definiálásánál szabályokat kell megadnunk. Ezek mondják meg, hogy milyen rekordok esetében milyen módon tudunk tovább menni az eredmény rekordok felé. Kétféle szabályt tudunk megadni:

A programhoz adott példa adatbázisban néhány projekciót is definiáltunk, hogy egyszerűen ki lehessen őket próbálni.

Neve: Könyvek összes szerzője
Projekció adatai:
Rekordtípus: 53 (DOKUMENTUM)
Mező sorsz.: 70 (SZERZO)
eredmény Rekordtípus-ok:63 (ALKOTO) es 57 (TESTULET)

Neve: Szerzők összes könyve
Projekció adatai:
Rekordtípus: 63 (ALKOTO)
Indexfájl: 74 (SZERZOJE)
Rekordtípus: 57 (TESTULET)
Indexfájl: 74 (SZERZOJE)
eredmény Rekordtípus-ok:53 (DOKUMENTUM)

2.2.8. Feladat

2.2.9. Help rendszer

A TextLib egy háromszintű help (segítség, súgó) rendszert tartalmaz. Kérhet segítséget arra vonatkozóan, hogy mire való az az ablak, ami éppen a képernyőn van (Aktuális ablak mire való), megtudhatja, hogy mit tehet a billentyűzettel és az egérrel abban a mezőben, amiben éppen van (Program használata), valamint azt is megkérdezheti, hogy mi a kitöltési utasítása az éppen aktuális mezőnek (Adatbázis szerkezet). Ez a háromféle help különböző billentyűkkel, vagy egy menüből választással érhető el.

3. Adatbázis szerkezet

3.1. *.DBF, *.NDX, *.POS

3.2. Rekordtípus

3.3. Adatfájl

3.3.1. Rekordazonosító

3.4. Mezők

3.5. Rekord kapcsolatok

3.6. Indexek

Billentyű	mire jó
F1	Aktuális ablak mire való
SHIFT/F1	Adatbázis szerkezet
SHIFT/F2	Program használata
F2	Help menü
egér középső gomb	Help menü

3.6.1. Névelő lista

A TextLib adatmezőibe előre írt névelők a rendezés szelektivitását rontják, illetve szavas indexelésnél a gyakori előfordulás miatt az információtartalmuk csekély. Ezért az alábbi listában szereplő névelők a sorba rendezendő karaktersorozatokból kimarad(hat)nak.

3.6.2. Stopword lista

A TextLib adatmezőibe írt egyes szavak a rendezés szelektivitását rontják, illetve szavas indexelésnél a gyakori előfordulás miatt az információtartalmuk csekély. Ezért az alábbi listában szereplő szavak, az úgynevezett stopword-ök a sorba rendezendő karaktersorozatokból kimarad(hat)nak.