Paging – saldo žiro računa

 

Kako približati delovanje Službe družbenega knjigovodstva pravnim osebam? Ali delavci službe naredimo dovolj za izboljšavo svojega »servisa«? Ali smo navsezadnje dovolj odprti do zunanje ideje za nudenje kaj več kot le stanje salda na izpisku? Odgovor je »DA« in pričujoči zapis opisuje idejo in rešitev le ene izmed možnih smeri razvoja dodatnih uslug in servisov zainteresiranim pravnim osebami.

 

Ideja se je porodila iz stiske, morda celo iz obupa ob jutranjem vrtenju telefonske številčnice. Ali so bile zasedene PTT linije ali pa je bil zaseden interni kontrolor na šalterju in najvažnejšega podatka tj. stanja - salda žiro računa se dovolj zgodaj enostavno ni dalo dobiti. Pa še kurir je zaradi varčevanja prvo pot na SDK opravil ob 11. uri in končno, kateri »financar« v podjetju pa sploh lahko uspešno deluje brez informacije koliko ima denarja na razpolago! Čudovito, celo idealno bi bilo, če bi ob prihodu na delo podatek o stanju na žiro računu že čakal na pisalni mizi. In zakaj ne? Ideja, kako do podatka o novem saldu, je prišla kar sama ob uporabi sistema »PAGING — OSEBNI KLIC«.

 

»Paging - osebni klic« predstavlja le eno izmed možnih funkcij RDS sistema (Radio Data System - Prenos podatkov po radiju), ki ga je zasnovala in predpisala EBU (European Broadcasting Union - Zveza evropskih radiofuznih organizacij) že v letu 1984. Leta 1990 je bil sprejet kot standard v večini evropskih držav in pri tem sprejemu je aktivno sodelovala tudi Jugoslavija. Gre za javni servis, prvi te vrste v Sloveniji ih v Jugoslaviji, ki predstavlja brezžični prenos sporočil. Sporočilo se odda preko telefonskega omrežja, oseba ali osebe, katerim je to sporočilo namenjeno, pa ga sprejmejo s pomočjo ustreznega osebnega sprejemnika - pagerja.

 

Prenos podatkov se izvede preko obstoječih UKV oddajnikov in pretvornikov RTV Slovenije na frekvenci 57 kHz s hitrostjo 1200 bps. Tako je zagotovljena zadostna kapaciteta za prenos klicev, saj je območje, ki ga pokriva navedena frekvenca praktično enako področju, kjer je možen sprejem radijskega programa od 87,5 do 108 MHz UKV področja.

 

Republika Slovenija je tako skoraj v celoti pokrita s paging signalom. Zaradi geografske razgibanosti Slovenije obstajajo posamezne »bele lise« s slabšim signalom predvsem ozke doline. Sprejem je tudi slabši v globokih garažah, dvigalih, ob nezaščitenih aparatih, ki proizvajajo elektromagnetne motnje ipd. V primeru, da se oseba s sprejemnikom nahaja v takem območju z nezanesljivim sprejemom, sprejemnik sam z zvočnim signalom opozori uporabnika, da je na tem mestu sprejem slab ali da celo sprejem ni možen.

 

Sprejem paging signala omogoča ti. Pager, poseben sprejemnik velikosti približno 105 x58X21 mm, teže 160g, ki ga napaja ena baterija 1,5V, velikosti AA (R6). kar zadošča za približno 200 ur delovanja.

 

 

Sprejemnik dela na UKV FM področju 87,5 - 108 MHz in na frekvenci na kateri je sprejem RDS RP (Radio Paging) signal najboljši. To pomeni, da pager sam poišče najmočnejši signal. Zaradi varčevanja z električno energijo se sprejemnik - pager samodejno vklaplja in izklaplja. Čas vklopa je določen s samim delovanjem celotnega sistema, sprejemnik se avtomatično sinhronizira z oddajnikom in tako ni možno, da bi v času izklopa preslišal njemu namenjeno sporočilo.

 

In kako deluje celoten sistem? Vsak sprejemnik - pager ima svojo 6-mestno identifikacijsko številko, podobno kakor telefonski naročnik. Prav tako je vsak sprejemnik izdelan in programiran tako, da sprejema samo svoja sporočila tj. le tista, ki so opremljena z njegovo identifikacijsko številko.

 

Stanje telefonske strukture v Republiki Sloveniji omogoča, da PTT Slovenije zagotavlja dva načina sporočanja sporočil: avtomatsko in ročno. Pri avtomatskem klicu je na voljo posebna omrežna skupina »0610«, pri ročnem pa se pokliče številko »917« ter preda sporočilo operaterju. Vzemimo, da želimo poslati sporočilo lastniku sprejemnika s identifikacijsko številko »987654«, preko telefonskega aparata »064-12345«. To naj bo tudi sporočilo lastniku sprejemnika - pagerja, seveda po predhodnem dogovoru, katero naj čimprej pokliče.

 

Postopek avtomatskega sporočanja je naslednji: odtipkamo (odvrtimo) naslednje zaporedje številk: »061098765412345«, Takoj sledi avtomatično preverjanje tj. ponovno klicanje telefonske številke s katere smo zahtevali oddajo sporočila: ker je telefonska številka zasedena, pomeni da je vse v redu, sicer se pa takšen poziv zavrne. Naletimo pa na omejitev, ker če kličemo z internega telefona naročniške centrale z npr. 10 vhodnimi naročniškimi številkami, kontrola ni možna, saj pri povratnem klicanju ni zagotovila, da bo izbrana prav naša klicna številka. Preko avtomatskega telefonskega odzivnika dobimo sporočilo »Klicali ste paging službo, sporočilo sprejeto, hvala« in čez približno 1 minuto nas sprejemnik s število »987654« z zvočnim signalom opozori in izpiše sporočilo 9064 12345«. Običajni dogovor je, da sedaj lastnik pagarja telefonira na to številko.

 

Pri ročnem načinu preko operaterja na številki »917« praktično ni omejitev, saj je glede na vrsto sprejemnika možno oddati sporočilo dolžine do 80 alfanumeričnih znakov. Dodati pa velja, da je trenutno možno oddajati le do 18 številk.

 

Vse opisane prednosti in lastnosti »Paging — osebni klic« so se kot ideja in možnost uporabe porodile našemu nekdanjemu sodelavcu g. Janezu Žlendru, sedaj direktorju firme A-Ž Consulting d.o.o. Ljubljana, Miklošičeva 38, ki je ustanovljena tudi za »dnevno servisiranje gospodarskih subjektov z informacijami za dosego optimalne likvidnosti«. Vsaka uporabna ideja je v osnovi preprosta: zakaj ne bi uporabili RDS paging sistem še za sporočanje stanja - salda na žiro računu? Drugače povedano: ko SDK zaključi dnevno obdelavo plačilnega prometa, bi zainteresiranim pravnim osebam s pomočjo telekomunikacijskega prenosa podatkov posredoval njihovo stanje - saldo na žiro računu.

 

V marcu 1991 so bili opravljeni prvi pogovori. Podružnica Ljubljana je bila pri- pravljena posredovati podatke o stanju na ' žiro računu, SROP centrale v Ljubljani pa operativno izvajati in posredovati podatke do RTV Slovenije. Dogovorjeno je tudi bilo, da firma A-Ž Consulting zagotovi vse ustrezne programe, delavci SROP pa jih preizkusijo, dopolnijo ustrezna navodila za uporabo in poskrbijo za dnevno izvajanje ustrezne obdelave.

 

Projekt »Paging — saldo žiro računa« pri dnevni obdelavi plačilnega prometa v SDK podružnici z IBM strojno in programsko opremo poteka takole:

 

•        izvede se program PAGE2, ki po kontroli, če je kontrolni program za plačilni promet TEZAURUS že zaključil s funkcijo O=EJ, prepiše salde s tistih žiro računov, ki so vključeni v APS »Paging - saldo žiro računa« v posebno datoteko,
•     sledi prenos na PC,
•     komunikacijskim programom (npr. Kermit ali XTALK ali PROCOMM) na PC računalniku se podatki prenesejo na računalniško-oddajni sistem RTV Slovenije,
•     TV Slovenija preko svoje UKV radijske mreže odda podatke, ki so čez minuto prikažejo na ekranih ustreznih sprejemnikov-pagerjev.

Prva obdelava in spremembe pa se izvedejo takole:

 

 

