Jutranji program - TEZAURUS

Zapis v izdelavi !

Delam, delam kot zamorc ! 

Kontrolni program – TEZAURUS

Projekt TEZAURUS, njegovo logiko, organizacijo podatkov za računalniški sistem IBM, izdelavo vitalnih delov za pristop do banke podatkov in ne nazadnje tudi same programske kode, je v SDK podružnici Ljubljana začela trojka:

Matjaž ČADEŽ iz IBM Intertrade Ljubljana,

Wolfgang JUNG iz IBM ROECE Dunaj in

Mladen TROBEC iz SDK podružnice Ljubljana.

Prvi kontrolni program AROPS, izdelan v SDKJ, Beograd, je poleg osnovne naloge kontrole vseh podatkov, ki sodelujejo v obdelavi plačilnega prometa, imel še naslednje značilnosti, ki so se pokazale kot glavna ovira pri njegovem delovanju:

• uporabljal je zaporedne (SAM) datoteke,
• velika redundanca podatkov v več datotekah,
• vse popravke napačnih podatkov je bilo treba predhodno sortirati in uveljaviti v več datotekah,
• hitrost obdelave in kontrole je v idealnih razmerah bila do nekaj 1.000 transakcij na uro in v primeru prekinitve proti koncu dneva, se je ponovna kontrola zavlekla pozno v nočne ure,
• ročno klasiranje dokumentov se nikoli ni ujemalo z računalniškim sortiranjem in izpisi,
• praktično nemogoče dodajanje novih funkcionalnosti ali izboljšav,
• vsak dan zamudna priprava datotek za dnevno obdelavo.

Posledica počasnosti delovanja programov je bila, da je morala podružnica Ljubljana za pravočasni zaključek (do začetka novega dneva) dnevne obdelave nalogov plačilnega prometa dnevno najemati še dodatne računalniške kapacitete pri Ljubljanski banki.

Skupaj z zunanjima sodelavcema iz IBM Intertrade Ljubljana in IBM ROECE Dunaj, so delavci SDK podružnice Ljubljana ob jasni in odločni podpori vodstva podružnice sprejeli odločitev, da je treba narediti nov kontrolni program tako, da bo

• sodobno organiziran in
• hitrost ter prilagodljivost podrejena SDK delovnemu procesu.

Sodobno organiziran

Glavne značilnost so bile naslednje:

Pristop do podatkov – datotek

V tistem času je IBM operacijski sistem podpiral naslednje datoteke in njihove pristopne metode

SAM – Sequential Access Method (sekvenčne ali zaporedne pristopne metode) za vse serijske datoteke in vhodno-izhodne enote (hardware) npr. čitalec (bralnik) kartic, magnetni trak, tiskalnik in tudi diske, ko se je do njih pristopalo sekvencialno. Osnovni rutini za tak pristop sta GET (čitaj) in PUT (piši).

DAM - Direct Access Method je način pristopa in obdelave in ne način organizacije. Podatki so zapisani na diskih. Uporabniški program je moral poskrbeti za ustrezen ključ pri direktnem čitanju. Osnovni rutini za tak pristop sta READ (čitaj) in WRITE (piši), kar pomeni, da je bila možno zaporedno kakor direktno obdelovati podatke.

ISAM – Index Sequential Access Method je način zapisa in obdelave podatkov. Operacijski sistem je na osnovi uporabnikovih informacij zgradil datoteko s podatki in ločeno ključe za pristop do teh podatkov. Osnovni rutini za direktni pristop sta READ in WRITE, za zaporedni pa GET in PUT.

Primerjava hitrosti direktnega pristopa do podatkov med DAM in ISAM je v korist DAM, saj je DAM potreboval le dva premika bralno-pisalnih glav po disku, ISAM pa tri premike, kar je v praksi pomenilo vsaj 30 % hitrejši direktni pristop do naključnih podatkov po disku. Zaradi počasnosti diskov v tistem času pa je to lahko predstavljalo zamudo dnevnih obdelav za nekaj ur.

VSAM – Virtual Storage Access Method je način pristopa do podatkov na diskih na zaporeden ali direkten način. Poleg vseh značilnosti zgoraj opisanih vrst pa ima boljši učinek, integriteto in varnost, izboljšano organizacijo in enostavno uporabo. Edina »slaba« lastnost je večja poraba glavnega računalnikovega spomina. Prav zaradi zahtev po spominu se VSAM metoda do prve zamenjave in nadgradnje glavne procesne enote v letu 1980 ni razširjeno uporabljala v SDK.

Spodaj je ilustrirana struktura centralnega spomina računalnika IBM 370/138 s 96 KB v DOS operacijskem sistemu:

 


Čeprav so se bile relacijske banke podatkov (Relational Database) definirane že leta 1970 v IBM laboratorijih (San Jose Research Laboratory) in pozneje leta 1980 z objavo upravljavskega sistema RDBMS (Relational Database Management System) in SQL (Structured Query Language) pravili, se je njihova uporaba v SDK začela po letu 1985, bolj v testne kot resne produkcijske namene. Relacijske baze podatkov so namreč zahtevale bistveno hitrejšo računalniško opremo, ki je bila v zgodnjih 70-tih letih še mnogo predraga, da bi jo lahko opravičili za obdelavo plačilnega prometa.

Programski jezik

Na razpolago in izbiro sta bila dva programska jezika

• assembler in
• PL/I.

