torek, 13. julij 2010

Zakaj TEZAURUS?


Okoli leta 1970 so zvezni organi Jugoslavije v sodelovanju z republikami in SDK sprejeli odločitev, da se mora poslovanje SDK izboljšati, po potrebi spremeniti in tehnično posodobiti. Vse te izboljšave naj bodo narejene tako, da naj

  • uporabniki družbenih sredstev imajo čim manj dela
  • spremembe naj bodo minimalne in le nujno potrebne
  • sedanja tehnična oprema se posodobi z računalniki.

Imenovane so bile delovne skupine, ki so delale posnetke stanja, vse skupaj več ali manj kopirale, minimalno spreminjale, ustvarjale podatkovne zbirke, pisale zahtevke kaj in kako naj delajo programi itd.

Edina večja sprememba je bila nova določitev individualne partije za vse uporabnike. Dosedanji način označevanja uporabnikov je bil SDK-RAČUN-NAMEN-PARTIJA in sicer tako, da se je v okviru vsakega RAČUNA številčenje začelo z 1 (ena). RAČUN 601 (gospodarstvo) se je začel z 1, 603 (negospodarstvo) se je začel z 1, 678 (hišni sveti) se je tudi začel z 1 itd. Napačno vpisan podatek 603 namesto 601 je nakazal sredstva napačnemu uporabniku. Tudi nobene kontrolne številke npr. po »MODULU 11« ni bilo. Nova določitev individualne partije je

  • v okviru SDK računov 60x, 61x, 62x, 67x, itd. se individualna partija ne sme ponoviti
  • partiji se doda kontrolna številka po »modulu 11«.

V SDK Sloveniji je bil narejen še dodaten zahtevek, saj se je številčenje začelo s 1000+K (+K je bila kontrolna številka) in tako je preprost pogled na »partijo« razkril vsaj ustrezno dolžino, to je najmanj 5 številk.

Vse drugo v organizacijskih in programerskih rešitvah ter izvedbah je bila več ali manj preslikava starega ročnega dela v plačilnem prometu!

Poleg osnovne naloge kontrole vseh podatkov, ki sodelujejo v obdelavi plačilnega prometa, je prvi »kontrolni program« imel še naslednje značilnosti, ki so se pokazale kot glavna ovira pri njegovem delovanju:

  • uporabljal je zaporedne (SAM) datoteke, ki niso omogočale direktnega pristopa do poljubnega zapisa
  • vzdrževal je 3 datoteke in sicer 
  1. prometna – vsi nalogi v okviru matične podružnice, 
  2. aviza – vsi nalogi za druge SDK podružnice in 
  3. skontra – potrditve vseh nalogov od drugih podružnic, ki so jim bili poslani preko datoteke aviza
  • vse popravke napačnih podatkov je bilo treba predhodno sortirati
  • vse popravke napačnih podatkov je bilo treba uveljaviti v vsaj dveh datotekah
  • hitrost obdelave in kontrola je v idealnih razmerah bila do nekaj 1.000 dokumentov na uro in v primeru prekinitve proti koncu dneva, se je ponovna kontrola zavlekla pozno v nočne ure
  • vsak dan je bilo treba datoteki promet in aviza kreirati s praznimi podatki

Kontrolni program TEZAURUS je odpravil vse pomanjkljivosti:

  • uporabljal je datoteke z direktnim pristopom (DAM)
  • uporabljal je le eno datoteko za vse naloge. Zaradi združljivosti s prvotnim projektom AROPS in za obdelavo po končani vhodni kontroli, je bil narejen program »ena-tri«, ki je naredil ustrezne datoteke. Sčasoma so bili popravljeni oziroma na novo napisani programi za dnevno obdelavo, ki so črpali podatke neposredno iz »DAM prometne datoteke«
  • hitrost obdelave in kontrole je dosegla nekaj 10.000 dokumentov na uro. Ko je okoli leta 1980 SDK Ljubljana dobila novi, zmogljivejši računalnik IBM 4341 je bila z dobro razporeditvi podatkov po diskih dosežena hitrost do 80.000 nalogov na uro
  • logična organizacija »DAM prometne datoteke« je vsebovala tako imenovani »ničelni« stavek z vsemi podatki za vsakokratni obdelovalni dan, osnovne zapise ali »pcf stavke« za vsak paket podatkov in običajne zapise vsakega dokumenta
  • vsakodnevno kreiranje prometne datoteke je bilo le brisanje ničelnega in pcf stavkov, vsega skupaj 1.000 zapisov ali potreben čas nekaj sekund
  • narejene so bile rutine in predpisani postopki za pristop do podatkov, ki so bili pozneje uporabljeni pri pisanju novih programov
  • kontrolni program Tezaurus je bil napisan na »overlay« način, ki je omogočil izvajanje velikega programa, več kot 150.000 bajtov, v glavnem spominu računalnika na particiji z vsega 25.000 bajtov
  • odpadlo je nepotrebno sortiranje popravkov napačnih podatkov
  • direktni pristop je omogočil uporabo CICS  (Customer Information Control System), IBM paketa za programiranje in uporabo aplikacij preko ekranskega terminala.

Navedenih je le nekaj značilnosti in razlik. Pozneje med uporabo je bilo dodanih še kup funkcij, ki so bistveno posodobile plačilni promet.


Več in bolj natančno o »Kontrolnem programu – Tezaurus« pa v zapisu  tukaj.



.

Ni komentarjev:

Objavite komentar