•          Program PAGE1 čita in kontrolira vhodne podatke ter zapiše vse pravilne v posebno datoteko, vse nepravilne pa na tiskalnik,
•           sledi sortiranje zapisov v datoteki po ključu (račun, namen, partija.

 

Poudariti velja, da se program PAGE1 lahko časovno izvaja kadarkoli, dočim program PAGE2 le po končani kontroli vhodnih podatkov plačilnega prometa. To pa je v večernih urah, ko je tudi sicer promet na PTT in RTV manjši. Na ta način je za prenos podatkov o stanju na žiro računu na razpolago časovni interval od 20:00 do 06:00 ure. To pa zadošča za prenos vsaj 25.,000 sporočil o stanju na računu. Vsako sporočilo vsebuje naslednje podatke:

•           saldo - do 10 cifer,
•         partija — do 6 cifer in
•           oznaka negativnega stanja - 1 cifra.

 Kot primer vzemimo žiro račun 50100- 620-133 Ljubljanske banke v Ljubljani z negativnim saldom 1234567890. Na prvem ekranu dobimo podatek 1234567890, po pritisku na tipko MEM na sprejemniku, pa se nam na naslednjem ekranu prikaže 133 0 (0 je oznaka za minus stanje, če pa je stanje pozitivno, potem se pač nič ne izpiše).

 

Sam projekt »Paging - saldo žiro računa« je odprt in z ustrezno dopolnitvijo in razširitvijo odpira in nudi še dodatne možnosti. Obveščanje pravnih oseb o dnevnem prilivu sredstev po zaključenem prvem preseku okoli 10 ure dopoldne je možnost, ki se ponuja kar sama. Z uvedbo sprejemnikov, ki lahko na ekranu prikažejo do 80 alfanumeričnih podatkov dobimo možnost posredovanja podatkov iz podatkovne zbirke Register Imetnikov Računov itd.

 

Naj zaključim: prvi korak je narejen, tehnične možnosti so na razpolago in vsaka nova, uporabna ideja, ki nudi boljše in dodatne usluge pravnim osebam je dobrodošla.

  

 

Odmev: O računalniški opremljenosti - računalniškem znanju

Čeprav so nekatera mnenja v rubriki »Kaj o tem menite vi« v zadnjem času ostala brez potrebnih odgovorov oziroma pojasnil za objektivno ali celovitejše informiranje bralcev "Obvestil" (za to je zmanjkalo časa ali je prevladalo mnenje, da naše glasilo ni strokovna revija, v kateri bi pojasnjevali npr. cilje, metode in postopke oblik nadzora v teoriji in naši praksi), ne bo odveč pojasnilo oziroma mnenje o naslednjem problemu in težavi:

"Nesprejemljivo je, da ob spomladanskem kadrovanju delavcev za opravljanje ocene ZR in ekonomsko finančne revizije v pogojih avtomatske obdelave podatkov njihovo izobraževanje preprosto prestavljene v jesenski čas, in to ob tem, da je že danes skoraj nemogoče ročno kontrolirati računalniško obdelane informacije pri uporabnikih družbenih sredstev. Problem računalniške podpore za potrebe eksternega nadzora je treba rešiti takoj in upoštevati organizacijski in kadrovski vidik". 

Z osnovnimi metodami in postopki ocenjevanja zaključnih računov v pogojih računalniškega obravnavanja podatkov so se vsi delavci, ki opravljajo naloge ocenjevanja zaključnih računov, seznanili v drugem in delno tretjem letu izvajanja teh nalog. V drugem letu in začetku tretjega leta je SDK v SR Sloveniji imela možnost vključitve v izobraževanje specialistov za opravljanje ocene ZR in EFR na ravni SDK Jugoslavije 7 delavcev. SDK Jugoslavija je v obeh letih uspela zagotoviti usposabljanje dveh skupin delavcev z 20 do 25 delavci iz vseh republik in avtonomnih pokrajin. Pri evidentiranju udeležencev izobraževanja SDK Jugoslavija ni upoštevala, da se služba v Sloveniji srečuje z relativno višjo stopnjo računalniškega obravnavanja podatkov kot službe v drugih delih Jugoslavije. Zato smo jo zaprosili, da izobraževanje za specialiste opravi posebej za delavce iz naše republike.

Prošnji, da bi navedeno izobraževanje organizirali v zimsko-spomladanskem izobraževalnem terminu, SDK Jugoslavije ni mogla ustreči, saj ima za izvajanje teh nalog le 4-5 delavcev, ki poleg izobraževanja opravljajo po vsej državi še instrukcijske naloge ekonomsko-finančne revizije in druge naloge. Preostalo nam ni drugega, kot da počakamo na jesenski rok. Tako bo v času od 5. septembra do 8. oktobra 1988 15 delavcev ocene ZR in EFR naše službe pridobilo potrebna znanja (za uporabo programskega paketa SDK PAK), s katerimi bodo mogli začeti z opravljanjem nekaterih postopkov kontrolnega obdelovanja datotek podatkov, glede na cilje preveritve posameznih kategorij zaključnega računa.

Iz povedanega ni težko ugotoviti, da bi o nesprejemljivem prelaganju izobraževanja lahko govorili le takrat, ko bi v naši republiki imeli delavce, ki bi tako znanje imeli in ga znali posredovati naprej ali pa bi za to bila usposobljena kakšna druga izobraževalna institucija. Delavci SDK Jugoslavije so tovrstna znanja pridobili v tuji revizorski firmi. Služba v naši republiki sama oziroma neposredno z navedeno firmo ne sodeluje. SDK v Sloveniji za razvoj nadzorne funkcije nima službe ali skupine strokovnih delavcev, ki bi med drugim razvijal oziroma spremljal razvoj metod revidiranja in nadziranja v pogojih računalniškega obravnavanja podatkov v svetu. Z razvojem metod in postopkov revidiranja se v razvitem svetu ukvarjajo posebni inštituti pri revizorskih firmah. Potrebna znanja si lahko bodoči revizorji pridobe tudi na fakultetah. Na naših ekonomskih fakultetah za enkrat še nimamo posebne usmeritve, ki bi nudila poleg splošnih znanj s področja računovodstva, financ, informacijskih sistemov tudi potrebna dodatna znanja za poklic revizor (Centrala SDK je pobudo za organiziranje tovrstnega študija že posredovala pristojnim republiškim organom).

Smo torej v situaciji, ko poznamo potrebe po uspešnem, kvalitetnem in racionalnem opravljanju vseh oblik eksternega nadzora, ki jih zahteva računalniško obravnavanje podatkov uporabnikov družbenih sredstev, teoretično poznamo potrebne metode in postopke, potrebujemo pa dodatno, zlasti praktično usposabljanje. Ne glede na to, ali se z revidiranjem ukvarjajo zunanji revizorji in ga izvaja oddelek zunanje revizije iz SDK, ali se z njim ukvarjajo notranji revizorji in ga izvaja služba notranje revizije v poslovnem sistemu, zahteva obsežno poznavanje ne samo strokovnih problemov poslovanja, temveč tudi problemov dela z računalniki. Medtem ko je revidiranje pred dobo računalnikov bilo usmerjeno pretežno v verifikacijo računovodskih poročil, je revidiranje v dobi računalnikov usmerjeno tudi in najprej v verifikacijo računalniških programov in uporabniških računalniških rešitev nasploh, saj brez tega ni mogoče niti verificirati računovodskih poročil. Odpira se torej povsem novo področje dela revizijske službe (dr. Ivan Turk, Vloga in mesto revidiranja v sodobnih organizacijah, str. 22 v Zborniku Sodobne metode gradnje informacijskih sistemov z ekonomskega in organizacijskega vidika, Društvo ekonomistov Ljubljana, XXI. posvetovanje - Portorož, april 1988).

Ob tem pa moramo najbrž priznati, da je računalniška pismenost računovodskih delavcev v Sloveniji poprečno višja od zaposlenih v SDK, če o tej že sploh lahko govorimo. Delavci, ki opravljajo eksterni nadzor po inšpekcijski metodi v zadnjih petih letih niso imeli nobenega organiziranega izobraževanja s področja računalništva.

Menimo, da služba v Sloveniji, ki šteje približno 2900 delavcev, mora poskrbeti za razvoj svojih funkcij, kot mora to vsaka organizacija združenega dela in ne le slediti razvoju, ki ga vodi SDK Jugoslavije. Pri tem je potrebno tudi povedati, da razvoju SDK Jugoslavije pri nalogah ekonomsko-finančne revizije in ocene ZR kadrovsko in organizacijsko niti ne sledimo. Sektor, ki na ravni SDK Jugoslavije opravlja tovrstne naloge, ima za to strokovnjake, organizirane v posebnem oddelku. V centrali SDK v Sloveniji nimamo takega oddelka, nimamo delavcev, ki bi te naloge opravljali. Smo torej le del poprečja naše družbe, kjer dejanja ne slede besedam, da so nam danes bolj kot kdajkoli prej potrebna vlaganja v izobraževanje, v strokovnjake, v načrtovanje njihovega razvoja, v nagrajevanje, ki jih bo spodbujalo h kvalitetnejšemu delu. Posamezniki lahko v takem trenutku storijo v zadevnem primeru le to, da pozovejo najbližjo izobraževalno institucijo, npr. Izobraževalni center IBM Intertrade v Radovljici, k prilagoditvi nekaterih svojih izobraževalnih programov potrebam eksternega nadzora službe, jim pri tem pomagajo in čakajo na ponudbo. To smo storili in upamo, da bomo tako tudi letos šli korak naprej. Korak naprej v času, ko se v SDK čaka, da nam bodo pripravljavci gospodarske reforme dokazali, da kvalitetnega nadzora nad gospodarskimi subjekti, ki spoštujejo gospodarski račun, to je - revizijo, nismo sposobni razviti in bi zato ta morala v posebno institucijo.


September 1988

Eno leto po prehodu na popolni TK prenos podatkov

V aprilu 1994 je bil v podružnici Celje in v vseh petih ekspoziturah vpeljan popolni telekomunikacijski prenos podatkov.

Za pravno osebo je pomenil telekomunikacijski prenos podatkov spremembo, saj pri izpisku ni dobila več originalnih plačilnih nalogov, ampak računalniško izpisano zbirno sporočilo o obremenitvi in zbirno sporočilo o odobritvi z vsemi elementi iz originalnega plačilnega naloga. Iz teh podatkov je pravna oseba imela dovolj informacij za knjiženje.

Ob prehodu je bilo veliko težav, ker se nekateri udeleženci v plačilnem prometu niso pravočasno pripravili na spremembe. To se je odražalo v povečanem številu reklamacij. Zato smo skupno z oddelkoma interne kontrole in družbenega računovodstva na številnih sestankih opozarjali pravne osebe in banke na pravilno izpolnjevanje plačilnih nalogov, saj je to temeljni pogoj za pridobitev točne informacije o opravljenih plačilih.

Za uresničitev tega projekta je bilo v podružnici vloženih veliko naporov v usposabljanje delavcev, predvsem tistih iz odseka razvrščanja, razporejenih na delo pri vnosu podatkov.

Dvakrat večji zajem podatkov iz nalogov plačilnega prometa na osebnih računalnikih je zahteval večje posege v organizacijo dela v plačilnem prometu, kar je bilo možno operativno izvesti le z dobrim sodelovanjem vseh delavcev podružnice. Ob tej priliki bi se želela zahvaliti sodelavcem oddelka obdelave nalogov plačilnega prometa za njihovo sodelovanje in pripravljenost za delo v spremenjenih pogojih. Vsak delavec je s svojim delom prispeval k temu, da smo pri vnosu dodatno zaposlili samo tri delavce. Pri realizaciji končnega cilja pa smo imeli veliko podporo iz vodstva podružnice in strokovno pomoč delavcev SROP-a in Sektorja za plačilni promet Centrale.

Danes, po več kot letu dni, ugotavljamo, da vseh težav še nismo odpravili. Težave pri vnosu nam še vedno povzročajo položnice pošt in bank, ki so večkrat nečitljivo izpisano ali pa niso izpolnjene v predpisani standardizirani obliki. Tovrstno dokumentacijo bi od bank in pošt želeli prejemati na magnetnem mediju, to pa ni mogoče, ker večje banke in pošte pri pripravi programov niso samostojne. Rešitev vidimo v sodelovanju s Sektorjem za plačilni promet Centrale.

Druga težava je v tem, da delavci plačilnega prometa veliko časa porabimo za naknadno vizualno kontrolo sedežev in partij računov in podatkov pri dovoljenih modelih, ki niso pod kontrolo. Prav tako vidimo težavo pri prepletanj u enakih partij v okviru istega računa v različnih podružnicah, saj ima to za posledico slabo kvaliteto storitev komitentom. Nujno je izboljšati vnosne programe z večjo zaščito - kontrolo pravilnosti vnesenih podatkov in v to kontrolo manj vključevati človeški faktor.

Kako naprej

Po enoletni izkušnji ugotavljamo, da je sedanji način dela v pogojih popolnega telekomunikacijskega prenosa dobra osnova za realizacijo projekta modernizacije plačilnega prometa.

Vpeljava tega projekta je načrtovana v več fazah - programskih podsistemih. V naši podružnici in ekspoziturah se sedaj pripravljamo na uvedbo aplikacije programskega podsistema za vnos in zajem podatkov z nalogov plačilnega prometa. Osnova novemu programskemu podsistemu je uvedba tehnologije enotnega republiškega registra imetnikov računov v plačilni promet.

Aplikacijski programski podsistem za vnos in zajem podatkov bomo vpeljali postopno, saj moramo še pred tem počasnejšo računalniško opremo nadomestiti z zmogljivejšo, kar bo zagotovilo, da pravne osebe prehoda in s tem povezanih problemov ne bodo čutile, bo pa gotovo velik napor za vse delavce, ki delajo v plačilnem prometu.


Julij 1995

Povezava SDK računalnikov

September 1985

V marcu 1984 je generalni direktor SDKJ imenoval skupino sedmih delavcev SDK podružnice z IBM računalniško opremo in sicer iz Beograda, Novega Sada, Sarajeva, Skopje, Zagreba in Ljubljane.

Delovna skupina je imela nalogo, da

• izdela pregled trenutnega sistemskega programja, ki se uporablja na IBM računalnikih v SDK
• izdela predlog novega enotnega osnovnega sistemskega programja
• izdela predlog telekomunikacijskega programja za prenos podatkov
• izdela predlog nabave, centralne distribucije, generiranja in vzdrževanja vsega sistemskega programja in pripadajoče literature.

Vsak član delovne skupine je obdelal vse SDK podružnice svojega področja. Stanje trenutno delujočega sistemskega programja je porazno. Tako smo imeli v SR Sloveniji kar tri različne operacijske sisteme na vsega štirih IBM računalnikih. Najslabše se je odrezal SERC, ki še danes (julij 1985) uporablja operacijske programje DOS/VS R. 34 (Disk Operating Sistem/Virtual Storage Release 34), katerega tudi proizvajalec več ne vzdržuje. SDK podružnica Maribor je bila naslednja z DOS/VSE R. 1 (Disk Operating System/Virtual Storage Extended Release 1). Še kar sodobno, čeprav že približno dve leti zamenjan z novejšo verzijo, sta bili opremljeni SDK podružnici Celje in Kranj z DOS/VSE R. 2.

Analiza in primerjava IBM programske in strojne opreme SDK v SR Sloveniji z ostalimi SDK podružnicami v Jugoslaviji pokaže, da je na zadnjem mestu SDK podružnica Skopje, takoj pa ji sledi SERC. Ta situacija se je od marca l985 še spremenila na škodo SERC-a, saj je bil računalnik IBM 370/135 po uspešnih 13 letih obratovanja demontiran.

SERC vse obdelave za podružnice Ljubljana in centrale v SR Sloveniji opravlja na računalniku IBM 370/ 138, ki ima že kar častitljivo starost 7 let. Zmogljivosti računalnika v SERC-u so nezadostne za kakršnokoli resno razmišljanje o uvedbi TK povezave in prenosa podatkov. Vsa nadaljnja razmišljanja in delovanje v delovni skupini so slonela na predpostavki, da je nujno treba nabaviti zmogljivejši računalniški sistem. To je delno že uresničeno: CPU (centralna procesna enota) IBM 4341 s KB 8 in 4 KB spomina sta že v SERC-u, do avgusta 1985 pa pričakujemo še ostalo strojno opremo (diskovne in tračne enote), tiskalnike pa do konca leta 1985.

Tudi analiza zasedenosti zunanjih nosilcev podatkov tj. magnetnih diskov, je pokazala nič kaj rožnato situacijo. Zasedenost diskov v vseh treh podružnicah (Celje, Kranj, Maribor) je okoli 70 %, zasedenost CPU pa je v času obratovanja računalnikov do 45 %.

Ob navedenih številkah moramo upoštevati, da so magnetni diski IBM model 3310 v SDK podružnici Celje in Kranj emulirani, kar pomeni, da se logično obnašajo kakor starejši IBM model 2314. To pa je približno do 15 % slabša izkoriščenost celotne zmogljivosti posameznega diska in izguba do 250 KB realnega spomina CPU, kar praktično pomeni, da ima centralni procesor na razpolago le do 750 KB spomina. In zakaj takšna izguba spomina in diskov? Razlaga je enostavna, rešitev pa ne: večina APS (aplikacijskih programskih sistemov) v SDK je izdelanih tako, da za organizacijo in pristop uporabljajo preživelo ISAM (Index Sequential Access Method) metodo. Model diskov v SDK podružnici Celje in Kranj pa ISAM pristopne metode ne podpira. IBM ima rešitev v emulaciji diskov, SDK pa po drugi strani tudi ni kaj dosti naredila na področju APS, da bi se ISAM pristopna metoda zamenjala z VSAM (Virtual Storage Access Method) organizacijo podatkov, ki je neodvisna od modela diskovnih enot.

Problem zasedenosti diskov je SDK podružnica Kranj delno rešila tako, da je isto področje na disku uporabila za več različnih obdelav, ki si časovno sledijo v določenem obdobju. Ta uspešna rešitev je bila prenesena tudi v SDK podružnico Celje.

Trenutno stanje IBM opreme v SDK v SR Sloveniji nam tako ne omogoča TK povezavo in prenos podatkov.

Svet SDK je v juniju 1984 sprejel odlok, s katerim določa tehnološke in tehnične osnove za obdelavo podatkov z nalogov plačilnega prometa v pogojih telekomunikacijskega prenosa podatkov (Glasnik št. 6 z 22. 6. 1984). S tehnološkimi osnovami so predpisani vsi potrebni elementi nalogov plačilnega prometa, ki se bodo prenašali v TK. Tehnične osnove pa določajo vso potrebno strojno opremo za TK prenos podatkov. Obstoječa oprema se mora nujno dopolniti z komunikacijskimi procesorji, adapterji, moderni, spominom, terminali in drugim.

Med partnerji, ki oblikujejo SDK mrežo za TK prenos podatkov, so topologija mreže, vrsta komunikacijskih linij, strojna in programska oprema. Predvidena topologija SDK mreže razvršča organizacijske enote SDK v 4 nivoje: glavni vozel (I. nivo) omogoča komunikacijo med republikami in pokrajinama, tranzitni vozel (II. nivo) omogoča komunikacije v regiji in povezavo proti I. nivoju, aktivni vozel (III. nivo) predstavljajo posamezne podružnice SDK in pasivni vozel (IV. nivo) so ekspoziture in poslovalnice, ki so vezana na vozlišče III. nivoja in preko njega v celotno mrežo.

Glede na število, velikost in usmerjenost nalogov posameznih podružnic v republikah in pokrajinama, predstavljajo vse podružnice v te glavnih mestih tudi glavne vozle v mreži. Tranzitni vozli so predvideni v SR Srbiji, Hrvaški in BiH. Jasno je, da so tako glavni kakor tudi tranzitni vozli istočasno tudi aktivni vozli. Najnižji nivo tj. pasivni vozli so glede na oddaljenost od aktivnega vozla, možnost fizičnega prenosa dokumentov, obseg posla in možnostjo nakupa potrebne opreme itd. deli v dve osnovni skupini: do in nad 1500 obdelanih dokumentov dnevno. Trenutno so vse aktivnosti SDK usmerjene v povezavo od I. do III. nivoja in je po povezovanje aktivni-pasivni vozel odloženo ali pa prepuščeno v realizaciji posamezne podružnice.

Komunikacijske linije med glavnimi vozli bodo najete, saj le takšne zagotavljajo brezhiben prenos s hitrostjo 4800 bitov/sekundo. Vse ostale linije bodo komutirane z možnostjo hitrosti prenosa 2400 b/s.

Priznati je treba, da je SDK v SR Sloveniji z naročilom potrebne dodatne komunikacijske opreme zaostajala. Takrat, ko so v SDK v SR Hrvaški in v SAP Vojvodini že prihajali ustrezni komunikacijski kontrolorji, je SDK v SR Sloveniji šele naročila le-tega za SERC, za ostale tri podružnice z IBM opremo pa komunikacijske adapterje. Ta odločitev, da se za računalnike v podružnicah Celje, Kranj in Maribor kupi ICA (Integrated Communications Adapter) in ne komunikacijski procesor IBM 3705 (imenovan tudi FEP - Front End Proccessor), ni bila najbolj posrečena. Napaka je bila narejena pred leti ob nakupu računalniških sistemov za te tri slovenske podružnice, ko je v samih CPU 4331 že bila delno in nepopolno vgrajena ICA. Takrat se je sicer že govorilo, da mora SDK povezati računalnike med seboj, ni se pa kaj dosti vedelo kako in na kakšen način naj bo ta povezava izpeljana.

Komunikacijski procesor pri TK opravlja večino dela v mreži po nalogu CPU in ga tako razbremeni. ICA pa dela isto toda v okviru CPU in na račun obremenjenosti, zasedenosti in hitrosti CPU. Če primerjamo obremenjenost računalnika v podružnici Maribor, ki bo imel vgrajen ICA, in SDK podružnice Osijek, ki je že opremljena z komunikacijskim procesorjem 3705, potem je razlika na dlani. Očitno je, da računalnik v Osijeku še nekaj časa ne bo preobremenjen zaradi TK, medtem ko za Maribor to ne morem trditi. Res pa je tudi, da v SR Sloveniji priprava in vnos podatkov poteka s pomočjo S/1, ki pripravi podatke skoraj brez napake in zato CPU ni toliko obremenjen kakor v Osijeku, kjer se vhodni podatki zajemajo na strojih manjših zmogljivosti kakor S/l.

Težišče delovanja delovne skupine je bil izbor enotnega osnovnega operacijskega in TK programja. Pod besedo osnovnega sistemskega programja razumemo vse tisto, kar omogoča nemoteno delovanje računalnika. Nekaj dileme je bilo, ali SDK potrebuje VM/SP (Virtual Machine/System Product) ali ne. VM/SP je operacijski sistem, ki upravlja celoten računalniški sistem tako, da ima več uporabnikov na razpolago funkcionalno celoten računalniški sistem. Takšni funkcionalni celotni računalniški sistemi se seveda simulirajo kot navidezne mašine. Koncept navideznih mašin omogoča upravljanje z resursi računalniškega sistema tako, kakor da obstaja več računalniških sistemov, saj VM/SP omogoča vsaki navidezni mašini funkcije podobne funkcijam obstoječega (realnega) računalniškega sistema. Vsaka navidezna mašina je kontrolirana od lastnega operacijskega sistema, ki deluje pod kontrolo VM. izkušnje, ki jih ima SDK z VM, so omejene na podružnico Beograd, ki ima zastarelo verzijo in na podružnice Novi Sad, ki ima najnovejšo verzijo VM. Manjši problemi v podružnici Novi Sad so nastali takrat, ko so se izvajale obsežne in časovno daljše obdelave za SAP Vojvodino. Z razširitvijo CPU 4341 z 2 MB na 4 MB so ti problemi odpadli. Odločitev delovne skupine je, da je vsak računski center z najmanj 4 MB spomina CPU  primeren za uporabo VM operacijskega sistema. Kot gostujoči operacijski sistem v okviru VM je bil izbran DOS/VSE R. 3, ki ustreza tudi podružnicam z računalniki manjših zmogljivosti.

S takim izborom in opredelitvijo smo dosegli enoten operacijski sistem za vse IBM računalnike v SDK. To pa ni in ne sme biti razlog za počivanje, ker od julija 1985 dalje ni več možno kupiti DOS/VSE operacijski sistem. Nadaljevanje je DOS/SP (Disk Operating System/System Package), ki obsega vse najboljše svojega predhodnika in nudi še veliko več.

Kakor je bila odločitev o izboru operacijsko osnovnega sistema lahka, pa so se dileme in mnenja okoli TK sistema še kako kresala. Odločiti smo se morali med VM/RSCS (Virtual Machine/Remote Spool Communication Subsystem) in SNA (System Network Architecture).

VM/RSCS smo lahko praktično videli v ZERC Split. Njihovo mrežo je v marcu 1984 sestavlja] CPU 3031 s 3 MB spomina, FEP 3705 s 128 KB spomina in na več kakor 20 lokacijah po Splitu s 40 telefonskimi
linijami različna terminalska oprema (MDS, S/34, S/38 in S/l) skupaj s približno 100 aktivnimi terminali. Operacijsko programje je VM/SP z mrežno komponento RSCS, in DOS/VSE R. 3, DC (Data Communication) monitor CICS, za DB (Data Base) pa uporabljajo DL/I. Izkušnje delavcev ZERC-a lahko stremo, da je rešitev RSCS dobra za prenos podatkov v obliki kartice (80 znakov) ter kombinaciji s S/l kot FEP (to pa pogojuje S/l samo za TK z najmanj l MB spomina in ostalo nujno opremo) in da povezovanje več IBM računalnikov in računalnikov drugih proizvajalcev v mrežo najbolje omogoča SNA.