Začelo se je z assembler jezikom (Assembly Language) zaradi omejenih velikosti spomina, enostavnim pisanjem makro ukazov, z možnostjo neposrednega poseganja v operacijski sistem z namenom boljšega izkoriščanja splošnih rutin in ne nazadnje zaradi dejstva, da je to bil programski jezik za katerega so bili izšolani vsi organizatorji in programerji v SDK z IBM računalniškimi sistemi. Odločitev v katerem programskem jeziku napisati novi kontrolni program TEZAURUS je bila enostavna.

PL/I in pozneje PLIOPT se je uporabljal za programiranje različnih izpisov in obdelav, predvsem za sektor analiz in statistiko.

V zgodnjih 70-tih letih so bili računalniki še zelo počasni, spominsko zelo siromašni, cenovno pa zelo dragi. Zato je bilo zelo pomembno, da smo izbrali tak jezik, ki je omogočal čim boljšo izkoriščenost računalniških kapacitet, čim manjšo porabo centralnega spomina in čim hitrejše izvajanje. Programski jezik assembler pa je ob dobrih in iznajdljivih programerjih omogočal zelo veliko propustno moč in učinkovito obdelavo.

IBM operacijski sistem DOS/VS

Pri izdelavi kontrolnega programa TEZAURUS in seveda tudi pri nekaterih drugih se je optimalno izkoristilo vse kar je omogočal operacijski sistem.

OVERLAY tehnika omogoča, da je le en del programa stalno v glavnem spominu. Ta del programa se imenuje ROOT (koren, jedro, osnova) in je v spominu do konca ali EOJ (End Of Job) izvajanja programa. ROOT program je v bistvu le nekak "dispečer", ki polni v spomin določene dele programa, imenovane OVERLAY, ki nato opravijo določeno nalogo. Ko posamezni OVERLAY opravi svojo nalogo, se kontrola vrne v ROOT.

CIL = Core Image Library in vsebuje izvršljive programe (EXEC)



Razlog uporabe overlay tehnike je bil zelo enostaven: če bi ves kontrolni program TEZAURUS napisali kot en enovit program, bi nekajkrat presegli celoten glavni spomin v računalniku IBM 370 model 138! Ne gre prezreti tudi nekaterih funkcij, ki so uporabljale le nekajkrat na dan npr. O=DT (prepis vseh podatkov z diskov na magnetni trak) ali pa obratno O=TD (prepis vseh podatkov z magnetnih trakov na diske), ki se je uporabljala zelo redko, obe pa sta imeli zelo velika vhodno – izhodna področja za datoteke.


Vedno ko se je kontrolni program TEZAURUS začel izvajati in je kontrolo dobil ROOT, je preveril status predhodnega izvajanja. Stanje je lahko bilo

• normalno (predhodni zaključek po vseh pravilih) ali
• nenormalno (izpad električnega napajanja, okvara računalnika itd.)

V normalnem stanju je takoj dobil kontrolo KONZOLNI SERVIS, to je komunikacija z operaterjem s sporočilom »hh.mm.ss  O=« (trenuten čas) in operater je vpisal kaj naj program naredi.

V nenormalnem stanju pa se je izvajanje in nadaljnja kontrola takoj prenesla na tisti OVERLAY, ki je bil aktiven v času prekinitve. Po odpravljeni napaki je bila kontrola vrnjena KONZOLNEMU SERVISU.

Kontrolni program TEZAURUS je normalno zaključeval svoje delo na dva načina:

• O=EJ – (End Of Job) vse kontrole so ugotovile, da je material čist in
• O=ST – (Stop) kadarkoli, brez kontrol kakor pri O=EJ.

Sestavni del ROOT programa je tudi posebno COMMON področje. Tu so bili podatki, ki so bili skupni za overlaye in preko tega področja so različni overlayi programsko komunicirali med seboj.

Banka podatkov –Data Base

Plačilni promet v TEZAURUS konceptu banke podatkov je imel tri glavne in več pomožnih datotek.

Glavne informacije so bile v

• REGISTER ali RUDS (Register Uporabnikov Družbenih Sredstev) s podatki o uporabniku, bankah, sedežih SDK, občinah, dejavnostih in druge posebnosti, ki so bile pomembne za SDK,
• MATIČNA datoteka s finančnimi podatki,
• PROMETNA datoteka z vsemi dnevnimi transakcijami.

Vse tri datoteke so bile med seboj in znotraj posamezne datoteke povezane s POINTER-ji (kazalci), ter je tako bilo možno na hiter način dobiti različne informacije s pomočjo poljubnih parametrov. REGISTER je bil organiziran kot ISAM, MATIČNA in PROMETNA pa na TEZAURUS direktni način (DAM). S tem načinom smo dosegli najhitrejši možni način obdelave podatkov direktno, zaporedno (sekvenčno) ali verižno (po pointerjih). Vse datoteke nimajo praznih mest, vsi podatki so stisnjeni, posledično ni potreb po velikih zunanjih spominskih enotah – diskih in hitrost pristopa je večja.

Banka podatkov ni le skupek nekih informacij v posameznih datotekah, temveč tudi vse možne metode, način in rutine za pristop do teh informacij.

Pomožne datoteke v TEZAURUS konceptu banke podatkov se uporabljajo za delovanje kontrolnega programa. Te datoteke vsebujejo informacije, ki so potrebne pri ponovnem startu programa, za vmesnik med različnimi vhodnimi mediji in kontrolnim programom, za datoteko popravkov s pomočjo CICS transakcijskega programa. Vse te datoteke imajo DAM organizacijo, pa tudi zaporedna obdelava je predvidena.

Vse datoteke glavne in pomožne, morajo biti med delom TEZAURUS programskega paketa ON-LINE na računalniškem sistemu, saj so medsebojno povezane in status posamezne datoteke je bil običajno v prvih slogih glavnih datotek. Vsaka sprememba kjerkoli mimo kontrolnega programa TEZAURUS je lahko imela nepredvidljive in katastrofalne učinke.

