Már, hogy ISAM? (Persze fizikailag, mert logikailag, mondjuk Cobol-bol még rekord relatív is van. És egy sima szekvenciális file is ISAM lesz végül is.)
Nálunk megy az Oracle, igaz, mainframe-en és jó sok munka volt a hangolásával, de stabil. Nem biztos azonban, hogy mindenre egy ilyen "nagyágyú" kell. Ha viszont több féle megoldást használtok, akkor az mindenképp adminisztrációs többletmunkát jelent és előbb-utább beleszálltok abba a problémába, hogy az egyes rendszerek között hogy lehet mozgatni az adatokat.
Az Oracle-t protezsálják agyba-főbe... vidám kalandjaink voltak már azzal is, olvashatók itt az "Oracle fórum" topikban... de vannak olyan feladatok, amikhez egyszerűbb eszköz kívánkozik... mondjuk olyan, amivel a programnak már le is kell futnia addigra, amíg az Oracle még csak a "No listener"-ig jutott el...
Leginkább univerzálisan kellene megoldani a problémát... az igényesebb dolgokból nyilván adatbázis lesz, de az egyszerűbb esetekre is kellene valami... talán a Berkeley DB jó lesz...
Na ebből is látszik, hogy azzal kellett volna kezdenem, hogy milyen nálunk az ISAM-file, azaz mit kellene emulálnom: ISAM-kulcs: a rekordban valahol (KEYPOS) 1-256 hosszú (KEYLEN) mező, jobb ha egyedi, de lehet dupla is. (Az úgynevezett "másodlagos kulcs"-okat szerencsére sose használtuk) Hozzáférési módok: INPUT/INOUT/OUTIN/OUTPUT - csak_olvasás/ olvasás+karbantartás/ létrehozás olvasás+karbantartásra/ léterhozás csak soros írásra Párhuzamos karbantartás (Shared Update): Több INPUT és INOUT módú megnyitás lehetséges egyidőben (esetleg egy OUTIN is) Soros feldolgozás: GET/GETR/PUT/SETL_B/SETL_E - olvasás/ olvasás_vissza/ írás/ pozícionálás_elejére/ pozícionálás_végére Kulcsos feldolgozás: GETKY/INSERT/STORE/SETL_K - olvasás/beszúrás/felülírás (a duplakulcs kezelésében különböznek)/ pozícionálás kulcs alapján Zárolás: GET/GETR/GETKY "LOCK" operandussal, PUTX/UNLOCK - visszaírás/ lock_megszüntetése
Nem. A REGIONAL tipusú file-oknál tulajdonképp egy szektor-emuláció történik és a rekord helyét léegalább sáv-pontosságig (Reg(3)) illetve teljes rekord-pontosságig (reg(1) és reg(2)) számítással határozza meg a rendszer. A Reg(3) sávon belül már ugyanúgy keres, mint az indexelt file.
A ISAM kulcs bárhol lehet a rekordban(KEYLOC paraméter), mert felíráskor a rekord adatmezejéből kiemelődik a (felhasználói program által nem hozzáférhető) kulcsmezőbe (a C-K-D) struktúrából a felhasználói program közvetlenül csak a "D", "Data" mezőt éri el).
ISAM-ban nem lehet dupla kulcs (ellentétben a VSAM-KSDS-sel) és a file feltöltése a kulcsok szigorúan monoton növekvő sorrendjében történik. Feltöltéskor a sávokon (TRKOFL) illetve a cilinderenek (CYLOFL) lehet hagyni szabad helyeket a direkt update módon beszúrt rekordoknak. Amíg ez a heyl el nem fogy, a file működése nem lassul észrevehetően. Egyébként célszerű a file-t (ha direkt update megengedett rá) időnként reorganizálni. Ez egy szekvenciális outputot és egy újra betöltést jelent és ilyenkor az update-re fenntartandó területek újra felszabadulnak.
A hardverrel igen sok mindent "meg lehet beszélni", mert a file-kezeléshez közvetlenül kapcsolódó csatornaprogramok mellett a lemezvezérlőt is lehet "idomítani" a SetFileMask parancsban átadott extenthatár-információval.
A file-kezelésnek egyébként két szintje van: a logikai (LIOCS), amikor a rendszer készen adja a szükséges csatornaprogramokat, a felhasználói programnak csak a file logikai struktúráját leíró DTF vagy DBC táblát kell tartalmaznia, és a fizikai (PIOCS), amikor a felhasználó maga állítja össze a teljes csatornaprogramot és egy CCB-vel csupán azt közli, hogy mely berendezésre akarja azt futtatni és hogy hol lesz a csatornaprogram kezdőcíme.
Hogy mennyire hatékony ez a kettős utasításkészlet (ALU + csatorna), az abból látszik, hogy például egy szalagfile listázása sornyomtatóra üres, oprendszer nélküli gépbe pultról "begombolva" mindössze 72 byte-ot foglal le (+ az adatterület, ahova a szalagrekordot olvassa). Ugyanez lemezre egy kicsit bonyolultabb, elvisz 120 byte-ot...
Ha egy be-IPL-ezett gépen "tisztességesen" használunk file-okat, akkor a file kezelése (hacsak magunk nem írtunk elő fizikai szintű kezelést - ami azért néha a mazochizmus határás súrolja) nem része a felhasználói programnak. LIOCS használatakor a DTF fordításakor generálódó modulnév hozza be linkeléskor a megfelelő csatornaprogramot és CCB-t tartalmazó kezelőmodult. Ha valamilyen tranzakciókezelő rendszert (CICS, IMS, TUBES) használunk, akkor a programba még ennyi sem kell, minden erőforráskezeléssel kapcsolatos feladatot elvesz a programtól a tranzakciókezelő ("rendszer a rendszerben"). Így egy átlagos bonyolultságú tranzakciós program lefordítva, belinkelve néhány kByte szokott lenni. Ráadásul ezek reentrant programok, tehát önmagukkal párhuzamosan több független adathalmazzal is futhatnak anélkül, hogy magát a programkópiát többszörözni kellene.
Ez nem inkább a hash-jellegű file-kezelésre vonatkozik (REGIONAL(3) vagy mi a manó)? Az ISAM-kulcs ugyanis akár 256-byte is lehet, és nem feltétlenül a rekord elején van, lehetnek duplakulcsok.. továbbá az adatblokkok időnként betelnek, és ilyenkor esetleg az az index-blokkokat is reorganizálni kell... elég bonyolult lenne ezeket a hardverrel is megbeszélni...
No hát itt van az eltérés. Az indexelt file kezelésénél a felhasználói program átadja a csatorna részére azt a "csatornaprogramot", aminek az egyik eleme egy kulcs szerinti keresést ír elõ és aminek a címrésze arra a tárhelyre mutat, ahol az van, hogy "NEVEMTEVE". Ezután valóban SVC, a csatorna elindul és a CPU szabaddá válik és a csatorna elkezd keresni. Mivel ilyenkor már nyitott a file, (tételezzük fel az egyszerûség kedvéért, hogy egyetlen lemezen van a file) a csatornaprogram tartalmazni tudja a cilinderindextábla elsõ sávjának címét. Erre indít egy többsávos keresést, majd az elsõ, a keresettnél nagyobb kulcsot megtalálva behozza a hozzá tartozó cilindercímet oda, ahol azt a következõ csatornaparancsok címzeni fogják. Folytatva a láncot, átpozicionál a megtalált címre és ott megtalálja a sávindextáblát, amibõl megintcsak beolvassa az elsõ, a keresettnél nagyobb kulcshoz tartozó rekordot és az abban talált sávcímmel kiegészíti a korábban "megszerzett" pozicionálási címet. Elvégzi a fejkiválasztást, levárja a sáv elejét és elkezdi olvasni a sávot, keres. Ha a file blokkolatlan, akkor kulcs egyenlõre keres és vagy van ilyen rekord, vagy eléri az elsõ nála nagyobb kulcsot és akkor nincs, kulcshiba. Ez az a pillanat, amikor a CPU ismát munkát kap, de eddigre már a tárban van a keresett rekord vagy megvan a hibajelzés, hogy nincs olyan. Ha a file blokkolt, akkor megkeresei az elsõ olyan blokk-kulcsot, ami a kértnél nagyobb és behozza a hozzá tartozó blokkot, ebben kell lennie a keresett rekordnak. Itt indul újra a CPU, mert a szétblokkolás már az õ dolga.
Az "odafelé" kommunikáció a CPU és a csatorna között a CAW (channel address word, a csatornaprogram kezdõcíme) és a készülékcím által törtönik, visszafelé pedig a megszakított állapothoz tartozó "régi-PSW"-ben lévõ készülékcím és a CSW (channel status word) hozza az információt a mûvelet eredményérõl.
A csatornaprogram fix hosszúságú, 8 byte-os csatornaparancsokból áll és ezek között ugyanúgy van feltételes ugró utasítás, mint a "gépi" utasításkészletben.
Egy tipikus lemezes olvasó csatornaprogram úgy néz ki, hogy pozicionál - rekordot keres - ugrik vissza ha nincs meg - beolvas.
Ha a file több készóléken helyezkedik el, akkor van még egy Master Index Table, amelyik megmondja az adott rekordhoz tartozó készülékcímet.
Ha a nucleus keresné meg a tárban lévõ indextábla alapján a rekord helyét, akkor ez egyrészt értékes feldolgozókapacitást fogyasztana, másrészt a tárméret határt szabna az indextábla (pontosabban az éppen tárban tartózkodó összes program által együttesen használható indexterület) méretének. Így viszont, ha van például egy olyan rendszer, ahol van 16 ALU és mondjuk 48 lemezelérésre alkalmas csatorna, akkor ez azt jelenti, hogy 16 CPU-igénylõ dolgozhat valós idõben párhuzamosan 48 lemezes kereséssel. Ha tehát egy programnak 8-10 file-ból kell kulcs szerinti adat, ammor elindítja a kéréseket, majd átadja az ALU-t másnak és várakozó állapotba kerül. Ha minden adata bejött, akkor átminõsül "futásra kész"státusúvá és a prioritásának megfelelõen egyszer majd elindul valamelyik ALU-n (nem szükségszerûen ugyanazon, mint ahonnal leállt)
Asszem ezt most nem egészen értem; tegyük fel, hogy a felhasználói program szeretné megkapni a 'NEVEMTEVE' kulcsú rekordot; bizalommal és SVC-vel fordul a rendszermaghoz, aki (a remlélhetőleg memóriában lévő) indexadatok alapján megállapítja, hogy ez a rekord a file melyik blokkjában lehet, azután pedig azt, hogy az melyik lemez melyik blokkjának felel meg. A munka hátralévő, szinte triviális részét a CPU az IO-processzorra bízza: olvasd be az X lemez Y..Y+3 blokkjait a fizikai memória Z címére, és küldjél egy megszakítást ha készen vagy.
A Symmetrix is meg mondhatni minden SAN célra fejlesztett lemez már tetszőleges formátumot emulál kifelé, mégpedig interface-enként akár eltérőt is. Hogy bent meg mi van, az nem látszik (olcsó vincsik tömege RAID6-ban...). De ha CKD-t emuláltatsz vele, akkor mennek a csatorna általi keresések, ha meg FBA-t, akkor nem. Bizonyos munkaállomás-szám felett már nagyon nem mindegy.
Azért valahogy túlléptek a dolgon.. V10-től minden megy a szabványos (ahogy ők mondják NON-KEY) lemezeken is... ha jól tudom, manapság az EMC Symmetrix lemezei a szokványosak BS2000-es környezetben
Ez egy teljesen standard lemezformátum, az összes mainframe rendszer ezt használja ma is. Nálunk is pörög belőle vagy 40 TByte :-))) A Siemensnél az volt a baj, hogy eltértek a CKD szabványtól is.
Aha. Ilyen non-standard lemezformátumok nálunk is (Siemens BS2000) voltak: minden 2048 byte-os adatblokk előtt volt egy 16-bytes segédterület, az úgynevezett PAM-key, amelynek egy része felhasználható volt... csupán mindent kellett átszervezni, mikor a Siemensnél rájöttek, hogy a szabványos lemezekkel is együtt kell működni...
Ja, és még egy lényeges dolog: az egy sávon lévő rekordok természetesen eltérő hosszúságúak lehetnek illetve egy rekord lehet hosszabb, mint egy sáv, de nem lehet hosszabb, mint egy cilinder. Vannak tehát többsávos író-olvasó- kereső utasítások.
No, amit leírtál, az a szektorszervezésű lemez. A CKD lemezeknél a sávok eredendően üresek, csak a poziciobálási cím ellenőrzésérére szolgáló HA (Home Address) rekord és a sávon még rendelkezésre álló hely nagyságát mutató R0 rekord van rajtuk. Minden felírt adatrekord három részből áll: Count, Key és Data. A Count fixen 8 byte hosszú, tartalmazza a CCHHR formában a record saját fizikai címét ahol CC a cilindercím, HH a fej sorszáma, R pedig a rekord sorszáma a sávon. Utána egy byte a rekord kulcsának a hossza, ami lehet 0 - 255 byte, négy byte pedig a rekord adatrészének a hossza. Ha mind a kulcs, mind az adatrész hossza nulla, akkor az egy EOF (file vége) rekord. Egy sávra a sávkapacitás függvényében számos rekord kerülhet, de minél kisebb a rekordhossz, a járulékos szervízinformációk miatt annál rosszabb lesz a sávkihasználás. Az egyes rekordokat "Alpha-gap"-ek választják el, a sáv végén pedig a maradék kitölt(het)etlen helyre egy "Beta-gap" íródik.
A csatorna és a lemezvezérlő "saját hatáskörben", a CPU használata nélkül képes "pozicionálni", kiválasztani a megfelelő cilinder megfelelő sávján a megfelelő sorszámú rekordot, beállni elé vagy mögé (folytatáshoz), illetve képes keresni kulcsra (kisebb, egyenlő, nagyobb). Amíg a csatorna keres, addig a CPU szabad, más program(ok) futhat(nak). Ha megvan a keresett rekord, vagy a csatorna úgy találta, hogy az nincs a kért helyen, akkor I/O megszakítás történik, a futó program PSW-je eltárolódik a x'38'-as címre, benne a megszakítást okozó készülék címével és a x'78'-as címről betöltődik a megszakítás feldolgozásához szükséges új PSW. Az ezzel elinduló SV rutin kiértékeli a csatorna válaszát, majd indítja az I/O műveletet eredetileg kérő felfüggesztett programot.
El tudnád egy kicsit magyarázni, hogy mik azok a szektor-szervezésű lemezek? Az én ismereteim szerint a lemezeket fix méretű blokkok sorozatának érdemes elképzelni (mondjuk 512, 1024, 2048, 4096 byte-os blokkmérettel)
A gyanúd alapos. Az index-szekvenciális filekezelés alapvetően a cilinder-szervezésű CKD lemezekre lett kitalálva, ezért szektor-szervezés esetén nem is tud működni. Ezt jópáran megszívták már akkor is, mikor az IBM a 9370-es sorozathoz elkezdte árulni az olcsó FBA (szektorszervezésű) lemezeket. Ott egy jó és kis többletmunkával járó menekülési út volt a VSAM-KSDS, de mivel a midrange és a PC-világban nincs VSAM sem, itt már komolyan meg kell dolgozni a sikerért. Amiket egyszerűbb "adatbáziskezelőket" forgalmaznak, azok jobbára gyenge KSDS-utánérzések, de az eltérő lemezszervezés miatt a hatékonyságuk alatta marad a VSAM-nak vagy az ISAM-nak.
Berkeley DB: tud párhuzamos karbantartást, a soros feldolgozás is működik, ha a DB_BTREE típust használjuk, továbbá tudunk parciális-kulcsos olvasást végezni a DB_SET_RANGE opcióval.
Gyenge pontja, hogy a felhasználásával készült programnak Open Source-nak kell lennie, vagy pedig fizetni kell a licencért.
http://www.gnu.org/software/gdbm/gdbm.html: Sajnos a párhuzamos karbantartás (magyar szóval SHARE-UPDATE) nem működik... (Mármint ezt nem mint hibát említem, benne van a manual-ban is)