Druga možnost je SNA koncept za prenos podatkov. SNA predstavlja arhitekturo za KS (komunikacijske sisteme). Njen dizajn obsega vse dele KS. Rešitev v SNA je sistem, ki omogoča, da se ob minimalnih naporih instalira nove APS ter vzdržuje in širi konfiguracija mreže. Prav tako SN sistem ne obremenjuje uporabnike KS s funkcijami kontrole in upravljanjem mreže. SNA ni zgrajen za posamezne stroje ali programe, temveč je osnovan na določenih funkcijah. Dizajn SNA omogoča, da se te funkcije distribuirajo na najrazličnejše točke v KS. Funkcije, ki je prej izvrševal CPU glavnega računalnika, lahko sedaj izvršujejo tudi drugi sestavni deli KS. Te funkcije so

• upravljanje linij,
• kontrola posameznih naprav,
• formatiziranje podatkov in
• v določenih primerih tudi izvajanje programov.

Osnovne komponente SNA so nodes (vozli), ki predstavljajo fizično enoto ali napravo. Najvišje je Host Node (HN gostujoči vozel), ki ga predstavlja CPU s svojim operacijskim sistemom, pristopnimi metodami in bazo podatkov. Je odgovoren za izvajanje APS in upravlja komunikacijsko mrežo z izbrano pristopno metodo. Communication Controller Node (CUCN - vozel komunikacijske kontrolne enote npr. FEP 3705) je odgovoren za kontrolo mreže terminalov, lahko različnih lastnosti, ki so vezani na njega. Ta vozel imamo tudi za "služabnika" gostujočega vozla, ker izvršuje vse ukaze, ki mu jih pošlje CPU. Program, ki se izvaja v CUCN, je NCP (Network Control Program). Preko telefonskih linij je CUCN povezan z Cluster Controller Node (CCN), ki oddaljeni lokaciji omogoča pristop do podatkov centralnega računalnika. Ta vozel predstavlja enote, ki se lahko programirajo, so računalniki v malem (imajo CPU, diske, printer itd.). Lep primer za CCN je nam vsem dobro poznana šaltersko-terminalska oprema Ljubljanske banke - IBM 3600. Na koncu je v SNA konceptu tudi terminal node (TN - terminalski vozel). Z njegovo pomočjo, na katerega so priključeni terminali, končni uporabnik komunicira s centralnim računalnikom.