Moduli za pristop do BP

Zaradi posebnosti shranjevanja informacij v banki podatkov je bilo treba brezpogojno ločiti logiko posameznih programov (overlayev) od pristopov do slogov v banki podatkov. Tak način programiranje je omogočil tudi morebitne spremembe v organizaciji datotek brez sprememb programske kode v programih.

Programer in program sta neodvisna od organizacije datotek in ga ne zanima ali je DAM, ISAM, blokirana, stisnjena in podobno. Poznati mora le modul in njegovo uporabo, kar se je doseglo z uporabo makro inštrukcij.

V TEZAURUS banki podatkov so vse datoteke DAM organizirane (le REGISTER je ISAM) in se celo zaporedno čitanje izvaja direktno. Tak način ima več prednosti:

• vedno se uporablja le en način, kar pomeni, da IOCS (Input Output Control System, ki je del IBM operacijskega sistema) uporablja le en pristopni modul IJIFZZHZ za vse DAM datoteke,
• za obdelavo začasnih datotek z relativno majhnim številom slogov odpadeta OPEN in CLOSE rutini, ki sta časovno zelo potratni,
• imamo možnost najhitrejšega pristopa na vse načine - zaporedno, direktno ali po kazalcih,
• imamo možnost poljubno mešanega čitanja in/ali pisanja v datoteko.

Pristopne metode v kontrolnem programu TEZAURUS lahko razdelimo v dve skupini

• pristop do posameznega sloga v banki podatkov in
• pristop do skupine slogov v banki podatkov.

Za dostop do posameznega sloga kot parameter za ustrezen pristopni modul vpišemo številko sloga ali ključ (račun-namen-partija).

Za skupinski pristop pa lahko uporabimo tri različne načine:

• zaporedni način po vrsti redu vpisa na disk (fizično zaporedje),
• verižni način, kjer dobimo logični vrstni red,
• indeks sekvenčni pristop do podatkov MATIČNE datoteke s pomočjo stalne tabele v spominu (več o tem v poglavju »Tabela matičnih podatkov v spominu«.).

Hitrost teh pristopov temelji na preračunu npr. številke sloga v obliko CCC-HH-RR (cilinder-head-record), ki določa fizični zapis sloga na disku. Čeprav je z DAM organizacijo baze podatkov bila prepustna moč zadovoljiva, so avtorji stremeli za stalnimi izboljšavami kontrolnega programa.

Izziv za izboljšavo je podal eden od SDK kontrolorjev, ki je na vprašanje, ali je sedaj postala SDK sodobno računalniško opremljena hiša, rekel: »Vse je super, le včasih smo pri ročni obdelavi imeli tudi po vsaki transakciji novo stanje. Danes pa čakamo na stanje do konca dneva in če pride uporabnik v negativno stanje, moramo izločiti iz obdelave zadnje transakcije«.

Ko je bilo vpeljano ažuriranje stanja po vsaki transakciji, se je obdelava spet zaradi počasnosti dostopov do diskov zelo upočasnila. Začelo se je z raziskavami, če bi lahko imeli v centralnem spominu tabelo najpomembnejših uporabnikov in ažurirali tabelo stanj v spominu, ki bi jih na časovne periode ažurirali v bloku. Ideja je bila, da se razvije lastno rešitev za virtualni (hierarhični) spomin, ki se je šele v naslednjih letih pojavil kot del sistemov za baze podatkov.

Hierarhični spomin

Hierarhični spomin je sestavljen iz več nivojev shranjevanja podatkov na enotah z različno hitrimi pristopi. Zaradi relativno počasnih diskov in posledično premajhne hitrosti pri čitanju-pisanju, je bilo treba del zunanjega spomina s podatki prenesti v glavni spomin računalnika. Ali drugače, glavni spomin CPU obravnavati kot zunanji, saj je pristop do podatkov v spominu bistveno hitrejši.

Za ugotavljanje, ali tako skromne spominske kapacitete zadostujejo za vpeljavo hierarhičnega spomina za Matično datoteko, je bil v letu 1974 napisan program, ki je po končani dnevni obdelavi obdelal vse transakcije in izdelal naslednje poročilo:

• koliko različnih računov (sedež-račun-namen-partija) je bilo obdelano v enem dnevu in
• koliko transakcij v breme in dobro je imel vsak tak račun v enem dnevu.

Po mesecu dni zbiranja teh podatkov se je pokazalo, da je približno 3 % vseh komitentov imelo 90 % vseh nalogov in delež povečanega števila dokumentov je bil večji kot delež komitentov.

Zbrani podatki so olajšali odločitev za uporabo te tehnike za pristop do MATIČNE datoteke. Pravilo, ki določa, kateri uporabnik bo v danem trenutku v tabeli in glavnem spominu je bil dinamičen, saj je kontrolni program TEZAURUS vodil evidenco, koliko transakcij je uporabnik že opravil. Slogi uporabnikov z največ transakcijami so ostali v spominu in so izpodrivali manj pogoste (frekvenčne). Vse skupaj je bilo učinkovito in podrejeno zgolj trenutnim podatkom v obdelavi. Ko je bil prvič pognan program z novo rešitvijo, je bil uspeh popoln: prepustna moč se je povečala za faktor 10!

Poleg prednosti v hitrosti pa je ta način zelo ranljiv pri nepričakovanem nedelovanju računalniškega sistema. Podatki v glavnem spominu, to je »tabela uporabnik v spominu«, je izgubljena. Za preprečitev takšne izgube se je v naprej določenih časovnih intervalih ta tabela zapisovala na disk. Še več, da bi preprečili izgubo podatkov v času prepisovanja tabele na disk, se je uporabil način FLIP-FLOP. Na ta način je bila v največji meri preprečena izguba podatkov, saj je bilo treba v primeru ponovnega starta ponoviti le zelo majhen del kontrole med intervalom zapisovanja na disk. Celoten postopek je bil v kontrolnem programu TEZAURUS imenovan kot »Tezaurus paging«, je bil popolnoma neodvisen in ni potreboval nobene človeške intervencije.

Organizacija pristopnih metod

V kontrolnem programu TEZAURUS so bile zaradi različnih razlogov narejene tri vrste pristopnih metod:

• pristopne metode za kontrolni program TEZAURUS,
• pristopne metode za neodvisne programe in
• pristopne metode s pomočjo MAKRO inštrukcij.

Iz gornje slike je razviden več nivojski pristop in ustrezajo različnim funkcijam pristopnih načinov.

Najnižji nivo (1. nivo) so programi IBM operacijskega sistema, običajno IOCS moduli, kjer se za pristop do TEZAURUS organizacije datotek uporablja le en, skupen modul IJIFZZHZ.

Naslednji nivo (2. nivo) v hierarhiji je modul DAMZZZZZ, izdelan v SDK, ki je podobno kot IBM IOCS le en za vse datoteke v bazi podatkov. Druge pomožne datoteke niso prikazane na sliki. Kako naj deluje DAMZZZZZ se določi s pomočjo DAFCB (Direct Access File Control Block) za vsako datoteko posebej. Delovanje tega modula je neodvisen od tipa diska, ki so se uporabljali v SDK.

IBM IOCS moduli, DAMZZZZZ in IJIFZZHZ so standardni za vse datoteke. Njihova funkcija je, da lahko direktno pristopijo do vsakega fizično zapisanega sloga na disku in so neodvisni od logičnih podatkov.

Naslednji višji nivo (3. nivo) se deli na module, ki so ozko vezani na podatke v posameznih datotekah, to je, da mora imeti vsaka svoj modul za pristop. Ti moduli predajajo ustrezne zahteve DAMZZZZZ in IBM IOCS. Ko dobijo podatke jih ustrezno prilagodijo (razširijo, ustrezno premaknejo polja ipd.) standardnim slogom ustrezne datoteke. V vsaki datoteki je več vrst slogov, zato je izredno pomembno, da vrnejo ustrezne podatke.

Moduli v 3. skupini so hkrati tudi pomožni moduli za skupinske operacije, ki jih zahtevajo najvišji moduli (4. nivo). Za skupinske operacije je bilo narejenih več pristopnih modulov:

• modul za zaporedni pristop do PCF dela prometne datoteke
• modul za pristop slogom prometne datoteke preko številke traku in logične celote,
• modul za zaporedni pristop do slogov matične datoteke,
• modul za verižno povezovanje posameznega uporabnika s slogi v prometni datoteki.

Na spodnji sliki je prikazana pristopna metoda za pomožne datoteke v banki podatkov plačilnega prometa. Do teh datotek se pristopa neposredno z DAMZZZZZ makroja, saj se večinoma obdeluje na fizično zaporedni način.

Pristop do pomožnih datotek

Za programerje je pri izdelavi programov najučinkovitejši pristop do podatkov z uporabo makro ukazov. Na spodnji sliki so izdelani in verificirani vsi črno obrobljeni, zeleni so v zaključni fazi verificiranja, rdeča obroba pa je »super makro« in čaka na začetek programiranja. Z načrtovanim »super makro DAJ« bi programer določil le logično zahtevo za določenimi informacijami, ne da bi vedel katere datoteke vsebuje te informacije in ne kako bodo pristopni moduli prišli do teh podatkov. Produktivnost programerjev bi se povečala in zmanjšale napake pri kodiranju, organizatorji pa bi dobili orodje za pridobivanje vseh mogočih informacij iz banke podatkov. Z uporabo ON-LINE pripomočkov CICS in VTAM, bi bili podatki dostopni v realnem času lokalno v podružnici, kjer je nameščen računalniški sistem in oddaljeno v poslovalnicah in ekspoziturah.

Makro ukazi

 Organizacija datotek v BP 

 

Podatki oziroma transakcije v SDK plačilnem prometu se stalno povečujejo. Težave pri organizaciji ročne in računalniške obdelave rastejo hitreje kot se povečuje število dokumentov, to pa zahteva posebno skrbno načrtovanje organiziranja podatkov in s tem povezanih informacij.

Povečano število informacij zmanjšuje hitro posredovanje le-teh. Treba je narediti združevanje podatkov in odpraviti redundanco. Prav tako ne smemo misliti le na eno aplikacijo, za katero so te informacijo najpomembnejše. Jutri se lahko pojavi nova aplikacija, zato je že danes pomembno, da so podatki v datotekah razporejeni na način, ki omogočajo vsakemu uporabniku ali aplikaciji najboljši pristop do zbranih informacij v datotekah. Ob hitri rasti podatkov moramo razmišljati tudi o omejitvah pristopnega časa in prostora na sami strojni opremi. Zgolj direktni pristop do podatkov organiziranih kot DAM ima omejitve v blokiranju slogov. Zato je bilo razvito posebno TEZAURUS DAMZZZZZ organiziranje podatkov, ki omogoča hiter dostop do posameznega ali skupine slogov. Vse to je bilo dodatno pospešeno z že opisanim »hierarhičnim spominom«. Zaradi zagotavljanja hitrega in uspešnega pregleda nad informacijami v datotekah, je bila narejena reorganizacija datotek v duhu logično istih vrst podatkov. Prav tako je vsaka datoteka dobila posebne »ničelne« sloge, ki opisujejo stanje datoteke.