Resnični garač v SNA filozofiji je NCP, ki izvaja večino aktivnosti v mreži. V primeru računalniškega sistema brez FEP in NCP (podružnica Celje, Kranj in Maribor), vsak opravila NCP izvršuje VTAM. To pa je že omenjena dodatna obremenitev CPU.

Sestavni del povezave več računalnikov v mrežo je tudi MSNF (Multy System Network Facility). Ta programski paket omogoča povezavo in prenos med uporabniki, ki so povezani npr. z računalnikom v SERC in med uporabniki, ki so povezani z računalnikom v Sarajevu, oba računalnika med seboj pa preko računalnika v Beogradu.

Poleg navedenega ima SNA še niz programskih produktov, ki omogočajo lažje in enostavno delo operaterjem, hitro in učinkovito odkrivanje napak pri delovanju mreže in vključitev v mrežo tudi take strojne opreme, ki ne uporablja IBM SNA SDLC (Synchronous Data Link Control) protokol: BSC (Binary Synchronous Communications) ali S/S (Start/Stop) terminali npr. teleks.

Iskali smo dodatne informacije pri drugih računskih centrih. Problem je bil predvsem ta, da je zelo malo računskih centrov v Jugoslaviji povezanih med seboj v pravo mrežo tj. računalnik-računalnik. Omeniti velja, da je končni cilj SDK povezava 15 IBM, 23 NCR in 79 Burroughs računalnikov.

Končna odločitev za način povezave je bila SNA. Da bi to lahko argumentirano podprli in dokazali, smo izbrali poskusne podružnice Novi Sad, Osijek, Zagreb in Sarajevo. Namen poskusa je bil, da se vsi štirje IBM računalniki med seboj "pogovarjajo" tj. izmenjajo podatke in da na računalnik v SDK podružnici Sarajevo priključimo še računalnika NCR in Burroughs. Za načrtovani poskus smo predvideli dve obliki prenosa podatkov: stavke do1žine 80 znakov (oblika kartice) ali stavke dolžine 132 znakov (oblika tiskane vrstice) s pomočjo programskega paketa POWER v.2/RJE (Remote Job Entry) in poljubno dolžino stavka v poljubni datoteki s pomočjo FTP (File Transfer Program).

IBM računalniki so bili med seboj povezani v SNA arhitekturi tako, da je računalnik v Sarajevu prevzel vlogo »prvega med enakimi«, tj. trenutni nadzor nad vsemi dogajanji v mreži. SNA omogoča v vsakem trenutku dinamično spremembo »nadzornika mreže« ali celo več »nadzornikov«. Kakor rečeno je na računalnik v SDK Sarajevu bil priključen še NCR v centrali BIH in Burroughs iz SDKJ. NCR in Burroughs je IMB prepoznal kot oddaljene (remote) terminale tipa 3780 s pomočjo POWER/RJE. Med samim poskusom smo testirali tri različne poti izmenjave podatkov v obe smeri in sicer IBM-IBM, IBM-NCR in IBM-Burroughs. Zveze in povezave NCR-Burroughs nismo testirali, ker tehnološka rešitev in topologija mreže ne predvideva takih direktnih povezav. Vsekakor pa je prenos podatkov med NCR-Burroughs mogoč s pomočjo IBM računalnika kot posrednika. Med Osijekom in Sarajevom je bil aktiviran prenos podatkov z datoteke tako, da so le-ti šli preko Novega Sada (ne v CPU , temveč le skozi FEP). Burroughs v SDKJ je lahko poslal podatke za Osijek preko Sarajeva in Novega Sada. V Sarajevu so ti podatki šli v CPU tj. začasno na disk, od tu pa naprej kot izmenjavo podatkov med IBM računalnikoma, skozi FEP v Novi Sad do Osijeka.

Poskus še praktično potrdil pravilnost izbora SNA koncepta kot trenutno edino možnost za povezavo računalnikov instaliranih v SDK podružnicah med seboj. Vse to se pozneje popolnoma vklopi v javno
omrežje za prenos podatkov JUPAK, ki ga načrtujejo PTT organizacije. Javno omrežje za prenos podatkov bo omogočalo s hitrostjo do 64 Kbit/s zelo kvaliteten prenos istočasno pa zahteva določeno standardizacijo strojne opreme in sicer tistega dela, s katerim je računalniški sistem priključen na javno omrežje. Referenčni model za povezavo z javnim omrežjem je izdelala mednarodna organizacija za standarde (ISO), ki določa 7 nivojev, od uporabniških programov do fizičnih prenosov. Mednarodna organizacija za telefonijo in telegrafijo CCITT, je s svojim standardom X. 25 uredila spodnje tri nivoje, kar je tudi osnova paketnega prenosa podatkov. Načrtovane SDK mreža za TK prenos podatkov se bo vključila v JUPAK, zelo enostavno povedano, s pomočjo dodatne programske opreme NPSI (NCP Packed Switched Interface) v komunikacijskem kontrolerju. Poskus je tudi zanikal nekatere trditve v članku "Nujno enotno omrežje", ki je bil objavljen v SDK Obvestilih novembra 1984. Avtor piše, da »gre za povezavo računalniških sistemov treh različnih proizvajalcev, med katerimi je težko ali skoraj nemogoče vzpostaviti dialog«. Vsekakor smo pri poskusu naleteli na težave, ki smo jih uspešno rešili. Največji problem so bilo modemi in telefonske linije, kakšnih drugih omembe vrednih težav pa ni bilo. Skratka, zadane nalogo prenosa datotek smo praktično dokazali kot stvarno možnost, ki se lahko ob izdelavi potrebnih APS za TK prenos podatkov realizira v bližnji prihodnosti.

Poleg izbora vseh programskih komponent za nemoteno delovanje računalnikov smo tudi predlagali enoten način nakupa programov. IBM nudi možnost 25 % popusta pri nabavi programske opreme za več kakor eno inštalacijo. Podružnica Beograd je bila izbrana kot osnovna (bazna) inštalacija s polno ceno najema programske opreme, vse ostale podružnice z IBM opremo pa so tako imenovane DSLO (Distributed System Licence Option) inštalacije, katerim pripada že omenjeni popust. Na ta način se vsekakor prihranijo določena devizna sredstva, pridobi pa se tudi nekaj neugodnosti:

• sama bazna inštalacija dobi kompletno literaturo (DSLO nič),
• dobimo le en komplet programov na magnetnih trakovih (za DSLO jih nato sami prekopiramo),
• vsako prijavljanje napak v programski opremi poteka preko SDK podružnice Beograd, čeprav je center za tovrstno pomoč najbolj izkušen v Ljubljani.

Ker brez literature ne gre, smo naredili spisek le najbolj potrebnih knjig, katere bo SDKJ posebej kupila in uvozila za vse ostale podružnice.

V sodelovanju s skupino, ki je odgovorna za izdelavo APS za TK prenos podatkov, smo izdelali nujno potrebne parametre za TK prenos.

Zveza med IBM - NCR računalnikom omogoča POWER/RJE v.2 na IBM in RBS (Remote Batch System) na NCR strani. IBM prepozna NCR kot inteligentni terminal tipa 3780, ki podpira uporabo čitanja/luknjanja kartic in pisanja na printer. Isto velja za zvezo IBM - Burroughs z razliko, da Burroughs uporablja programsko podporo imenovano RJE 3780. Ker je IBM nadrejen NCR ali Burroughs računalniku, se celotna komunikacija vrši na prenosu podatkov v obliki stavka dolžine 80 znakov in opremljenih z ustreznimi krmilnimi karticami za IBM operacijski sistem. Vsak IBM računalnik v glavnem vozlu ima zvezo z ostalimi uporabniki mreže preko ostalih IBM računalnikov na osnovi že opisane SNA arhitekture. Prenosi med IBM se opravijo s pomočjo FTP, ki omogoča izmenjavo datotek brez omejitev na dolžino stavka ali nosilca podatkov v različnih kombinacijah (disk-disk, trak-disk itd.). FTP vsebuje tudi restart točke, kar pomeni, da se v primeru prekinitve prenosa le-ta nadaljuje od zadnje restart točke naprej. Potem ko IBM računalniki izmenjajo vse podatke med seboj, pripravijo tudi podatke za vse tiste NCR ali Burroughs računalnike, ki so vezani na njih. To so ponovno lahko stavki dolžine 80 znakov ali pa tiskane vrstice dolžine 132 znakov.

Direktna povezava NCR - NCR je možna s pomočjo RBS In IMOS/V operacijskega sistema. RBS simulira funkcijo IBM terminala 3780 in omogoča prenos datotek s dolžino stavka do 512 znakov. Tudi neposredna povezava Burroughs - Burroughs je možna, saj že danes deluje mreža SDK računalnikov v ožji Srbiji. Povezuje jih APS domače proizvodnje, izdelan v Interkomercu TOZD Informatika.

Naj zaključim z doseženim dogovorom pomočnikov generalnih direktorjev v SR, SAP in pomočniki generalnega direktorja SDKJ z dne 19. 6. 1985. Dogovorili so se, da glede na tehnične in kadrovske možnosti od 1. 10. 1985 prične s poskusnim in vzporednim delom APS za TK prenos podatkov v podružnicah Sarajevo, Novi Sad in Zagreb z IBM, v Zenici in Doboju z NCR ter v Subotici in Bački Topoli z Burroughs računalniki. Dogovorjeno je tudi, da se prične z rednim TK prenosom podatkov l. februarja 1986, do takrat pa se bodo čimprej zgoraj navedenim podružnicam priključile še vse tiste, ki bodo kadrovsko in tehnično pripravljene.

Literatura:

1. Tehnične komponente TK prenosa podataka u službi do uvodjenja javne mreže za prenos podataka, SDKJ, maj 1984
2. Idejni projekat APS za obradu podataka sa naloga platnog prometa u uslovima TK prenosa, SDKJ, september 1984
3. Beleške radne grupe za izradu predloga jedinstvenog softwera na IBM računarima službe, SDKJ, oktober 1984
4. Glasnik SDK, št. 6, junij 1984
5. Javno omrežje za prenos podatkov, naloga št. 21, ZPPT SR Slovenije, december 1983
6. Javno omrežje za prenos podatkov, Bit št. 2, julij-avgust 1984
7. IBM System Journal, Vol. 22, Nos. 1 and 2, 1983
8. The X. 25 Interface for Attaching IBM SNA Nodes to Packet Switched Data Networks, GA 27-3345, julij 1981
9. ACF/VTAM - General Information, Concepts, IBM GC 27-0463, februar 1981.

Informacija o možnosti izmenjave podatkov

Oktober 1985

V službi družbenega knjigovodstva so v glavnem trije tokovi izmenjave podatkov, ki se računalniško obdelujejo, in sicer:

1. izmenjava podatkov med organizacijskimi enotami službe,
2. izmenjava podatkov med organizacijskimi enotami službe in uporabniki družbenih sredstev
3. neposreden vpogled v podatke, ki so na računalniškem sistemu.

V nadaljevanju bomo na kratko pojasnili, kakšno je trenutno stanje pri vsakem tipu izmenjave podatkov in kakšne so nadaljnje možnosti.

Izmenjava podatkov med organizacijskimi enotami službe

Ta tok izmenjave podatkov obsega izmenjavo podatkov s področja plačilnega prometa, statističnih poročil in periodičnih ter zaključnih računov in omogoča izpolnjevanje nalog službe. Izmenjava teh podatkov poteka s pomočjo magnetnih trakov in zaradi dosedanjih tehničnih omejitev ni izpeljana kot neposredna izmenjava podatkov med računalniškimi sistemi. Z napravami, ki so že nabavljene (telekomunikacijska kontrolna enota) in s programskimi produkti, katerih nabava je načrtovana, bo mogoče interno izmenjavo podatkov tehnično posodobiti v smislu povezave računalniških sistemov. Kot enega od korakov do take rešitve lahko navedemo vnos podatkov preko dislociranega (oddaljenega) ekrana v nekaterih podružnicah.

Izmenjava podatkov med organizacijskimi enotami službe in uporabniki družbenih sredstev

Ta tok zajema izmenjavo podatkov na področju plačilnega prometa kot tudi na področju informacijske dejavnosti službe.

Prvi poizkusi so se v SR Sloveniji začeli že v preteklih letih, vendar le v podružnici SDK Celje. Pet temeljnih organizacij združenega dela in delovna skupnost skupnih služb Kovinotehne v Celju že več kot dve leti predlaga podružnici podatke iz zaključnih računov in periodičnih obračunov na magnetnih trakovih.

V lanskem letu pa so začele predlagati 4 delovne organizacije z 39 temeljnimi organizacijami in delovnimi skupnostmi skupnih služb, ob dvigu osebnih dohodkov, podružnici poleg virmanskih nalogov tudi podatke na magnetnih trakovih. Pobudo za sprejemanje podatkov na magnetnih trakovih je dala podružnica. Ni ji treba ponovno vnašati že enkrat vnesenih podatkov, organizacije združenega dela pa lahko predajo magnetne trakove, ki so rezultat njihovih računalniških obdelav.

Na področju plačilnega prometa je bil letos vpeljan obrazec "zbirni nalog za prenos". Izdelane so tudi programske rešitve, ki omogočajo obdelavo plačilnih nalogov, dostavljenih na magnetnem traku.

Novi obrazec »zbirni nalog za prenos« je v bistvu popis posameznih virmanskih nalogov, s katerim nalogodajalec-dolžnik plačuje v določenem dnevu svoje obveznosti raznim upnikom. Zato »zbirni nalog za prenos« vsebuje vse elemente - podatke, ki jih imajo posamezni nalogi. Podatki pa se lahko vnašajo na tiskani formular ali pa se tiskajo na računalniku. Prednosti zbirnega naloga so predvsem dvojne

1. odpade ponavljanje vseh informacij o nalogodajalcu - dolžniku in
2. odpade podpisovanje in žigosanje posameznih nalogov za prenos.

Če imata uporabnik družbenih sredstev in organizacijska enota službe izpolnjene ustrezne tehnične pogoje, se lahko dogovorita za izmenjavo podatkov na magnetnem nosilcu. V tem primeru predloži uporabnik družbenih sredstev službi skupaj z "zbirnim nalogom za prenos« tudi magnetni nosilec podatkov, ki pa mora vsebovati vse elemente posamičnih nalogov iz zbirnega naloga za prenos. In obratno: če se podatki z nalogov plačilnega prometa prenašajo po telekomunikacijskem sistemu in če se sprejemajo na magnetnih nosilcih, kar pomeni, da so izpolnjeni vsi tehnični pogoji, lahko sporoči podružnica SDK, ki je prejela podatke za uporabnika družbenih sredstev, te podatke uporabniku na posebnem obrazcu "zbirnem sporočilu o odobritvi - obremenitvi« in na magnetnem traku. Tako kot zbirni nalog za prenos je tudi »zbirno sporočilo o odobritvi - obremenitvi« popis posameznih virmanskih nalogov - sporočil, v glavnem o odobritvi žiro računov in drugih računov uporabnikov družbenih sredstev. Tako kot bo v primeru, če bodo uporabniki predložíli podružnici naloge za plačilo svojih obveznosti v obliki »zbirnega naloga za prenos« in izpisane na magnetnem traku, prihranjen službi ponovni vnos podatkov v računalnik, tako bo v primeru, ko bo služba dala uporabniku podatke o prilivu sredstev na njegove račune, vpisane na magnetnem traku, prihranjen uporabniku ponovni vnos teh podatkov v njegov računalnik. Interes izmenjave podatkov na magnetnih trakovih bo v bodoče obojestranski.

Pogoj za to pa je potrebna tehnična oprema za sporočanje podatkov o prilivu sredstev na račune uporabnikov družbenih sredstev na magnetnih trakovih in še vključitev podružnice SDK v telekomunikacijsko mrežo prenosa podatkov in sredstev v plačilnem prometu. Podružnica SDK, ki ni vključena v telekomunikacijski prenos podatkov, namreč ne evidentira v svoj računalnik, ko sprejme poročilo o prilivu sredstev na račune posameznega uporabnika, vseh podatkov, ki jih vsebuje poslovni virmanski nalog in ki so podlaga za knjiženje pri uporabniku družbenih sredstev.

Pričakujemo, da se bo izmenjava podatkov med uporabniki družbenih sredstev in službo družbenega knjigovodstva na računalniških medijih hitreje razvijala v okviru modernizacije tehnologije dela na področju plačilnega prometa, to je v pogojih telekomunikacijskega prenosa podatkov in sredstev v plačilnem prometu.

Služba je že sprejela vse potrebne normativne akte, opravila najvažnejše tehnološke priprave in pripravila plan vseli nujnih opravil pri uvajanju telekomunikacijskega prenosa podatkov.

Določeno je, da se prične 1. oktobra 1985 s poskusom, ki naj bi trajal 3 mesece, 3 podružnice službe družbenega knjigovodstva z območja SR Bosne in Hercegovine, SR Hrvatske in SAP Vojvodine. V prihodnjem letu pa naj bi se vključilo večje število organizacijskih enot službe; s l. februarjem v SR Sloveniji, ki imajo IBM računalniški sistem (podružnica v Ljubljani, Mariboru, Celju in Kranju).

Toda dokler podružnice SDK SR Slovenije ne bodo vključene v telekomunikacijski prenos podatkov in sredstev v plačilnem prometu, bodo lahko le sprejemale od uporabnikov podatke na magnetnih nosilcih, ne bodo pa jim jih mogle vračati.

Ker bo že v letošnjem letu vse podružnice SDK v SR Sloveniji tehnično in tehnološko sposobne sprejemati podatke o plačilih na obrazcih "zbirni nalog za prenos« in na priloženem magnetnem traku, bomo začeli vzpodbujati za tak način dela vse tiste uporabnike, ki imajo za to tehnične pogoje. Pri tem pa je treba podčrtati, da prehod iz sedanjega računalniškega izpisa podatkov po posameznih virmanskih nalogih na računalniški izpis podatkov v obliki "zbirnega naloga za prenos« in na magnetni trak ne bo enostaven. Priprave za uvedbo teh novitet pri posameznih organizacijah združenega dela so pokazale, da sedanji računalniški izpisi podatkov na posamezne virmanske naloge večkrat ne upoštevajo predpisanih standardov za posamezne elemente. To v sedanjem sistemu dela, ko izpis posameznih podatkov na virmanskem nalogu lahko popravi delavec službe, nima posledic, nestandardni izpis posameznih podatkov na magnetni trak pa bo v celoti onemogočil uporabo podatkov izpisanih na ta način. Zato bo potrebno zelo tesno sodelovanje strokovnih delavcev službe in uporabnikov družbenih sredstev, potrebna pa bo tudi pripravljenost uporabnikov družbenih sredstev, da spremljajo programe in izpis podatkov na virmanske naloge.