Prometna datoteka

Prometna datoteka vsebuje vse dnevne transakcije v plačilnem prometu. Velikost se je dnevno menjala (od 0 do nekaj 100.000 slogov), zato je bila za obdelavo plačilnega prometa izrednega pomena hitrost pristopa do poljubne transakcije.

Datoteka PROMET je bila organizirana na TEZAURUS DAM način. Slogi dolžine 64 bajtov so bili blokirani v bloke po 3.520 bajtov, kar pomeni, da je v enem bloku bilo 55 slogov. Na IBM diskih tipa 2314 sta bila na stezo zapisana dva bloka, na IBM diskih tipa 3330 pa po trije bloki. Sami bloki so bili razmeroma veliki in je zato bilo zaporedno čitanje zelo kratkotrajno. Datoteka je bilo logično razdeljena na tri dele;

• ničelni slog,
• PCF (Program Control File) slogi,
• prometni slogi – zapisi.

Prometna datoteka

 Ničelni slog

Vsa polja – podatki prikazujejo stanje datoteke v danem trenutku in delno tudi stanje samega kontrolnega programa TEZAURUS. Spodnja slika je izvleček iz dokumentacije in prikazuje posamezne podatke in njihov pomen za lažje razumevanje.

Ničelni slog v datoteki PROMET

SLOG0        DS     0CL64      NIČELNI SLOG
ZADSLOG      DS     PL4        ZADNJI OBDELANI SLOG
BRDAT        DS     PL3        DATUM
BRKOP        DS     CL1        ZA KOPIRANJE
BRSTR        DS     PL3        ŠTEVILKA STRANI
MAXTR        DS     PL2        MAX. ŠTEVILKA TRAKU
BRGOT        DS     PL3        MAX. ŠTEVILKA OČIŠČENEGA TRAKU
BRČAS        DS     F          ČAS ZADNJEGA OBDELANEGA TR
BREJT        DS     F          ČAS KONCA KONTROLE
BROPT        DS     F          ČAS ZAČETKA KONTROLE
BRSTAT       DS     CL1        ZNAK ZA STATISTIKO
SL0PCF       DS     PL2        ŠT. TRAKU NA QUEUE-U
BRUKL        DS     CL1        ZNAK VKLJUČITVE
SL0CSS       DS     PL3        ZA ON-LINE CICS POPRAVKE
SL0CSL       DS     PL3        ZA ON-LINE CICS POPRAVKE
NIČAVIZA     DS     CL1        ŠTEVILKA PRESEKA
SL0S1S       DS     PL4        ŠTEVILKA
SL0S1L       DS     PL4        ŠT. ZADNJEGA OBDELANEGA V S/1 PROMETNI
             ORG    SLOG0+64   ZASEDENIH 64 BAJTOV

Ničelni slog je prvi zapis v PROMETNI datoteki. Videz sloga na disku je enak videzu sloga v spominu.

ZADSLOG vsebuje številko zadnjega zapisa v PROMETNI datoteki in ima lahko največjo vrednost 9.999.999. To je tudi teoretična največja možna količina transakcij v enem dnevu, v praksi se je v največjih podružnicah dnevno obdelalo nekaj 100.000 dokumentov in ob špicah do 50 % več.

BRDAT je datum obdelave in se uporablja v celotnem TEZAURUS projektu. Oblika zapisa je dd/mm/l (dan mesec leto). Vrednost vpiše operater, ko pri prvem dnevnem startu kontrolnega programa TEZAURUS s funkcijo BR (Brisanje) vpiše datum.

BRKOP vsebuje znak za varnostno kopijo banke podatkov TEZAURUS. »N« pomeni, da varnostna kopija ni narejena, »K« pa da je varnostna kopija ali backup že bila narejena.

BRSTR vsebuje številko strani na izpisanih kontrolnih listah. Uporablja se pri ročnem arhiviranju kontrolnih list, predvsem za reševanje reklamacij.

MAXTR je številka največjega traku – plastične ovojnice z dokumenti, ki je v danem trenutku že bila obdelana. Podatek služi pri zaporednem čitanju PCF slogov, ki se pri vrednosti v polju MAXTR zaključi.

BRGOT je trenutno število vseh čistih, to je brez napak, trakov v PROMETNI datoteki.

BRČAS je do 1/300 sekunde natančen čas zadnjega obdelanega traku. Podatek se uporablja pri dnevni statistiki obdelave in se zapiše takoj po končani obdelavi vsakega traku.

BREJT je čas dnevnega zaključka obdelave kontrolnega programa TEZAURUS. Podatek se zapiše, ko operater vpiše zaključni ukaz EJ.

BROPT je čas, ko se je kontrolni program TEZAURUS začel izvajati prvič v tistem dnevu.

BRSTAT je namenjen programom, ki obdelajo datoteko PROMET za izdelavo raznih poročil (koliko transakcij, koliko trakov, koliko napak, čas začetka in konca, število vnašalk podatkov in koliko nalogov so vnesle itd.).

SL0PCF je številka traku, ki je v trenutni obdelavi. Ta podatek predstavlja stanje kontrolnega programa TEZAURUS. Če je vrednost 0 (ničla) pomeni, da kontrolni program ne ažurira nobenih finančnih podatkov in v primeru nenormalne prekinitve ni nobenih posledic za obdelavo podatkov plačilnega prometa. V primeru, da SL0PCF vsebuje vrednost različno od 0, pa to pomeni, da je kontrolni program v stanju kontrole in ažuriranja datotek. V primeru nenormalne prekinitve, se ob ponovnem startu samodejno izvedejo vse aktivnosti potrebne za nemoteno nadaljevanje.

BRUKL je podatek o vključitvi sredstev komitentov posamezne poslovne banke v njeno stanje.

SL0CSS in SL0CSL sta podatka, ki ju uporabljata CICS on-line program za vnos popravkov in kontrolni program TEZAURUS za njihovo obdelavo.

PCF slogi

PCF (Program Control File) so drugi logični segment v datoteki PROMET (prvi logični segment predstavlja »ničelni slog«). Skupaj jih je 999, vsak dolžine 64 bajtov, enake dolžine kot »ničelni slog« ali kot vsak posamezen slog podatkov.

PCF slogi vsebujejo vse podatke o posameznem traku. Fizični položaj, kje v datoteki in na disku posamezni PCF je, je tudi podatek o posamezni številki traku. To pa pomeni, da npr. podatek, da gre za PCF in trak številka 123 ni nikjer zapisan v nobeni datoteki. Številke PCF slogov in tako tudi trakov, so vnaprej razdeljene v posamezne logično zaključene skupine.

Vrsta posla »00«, to je vhodna kontrola podatkov, uporablja številke med »1« in »799«, razen številke »501«, ki je rezervirana za vključitev sredstev poslovnih bank in »502«, ki jo uporablja »jutranji program«. JUTRANJI program vzdržuje vse nefinančne podatke v vseh datotekah, v primeru pa, da se neki račun uporabnika zapre in njegova finančna sredstva prenesejo k drugemu uporabniku, kreira ustrezne podatke v obliki, ki jih nato obdela kontrolni program TEZAURUS.

Popravki podatkov imajo lahko vrsto posla »99«, »55« ali »66« in številke trakov od »1« do »99«. V primeru teh treh vrst posla, kontrolni program TEZAURUS vpiše te trakove kot PCF podatke med »801« in »899«.

PCF slog

Posamezna polja opisujejo pripadajočo skupino (trak) posameznih transakcij.

PCFOD se vpiše po začetku kontrole tega traku in pomeni prvi vpisani nalog v datoteki PROMET.

PCFDO se vpiše po zaključeni kontroli tega traku in pomeni zadnji vpisani nalog v datoteki PROMET.

MAXLC vsebuje največjo številko logične celote v tem traku.

PCFNA je število napak tega traku ugotovljenih pri njegovi prvi kontroli. To so le formalne napake kot napačen račun, napačna kontrolna številka pri partiji itd. Napake zaradi finančnih podatkov se ne vpisujejo, saj so le-te lahko posledica več napačnih vpisanih zneskov v eni logični celoti (ničelna kontrola).

Sledi nekaj podatkov za samo statistiko obdelave in nimajo nobenega vpliva na končno bilanco. To so polja PCFLUK (šifra operaterja na vnosu), PCFSTR (šifra stroja za vnos), PCFČAS (predstavlja dva časa: čas obdelave traku in čas, ko je bil trak brez napak).

PCFKLS in PCFMEŠ sta podatka o ročnem klasiranju in le v primeru, da se v SDK podružnici uporablja TEZAURUS način klasiranja dokumentov plačilnega prometa. 

Prometni slogi – transakcije

Prometni slogi ali transakcije so tretji logični segment v datoteki PROMET. Tu so zapisani vsi nalogi posameznih uporabnikov, ki tisti dan sodelujejo v plačilnem prometu. Vsak slog dobi svojo zaporedno številko v času vhodne kontrole in jo obdrži med vsemi postopki obdelave. Podobno kot velja za NIČELNI in PCF slog, tudi prometni slog nima nikjer v datoteki zapisane svoje številke. Položaj vsakega sloga pomeni tudi njegovo številko. Prvi prometni slog ima številko 1, ki pa ima dejansko številko 1.001. Pred njim je 999 PCF slogov in pred njimi še NIČELNI slog, ki je v datoteki prvi. Drugi prometni slog dobi številko 2 in položaj na disku 1.002 in tako dalje.

Vse to številčenje je interno, programsko narejeno tako, da vsi ljudje vidijo in upravljajo s številko 1 kot dokument 1 ali s številko 54.321 kot dokument 54.321.

Do vsakega prometnega sloga se lahko pristopa

• direktno na osnovi njegove številke,
• zaporedno na osnovi številke traku v okviru katere se nahaja ali
• verižno, če je znana njegova identifikacija račun-namen-partija.

Sama datoteka PROMET je logično razdeljena na dele, kjer vsak predstavlja papirnati trak. Do prometnih slogov papirnatega traku se pride tako, da se najprej izvede čitanje odgovarjajočega PCF sloga, kjer je zapisan podatek o prvem slogu tega traku in kje je njegov konec. Slogi so med seboj povezani s kazalci (pointerji) v okviru logičnih celot in jih tako ni mogoče brati v vrstnem redu, kot so bili vpisani v datoteko. Pri zaporednem čitanju vsega prometa s pomočjo pristopnih metod, se ne berejo slogi od številke 1 naprej, temveč najprej slogi, ki pripadajo papirnemu traku številka 1, sledijo slogi papirnega traku številka 2 itd.

Prometni slogi so v datoteki vpisani v stisnjeni (komprimirani) obliki. Ustrezno raztegovanje opravijo rutine v modulih za pristop ter tako uporabniški programi vedno uporabljajo normalno, nekomprimirano obliko podatkov.

Vsak prometni slog ima tri dele:

• minus slog z vodilnega dokumenta vsake logične celote,
• plus slog z vsakega sloga transakcije in
• opisnega dela. 