Vendar kljub temu, da bodo imeli uporabniki v začetku nekaj dodatnih del, pričakujemo, da bodo začeli uporabljati nov obrazec »Zbirni nalog za prenos« in magnetni trak, ker jim vendarle bistveno zmanjša obseg določenih opravil pri nakazovanju sredstev, kot so podpisovanje in žigosanje velikega števila posameznih virmanskih nalogov in količino potrebnega papirja. To pa je bilo vedno predmet negodovanja organizacij združenega dela.

V okviru svoje informacijske dejavnosti pa služba že sedaj daje na magnetnih trakovih uporabnikom družbenih sredstev na njihovo zahtevo oz. željo vse podatke, ki jih računalniško obdeluje. To so predvsem podatki iz zaključnih računov, periodičnih obračunov uporabnikov družbenih sredstev in podatki iz registra uporabnikov družbenih sredstev.

Neposreden vpogled v podatke, ki so na računalniškem sistemu

Ta možnost je že razvita za potrebe nekaterih funkcij službe, nismo pa še tehnično opremljeni za širšo uporabo takih obdelav. V službi so ustrezni terminali trenutno priključeni na sistem lokalno, kar pomeni strogo omejitev glede možnosti uporabe takega terminala celo v organizacijskih enotah službe. Nova oprema bo omogočila oddaljeno povezavo terminalov. S tem lokacija uporabnika ne bo več omejena na bližino računalniškega sistema, kar pomeni bistveno razširitev kroga potencialnih uporabnikov.

Prevzem podatkov na trakovih v SDK Celje

Februar 1984

Z instalacijo računalniških sistemov v organizacijskih enotah službe so bila sicer avtomatizirana nekatera najpomembnejša opravila, ki so se doslej opravljala ročno ali s pomočjo nižje in srednje mehanizacije, vendar pa s tem še niso bila izpolnjena vsa pričakovanja v zvezi z avtomatizacijo opravil službe. Tehnologija dela se ob prehodu namreč ni bistveno spremenila, še vedno je za posamezne vrste obdelav, predvsem v obdelavi nalogov plačilnega prometa, potrebno veliko ročnega dela. Službi tudi doslej ni uspelo zmanjšati števila raznovrstnih obrazcev, ki se uporabljajo kljub sodobni obdelavi podatkov.

Pobude za modernizacijo tehnologije dela v službi so bile dane že v letih 1980 in 1981. Izdelani so bili tudi že nekateri predlogi, vendar do bistvenih sprememb ni prišlo. Pomembnejši je le prehod na telekomunikacijski prenos podatkov med organizacijskimi enotami službe, v katerega sta vključeni tudi podružnici Ljubljana in Maribor in predlaganje statističnih poročil centrali na magnetnih trakovih.

Za čim hitrejšo izpolnitev smernic programa modernizacije opravil si mora služba prizadevati, da bi čim prej zaživela izmenjava podatkov med uporabniki družbenih sredstev in organizacijskimi enotami službe na magnetnih nosilcih podatkov. S tem bi služba na marsikaterem področju racionalizirala delo. Zmanjšalo bi se število dokumentov, ki sedaj krožijo med uporabniki družbenih sredstev in organizacijskimi enotami službe, zmanjšal bi se obseg vnosa podatkov in sortiranja dokumentov, razen tega pa bi služba s tem zagotovila še hitrejšo in kvalitetnejšo obdelavo nalogov plačilnega prometa. Telekomunikacijski prenos sredstev med vsemi organizacijskimi enotami službe pa bi še zmanjšal zadrževanje sredstev v kanalih plačilnega prometa in pospešil obračanje sredstev.

Za realizacijo naštetih ciljev pa mora služba izdelati novo konstrukcijo žiro in drugih računov uporabnikov družbenih sredstev, nov register uporabnikov, plan računov službe, numerično označevanje namena nakazila in sklicevanja na številko.

Ker se izvedba nove tehnologije iz leta v leto odmika, smo v podružnici Celje sami pričeli poskusno prevzemati določene podatke na magnetnih trakovih od nekaterih organizacij združenega dela, to so podatki iz zaključnih računov in periodičnih obračunov ter za izplačilo osebnih dohodkov delavcev v združenem delu.

Prevzem podatkov iz zaključnih računov in periodičnih obračunov na magnetnih trakovih

Podružnica je prvič prevzela podatke iz periodičnih obračunov za obdobje januar - junij 1982 na magnetnem traku od delovne organizacije Kovinotehna Celje. Podatki so se nanašali na sedem temeljnih organizacij združenega dela in delovno skupnost skupnih služb. Program za zapis podatkov na magnetni trak so izdelali delavci Kovinotehne v sodelovanju s predstavniki SERC v Ljubljani. Zapis vsebuje vse ustrezne podatke, ki so predpisani z obrazci ZR in POR. Poleg magnetnega traku pa predlaga Kovinotehna tudi računalniško izpisane obrazce ZR oz. POR za vse temeljne organizacije združenega dela in delovno skupnost skupnih služb.

Glede na doseženo uspešnost poskusa in racionalizacijo dela predvidevamo, da se bo ta način prevzemanja podatkov v letu 1984, še razširil, posebej še, ker je Kovinotehna Celje v lanskem letu prevzela računalniško obdelavo podatkov za SOZD Merx Celje in bo lahko koristila vse svoje projekte tudi za to organizacijo združenega dela.

S predlaganjem podatkov na magnetnih medijih se je precej olajšalo delo pri vnosu podatkov v službi, pri organizacijah združenega dela pa odpadlo prepisovanje podatkov v predpisane obrazce ZR in POR, zato podružnica teži za tem, da bi v to vključila še druge organizacije združenega dela, ki imajo računalniško obdelavo podatkov.

Prevzem podatkov za izplačilo osebnih dohodkov na magnetnem traku

Obračun osebnih dohodkov za delovno skupnost podružnice smo prenesli na računalniški sistem v začetku leta 1982. Sprva smo vnašali podatke za izplačilo OD na IBM S-l, opravili obračun z vsemi izpisi, nato pa ponovno vnašali podatke z nalogov preko S-l, za nadaljnjo obdelavo v plačilnem prometu. Da bi racionalizirali delovne postopke, smo po opravljenem obračunu osebnih dohodkov prepisali podatke na magnetni trak in jih neposredno vključili v dnevno obdelavo.

Ustrezne programe so izdelali delavci SERC in podružnice v Ljubljani. Po izpopolnitvi projekta poteka obdelava osebnih dohodkov po tem načinu nemoteno.

V letu 1982 smo se pričeli dogovarjati tudi z nekaterimi organizacijami združenega dela, da bi nam ob izplačilu osebnih dohodkov poleg predpisane dokumentacije predložile še magnetni trak z ustreznimi podatki. Doslej poteka tak način dela pri treh organizacijah združenega dela na območju podružnice Celje. Kljub nekaterim težavam ugotavljamo, da delo uspešno poteka, čeprav v sedanji fazi zahteva veliko sodelovanja med uporabnikom in podružnico. Uporabnik mora namreč na naloge za izplačilo vnašati tudi šifre razčlenjenega prometa in oštevilčiti naloge po vrstnem redu. Magnetni trak pa mora vsebovati vse podatke z nalogov, oblika zapisa pa je prilagojena navodilom za obdelavo nalogov plačilnega prometa v organizacijskih enotah. Vsak trak je zajet v obdelavo kot samostojni paket s konstantno številko, ki jo uporabniku določi podružnica. Poleg magnetnega traku in nalogov predloži uporabnik še računalniški izpis podatkov z rekapitulacijo, ki služi za kontrolo opravljenega obračuna osebnih dohodkov.

Predhodna kontrola v podružnici prevzame od uporabnika magnetni trak in drugo dokumentacijo za izplačilo osebnih dohodkov. Po opravljeni predpisani kontroli sestavi delavec še posebno listo popravkov za morebitne napake, ki jih je ugotovil pri pregledu predložene dokumentacije ter izloči naloge za telefonska in teleprinterska nakazila, ki se obdelajo posebej in vnesejo preko IBM S-l.

Po opravljeni kontroli preda delavec predhodne kontrole naloge za izplačilo osebnih dohodkov skupaj z magnetnim trakom, rekapitulacijo in listo popravkov v oddelek AOP, kjer magnetni trak vključijo v redno dnevno obdelavo plačilnega prometa, tiskajo kontrolno listo in opravijo ustrezne popravke, naloge pa normalno vključijo v sortiranje. S tem je krogotok obdelave osebnih dohodkov zaključen.

Naša prizadevanja v letu 1984 bodo tekla še intenzivneje v tej smeri, da bi čim več uporabnikov vključili v tak način obdelave osebnih dohodkov. Sami uporabniki pa bodo verjetno še bolj zainteresirani za izmenjavo podatkov na magnetnih medijih v pogojih nove tehnologije, ki bo omogočila zmanjšanje števila nalogov, zmanjšanje stroškov in recipročnost pri izmenjavi podatkov na magnetnih medijih.

Februar 1984

Nujno enotno omrežje

Javno omrežje za prenos podatkov v Sloveniji

Javno omrežje za prenos podatkov mora po zakonu zagotoviti hiter, varen, zanesljiv in racionalen prenos podatkov in sporočil za vse subjekte družbenega sistema informiranja - V Jugoslaviji potrebujemo enotno omrežje.