Prometni slog vsakega dokumenta

Vsak prometni slog vsebuje podatke vodilnega ali prvega dokumenta v logični celoti, delno tudi iz konsignacije za posamezno logično celoto ter vse podatke iz posameznega naloga. Vodilni slog tako ni samostojen zapis v datoteki PROMET ter zato tudi nima svoje številke sloga za identifikacijo. Vodilni slog lahko identificiramo, če poznamo številko traku in logične celote. Taka organizacija omogoča, da na podlagi enega samega plus sloga dobimo tudi vse ostale podatke, kar je velika prednost pri verižnem čitanju slogov določenega uporabnika. Videz in vsebina podatkov »Datica minus« in »Datica plus« je identična vsebini originalnih podatkov na luknjanem papirnatem traku, to je dva bloka po 10 znakov in 1 blok po 11 znakov (to je znesek, ki pa je konvertiran v 6 pakiranih znakov, za plus in minus posebej). Kaj točno pomenijo posamezna polja je odvisno od »vira informacij«, ki je vedno v minus delu na prvem mestu v dolžini dveh znakov. To informacijo uporabi pristopna metoda za ustrezno vsebinsko porazdelitev ostalih podatkov.

Opisni del vsakega sloga pa so podatki, dobljeni iz drugih datotek:

• oznaka poslovne banke,
• oznaka za ekspozituro ali poslovalnico,
• razne aktivnosti ločeno za minus in plus del,
• oznake za napake ločeno za minus in plus del,
• številka logične celote, ki ji pripada ta slog,
• številka papirnatega traku za ta slog,
• kazalec (pointer) na naslednji slog v logični celoti,
• kazalec za naslednji slog istega uporabnika, ki je v minus delu.

Matična datoteka

Matična datoteka vsebuje finančne podatke za vsak odprti račun v določeni SDK podružnici. Poleg tega pa je to edina datoteka, ki služi za kontrolo pravilnosti vsakega ključa, to je uporabnika ali komitenta, v obdelavi plačilnega prometa. Kontrolni program TEZAURUS vsako identifikacijo (račun-namen-partija) vhodnih nalogov kontrolira oziroma primerja z MATIČNO datoteko. Kontrola z matično datoteko pa zahteva hiter in učinkovit direkten pristop. Po uspešnem zaključku kontrolnega programa pa je MATIČNA datoteka vir podatkov za izdelavo GLAVNE KNJIGE, IZPISKOV, DNEVNIKOV BANK in še niz drugih izpisov, vse s pristopom na zaporedni način.

Hiter direktni in hiter zaporedni pristop omogočata TEZAURUS DAM način. Posamezni slog v matični datoteki je dolg 110 bajtov, ki so združeni po 32 skupaj v blok dolžine 3.520 bajtov. Dolžina bloka MATIČNE in PROMET je enaka in zato za obe datoteki veljajo ista pravila.

Ključ za pristop MATIČNE datoteke je račun-namen-partija in ne more biti številka sloga kot v PROMETNI datoteki, to pa je zahtevalo posebno pristopno metodo. Naslednji problem je bil, da na čim manjšem prostoru na disku shranimo vse potrebne informacije. Navedeni ključ ima to pomanjkljivost, da ima teoretično velik razpon od 100-000-0000001 do 999-999-9999999, kjer je ogromno praznih in neuporabljenih ključev. Tem pogojem bi zadostila ISAM organizacija datoteke, ki pa ima počasne pristope za direktno in zaporedno obdelavo.

Poseben pristop za MATIČNO datoteko je bil organiziran s pomočjo tabele, ki je stalno v glavnem spominu in kjer dobimo direkten naslov bloka na disku, kjer so zahtevani podatki. Vse skupaj pa je bilo pogojeno, da takšna tabela v spominu ni prevelika.

Tabela v spominu vsebuje za vsak blok na disku njegov največji ključ. Tabela ima toliko elementov koliko blokov ima MATIČNA datoteka. Pri direktnem adresiranju je potreben tudi podatek o številki bloka, ki pa ga dobimo iz položaja ustreznega elementa v tabeli. Če bi upoštevali zgoraj navedeni razpon ključev MATIČNE datoteke, skupaj 13 številk (3 za račun, 3 za namen ali občino in 7 za partijo), bi dobili ogromno tabelo, ki bi presegala velikost celotnega računalnikovega spomina. S posebnim matematičnim algoritmom so bila upoštevana tri dejstva, ki opredeljujejo SDK ključ:

• število računov ni večje od 256, trenutno jih je 140,
• število namenov ali občin ni večje od 128,
• individualna partija ima na prvem mestu vedno ničlo, zadnja številka je kontrolna številka izračunana po SDK modulu 11, torej je možnih oznak za račun le 99.999. Pri izračunu kontrolne številke po SDK modulu 11 je nekaj redkih izjem, ki nimajo bistvenega vpliva na celoten algoritem.

Ko vsa ta dejstva pretvorimo v binarno obliko, dobimo stanje, da za podatek o RAČUNU potrebuje 8 bitov, za NAMEN-OBČINO 7 bitov in za PARTIJO 17 bitov. Skupaj 32 bitov ali točno 4 bajte.

Programsko je to rešeno tako, da na osnovi vseh RAČUNOV najprej zgradimo običajno tabelo, kjer je vsak element dolg 3 bajte, kar bi za maksimalno 256 računov po 3 bajte skupaj pomenilo 768 bajtov, nato pa za vsak RAČUN njegov položaj pretvorimo v binarno obliko ter dobimo za 140 SDK računov tabelo v skupni velikosti 140 bajtov oziroma za vsak osnovni SDK račun 1 bajt ali 8 bitov.