V naši republiki že dlje časa tečejo priprave za oblikovanje družbenega sistema informiranja, katerega sestavni del je javno omrežje za prenos podatkov. Javno omrežje za prenos podatkov mora po 21. členu zakona o družbenem sistemu informiranja (Ur. l. SRS, št. 10/83) zagotoviti hiter, varen, zanesljiv in racionalen prenos podatkov in sporoči za vse subjekte družbenega sistema in formiranja ter medsebojno povezavo računalniške in druge informacijske opreme pod enakimi pogoji in z enakimi stroški uporabe na celotnem območju naše republike. Hkrati pa mora zagotoviti zveze za prenos podatkov na ozemlju Jugoslavije ter z omrežji drugih držav in mednarodnih skupnosti. Sestavljajo ga posredovalne in prenosne naprave in omrežni krmilni center.

Gradnja javnega omrežja za prenos podatkov je predvidena tudi v dogovoru o temeljih družbenega plana SR Slovenije, v samoupravnem sporazumu o temeljih plana razvoja ZO PTT Slovenije, v družbenem planu SR Slovenije in v planu razvoja ZO PTT Slovenije za obdobje 1981 - 1985.

Značilnosti javnega omrežja za prenos podatkov so:

• je mednarodno standardizirano, kar pogojuje tudi standardizacijo računalniške opreme,
• s konverzijo hitrosti, kod in prenosnih postopkov omogoča povezavo računalniške opreme različnih vrst in proizvajalcev,
• je osnovni infrastrukturni objekt družbenega sistema informiranja,
• omogoča dostop do domačih in tujih bank podatkov,
• omogoča uvajanje novih storitev (teletekst, videotekst itd.),
• zagotavlja zelo kakovosten prenos informacij,
• posebni prenosni postopki in možnost oblikovanja zaprtih uporabniških skupin zagotavlja varen prenos informacij,
• izvedba omrežja in organizacija njegovega vzdrževanja oziroma upravljanja zagotavljata veliko zanesljivost delovanja,
• vsem uporabnikom zagotavlja enakopraven položaj,
• prispeva k enotnosti informacijskega prostora v SR Sloveniji in SFR Jugoslavije ter skladnejšemu razvoju Slovenije in Jugoslavije

Dosedanje razprave na republiškem komiteju za promet in veze, republiškem komiteju za informiranje, v gospodarski zbornici in v drugih organih in organizacijah v republiki so potrdile, da ne smemo dopustiti velikega zaostajanja informatike, kajti posledice bi lahko bile usodna. Zato je zelo pomembno, da s skupnimi napori zgradimo javno omrežje za prenos podatkov v SR Sloveniji.

Predračunska vrednost gradnje javnega omrežja za prenos podatkov znaša 290.400.000 dinarjev, v letu 1984 pa naj bi uporabniki združili 128 milijonov dinarjev. Ker gre za gradnjo osnovnega infrastrukturnega objekta družbenega sistem informiranja je predvidena tudi odpoved pravici do povrnitve nadomestila za gospodarjenje, med tem ko se bodo združena sredstva vračala tako, d bo uporabnikom, ki bodo združili delo in sredstva, z dogovorom določena nižja cena, ki jo bodo plačevali toliko časa, da jim bo vrnjen znesek združenih sredstev. Investitor bo vračal združena sredstva uporabnikov v revalorizirani vrednosti. Letna stopnja revalorizacije bo enaka odstotku povečanja cen storitev za prenos podatkov v javnem omrežju v preteklem letu (Obrazložitev Podjetja za PTT promet Ljubljana v GV, št. 27, letnik 84).

Služba družbenega knjigovodstva v SR Sloveniji se je aktivno vključila v priprave za izgradnjo javnega omrežja, saj predstavlja to delo pravzaprav nadaljevanje začetih poskusov službe, da zgradi lastno mrežo za prenos podatkov. Pri začetem delu je namreč služba naletela na skoraj nepremagljive težave. Gre za povezavo računalniških sistemov treh različnih proizvajalcev, ki so trenutno instalirani v podružnicah SDK v Jugoslaviji, med katerimi je težko ali skoraj nemogoče vzpostaviti dialog v smislu skupnega reševanja problema povezovanja in prenosa podatkov. Gre za objektivne tehnične ovire in interne standarde različnih proizvajalcev, ki onemogočajo neposredno povezavo sistema s sistemom.

Ponudba pošte, da reši transportne probleme pri telekomunikacijskih povezavah z javnim omrežjem za prenos podatkov, je prišla kot naročena. Z javnim omrežjem bi lahko povezali različne računalniške sisteme SDK v SR Sloveniji (IBM in Burroughs) in tako modernizirati večino plačilnega prometa v republiki, katerega le manjši del je usmerjen v druge republike in pokrajini.

Povedati je treba, da se je PTT v Sloveniji in na Hrvaški odločila za švedskega proizvajalca opreme Ericsson in njegov sistem prenosa podatkov Eripax.

Prestop na javno omrežje za prenos podatkov pa kljub temu ni tako enostaven, ker je šlo za dve različni ideji. SDK načrtuje lastno (privatno) mrežo za prenos podatkov na območju cele države, PTT v Sloveniji pa javno omrežje za prenos podatkov v republiki. Že omenjene tehnične probleme prenosa v privatni mreži SDK, hočejo rešiti domači proizvajalci računalniške opreme, ki pa se žal ne morejo sporazumeti, saj ponuja vsak svojo rešitev, ki je vezana na njihovo strojno opremo in njihovo programsko opremo. Koliko so te različne rešitve res plod lastnega razvoja in dela je seveda drugo vprašanje, na prvi pogled zanemarljivo, v bistvu pa odločujoče, saj gre v večini primerov za kupovanje znanja in sredstev v tujini. Le Energoinvest iz Sarajeva je, po njegovih navedbah, uspel izdelati programe za kontrolo in prenos podatkov javnem omrežju.

SDK je zahtevala od Skupnosti PTT Jugoslavije in domačih proizvajalcev, ki naj bi gradili javno omrežje v drugih republikah, da se sporazumejo za enotno jugoslovansko omrežje za prenos podatkov. O nastalem problemu postopnega širjenja javnega omrežja in različnih tehničnih rešitev je razpravljal tudi Odbor za družbeni plan in razvojno politiko Skupščine SFRJ dne 12. 9. 84. Odbor se zavzema za to, da bi bila izgradnja javnega omrežja skupna prioritetna naloga. Nosilci gradnje bi morale biti organizacije PTT prometa, sodelovati pa bi morali ustrezni družbeni subjekti in neposredni uporabniki. Projektu bi bilo treba zagotoviti širšo družbeno podporo in verifikacijo. Tehnično in tehnološko enotnost bi bilo treba, po mnenju Odbora, zagotoviti s predpisovanjem tehničnih pogojev za vso opremo in z izdelavo generalnega plana razvoja. Odbor je mnenja, da se ne sme dovoliti izgradnja več lastnih sistemov za prenos podatkov (kot je to bil primer z zahtevo SDK), ker bi bila taka rešitev ekonomsko neupravičena.

Odbor je bil seznanjen, da je realizacija zamisli o enotni jugoslovanski mreži, ki so jo sprejeli samoupravni organi Skupnosti JPTT, že v teku. Kljub temu je odbor naslovil na predstavnike pošte nekaj vprašanj in to:

• ali je že prišlo do sestanka zveznega komiteja za promet in zveze, zveznega komiteja za energetiko in industrijo, zainteresiranih proizvajalcev ter PTT, na katerem bi izbrali sistem za prenos podatkov,
• ali SDK še vedno vztraja pri lastni mreži,
• kolikšen bo delež domače industrije,
• ali je izvršena ocena s stališča varnosti in splošne ljudske zaščite,
• s predpostavko, da je sistem v Sloveniji in Hrvaški že izbran, kaj bo z mrežo v Jugoslaviji, če ne bo prevzeta ista tehnologija,
• ali domači proizvajalci zadovoljujejo zahtevam in standardom internacionalne organizacije PTT podjetij,
• ali je predvidena tehnološka rešitev res najbolj ekonomična in tehnično najboljša

Odbor je sklenil, da bo po ustrezni obdelavi te problematike v Zveznem izvršnem svetu (ZIS) ocenil, na kakšen način se bo projektu zagotovila nadaljnja družbena verifikacija.

Skoraj enak pristop do te problematike je imel tudi Svet SDK v SR Sloveniji, ki je postavil dva pogoja pred sprejemom Samoupravnega sporazuma o združevanja dela in sredstev za izgradnjo javnega omrežja za prenos podatkov v SR Sloveniji:

1. Združene PTT organizacije Slovenije morajo pridobiti od Skupnosti JPTT potrdilo, ki bo jamčilo za nemoten prenos podatkov, ne glede na razlike v tehničnih rešitvah omrežja v državi ter podatek o ceni takega prenosa,
2. SDKJ mora jamčiti za nemoten telekomunikacijski prenos podatkov plačilnega prometa v primeru spajanja privatne TK mreže SDK v drugih republikah in javnega omrežja v Sloveniji.

SDK v tem času nadaljuje z intenzivnimi razgovori z domačimi proizvajalci in PTT. Za sedaj še ni sporazuma o enotni tehnični rešitvi, kar pa bo neposredno vplivalo na delo SDK. Neizvršena bo ostala naloga službe, da izpelje telekomunikacijski prenos podatkov plačilnega prometa in zaustavi originalne dokumente na sedežih iniciative.

November 1984