Podobno velja tudi za NAMEN ali OBČINO z razliko, da je tabela za maximalno 128 podatkov po pretvorbi velika le 48 bajtov. oziroma za vsak podatek le 7 bitov.

PARTIJO se pretvori v binarno obliko tako, da se odreže prvo in zadnje mesto. V primeru izjem, ko partija nima kontrolne številke, se enostavno pretvori cela partija. Ustrezen podatek o izjemah je zapisan v datoteki REGISTER.

Primer (rdeče označeni minus je le za vizualno predstavo):

Decimalno:          533-000-0123456
Binarno:               00000111-0000000-00011000000111001
Hexadecimalno:    07003039

Decimalno:         601-000-0001009
Binarno:              00001010-0000000-00000000001100100
Hexadecimalno:   0A000064

Decimalno:         720-003-0001009
Binarno:              00010000-0000011-00000000001100100
Hexadecimalno:   10030064


S pretvorbo ali kompresijo ključa s 13 na 4 mesta je bilo dosežena velikost tabele indeksov – pointerjev za MATIČNO datoteko 3.520 bajtov. Stisnjeni ključ je bil znan kot »binarni ključ MATIČNE datoteke«.

MATIČNA datoteka je bila razdeljena na naslednja logična področja:

Tabela INDEKSOV je lahko zasedla do 10 blokov. Vsak blok velikosti 3.520 bajtov je lahko vseboval 28.000 zapisov uporabnikov družbenih sredstev, teoretično 280.000, ki pa jih ni bilo v vseh SDK skupaj v celi Jugoslaviji! Položaj v bloku in v katerem bloku je zahtevani binarni ključ, sta skupaj določala fizični zapis v MATIČNI datoteki na disku. Neizkoriščeni del bloka ali preostalih blokov je bil zapolnjen s podatkom X'FF' ali binarno '11111111'.

NIČELNI slog v MATIČNI datoteki se je nahajal v zadnjih 110 bajtih zadnjega, to je 10 bloka. Zapisane informacije so bistvene za hierarhični spomin in pristop do podatkov uporabnikov družbenih sredstev in njihovih finančnih sredstvih.

Slogi 099 opisujejo in vsebujejo finančne podatke o transakcijah z drugimi SDK sedeži. Ključi so »umetno« narejeni v smislu »račun-namen-partija« in se nahajajo tudi v datoteki REGISTER na enak način kot običajni uporabniki družbenih sredstev. Podatek o NAMENU pa določa naslednje:

• 000 – prejeta zbirna aviza v breme in dobro
• 001 – poslana zbirna aviza v dobro
• 002 – poslana zbirna aviza v breme
• 003 – poslani teleks nalogi v dobro in breme
• 004 – prejeti teleks nalogi v dobro in breme

Podatek »partija« pa je operativna oznaka za SDK (10100 = Sarajevo, 50100 = Ljubljana, 51400 = Koper, 40100 = Zagreb, 60800 = Beograd itd.)

Komitenti SDK ali uporabniki družbenih sredstev v domačem sedežu SDK pa je zadnja in največja skupina slogov v MATIČNI datoteki. Identifikacija ali ključ je »račun-namen/občina-partija« in je zapisan v vsakem slogu. Podatki na disku so stisnjeni in se z ustrezno pristopno metodo raztegnejo v spomin. Vsak slog je logično razdeljen v več skupin

• identifikacija uporabnika,
• opis uporabnikovih podatkov,
• finančni podatki,
• kazalci – pointerji do drugih datotek.

Kontrolni program TEZAURUS je vzdrževal in ažuriral vse finančne podatke in kazalce do drugih datotek. JUTRANJI program je vzdrževal in ažuriral vse podatke o uporabniku v datoteki REGISTER in dodajal nove uporabnike v vse ustrezne datoteke. JUTRANJI program se je običajno izvajal po končani dnevni obdelavi ter je bila tako banka podatkov TEZAURUS pripravljena za naslednjo dnevno obdelavo. Vsaka sprememba, ki bi jo naredil JUTRANJI program med delom kontrolnega programa TEZAURUS, bi lahko bila usodna. V JUTRANJI program so bile vgrajene varovalke, ki so preprečile take nedovoljene primere. JUTRANJI program se je sicer med delom kontrolnega programa TEZAURUS lahko izvajal, kontroliral vse podatke, simuliral vsa ažuriranja, izpisal ustrezne protokole, le dejanskega ažuriranja ni izvedel. Takšno delovanje je omogočilo že med dopoldanskim delovnim časom vseh služb v SDK, da so popravili in pripravili brezhibne podatke za poznejše (večerno) ažuriranje TEZAURUS banke podatkov.

Poleg treh glavni datotek REGISTER, MATIČNE in PROMETNE, je bilo v TEZAURUS banki podatkov še niz pomožnih datotek namenjene varni, hitri in fleksibilni obdelavi plačilnega prometa. Najbolj značilne so bile

KPRTIN, KPRTOUT – datoteke na magnetnih trakovih, kjer so reševali (backup) vsi podatki banke podatkov
QUEUE – datoteka standardnega formata za ves vhodni material kontrolnemu programu TEZAURUS
MATQU – flip-flop datoteka za reševanje »Hierarhičnega spomina« MATIČNE datoteke v spominu na disk
CICSQU – datoteka podatkov s popravki, ki jih je zapisal on-line podsistem CICS in obdelal kontrolni program TEZAURUS

Vse pomožne datoteke (razen magnetnih trakov) so bile organiziranje na TEZAURUS DAM način in pristop je bil možen na direktni in zaporedni način.