Povzetek
Prispevek obravnava težave pri vnosu velike količine raznovrstnih podatkov na področju plačilnega prometa in tudi pri statističnih obdelavah. Ko je leta 1976 IBM objavil računalniški sistem Series/1, je SDK kupila več teh sistemov in dolgoročno rešila predvsem vnos podatkov (zamenjava strojev znamke DATICA, ki je podatke »luknjal« v papirni trak) in pozneje tudi del obdelav, predvsem izpisov.
IBM introduced the new Series/1 computer in November 1976 for experienced data processing users, i.e., primarily for customers with programming capabilities and a need for multiple systems. It was a general purpose system that offered both communications and sensor-based capabilities, and it enabled users to attach a large number and variety of input and output units, including custom-built devices for special applications.
The Series/1 consisted of 19-inch rack-mountable data processing units. It initially was available with two processors: a Model 3, ranging in memory size from 16K to 64K, and a Model 5, ranging from 16K to 128K.
In addition to the processors, the Series/1 also offered at announcement a fixed disk storage unit containing 9.3 million bytes of storable space; a diskette unit able to store either up to 250,000 or up to 500,000 bytes on one- or two-sided diskettes, respectively; a matrix printer which provided 120 character per second bi-directional capability; a display station; a sensor Input/Output unit; an I/O expansion unit to attach additional devices; various communications features; and OEM attachment features. Various processors and peripherals of the Series/1 were withdrawn from marketing between 1983 and 1987.
Zaradi vedno večje količine podatkov, ki jih je bilo potrebno kvalitetno spraviti v elektronsko obliko, je veliki modri izdelal računalnik Seria/1 (tudi S/1), ki naj bi to omogočal. Osnova je bila standardna omara (19-inch rack) visoka okoli 1,9 m in je bila razdeljena na posamezne “police”. Ker je bilo polic običajno premalo se je v praksi sestavilo več takih omar brez vmesnih sten v celoto. V Ameriki so potem posamezne S/1 povezovali v omrežja v obliki obroča.
Za nakup takih sistemov se je odločila takratna Služba Družbenega Knjigovodstva in sicer: Ljubljana – 4 sisteme, Maribor – 3 sisteme, Kranj – 2 sistema, Celje – 2 sistema, Beograd, Novi Sad, Zrenjanin po 1 sistem in Skopje – 3 sisteme.
Običajna konfiguracija je bila v dveh omarah, v katerih sta bila dva diska po 9,3 MB. Disk je imel eno okoli pol metra veliko ploščo postavljeno navpično z dvema bralno-pisalnima glavama na podobnem aktuatorju kot jih imajo sedanji diski v PC-jih. Na drugi strani plošče pa je bilo še 8 fiksnih glav zaradi boljšega in predvsem hitrejšega delovanja. Hitrost diska je bila okoli 3000 o/m. Velikost posameznih datotek je bila fiksna, saj je bilo potrebno ob postavljanju le teh vpisati njihovo velikost ali pa direktno vpisati od kje do kje na disku se ta fizično nahaja. Prav tako je bila dolžina sektorja vnaprej določena na 128 ali 256 bytov. Tudi disketa velikosti 8,5 palcev je bila enostranska za prenos podatkov z možnostjo vpisa 1898 slogov v dolžini 128 bytov. Dvostranska disketa pa je imela možnost do 3848 zapisov v dolžini 128 bytov. Te diskete so se uporabljale predvsem za shranjevanje izvornih datotek posameznih programov, že prevedenih programov, kontrolnih tabel in ostalih datotek potrebnih za delovanje sistema in so bile napolnjene izključno na S/1, ker jih disketne enota na IBM mainframe računalniku ni prepoznala. V policah je bil tudi prostor za priključek do 30 terminalskih kartic. Dolžina terminalskega priključnega kabla je bila od 5 do 250 m. Kartico zmogljivega linijskega tiskalnika do 520 vrstic na minuto, kartico igličnega tiskalnika do 90 vrstic na minuto. Bila je tudi opcija tračne enote in direktna kabelska povezava z IBM mainframe računalnikom . Možni so bili tudi diski po 13 MB in kot največji 64 MB. Sam sistem pa je imel 128 KB spomina, razširljivega na 256 KB ali 512 KB. V sistemu je bilo več hladilnih ventilatorjev, tako da po zagotovilih IBM ni bilo potrebno postaviti dodatnih klimatskih naprav, kar pa se je v poletnih mesecih pokazalo za netočno, ko je občasno prišlo do pregrevanja sistema in včasih tudi do pregrevanja posameznih kartic zlasti, če je bila notranjost sistema preveč zaprašena in, če kateri od hladilnih ventilatorjev ni deloval in tako ni bil vzpostavljen dovolj močan pretok zraka po sistemu.
Operacijski sistem je bil CPS – Controll Program Support napisan v Assembler programskem jeziku in z možnostjo istočasnega delovanja različnih programov v 7 particijah (če je bilo dovolj prostega spomina). Znotraj tega je deloval IDES – Intelligent Data Entry System tudi napisan v Assemblerju. Bilo je še nekaj standardnih programov za formatiranje, listanje, kopiranje diska ali disket, kreiranje datotek na disketah ali diskih, vračanje ali shranjevanje paketov, programov, tabel ali sporočil. V CPS je bil na nekaterih sistemih vgrajen tudi Assembler za S/1. To je bila sistemska programska oprema. Bila je tudi opcija programskega jezika COBOL, ki pa žal nikoli ni bil kupljen, tako da je bilo potrebno del programov za nadaljnjo obdelavo vnesenih podatkov napisati v assemblerju za S/1.
V IDES-u pa je bilo dokaj močno posebno programsko orodje namenjeno za pisanje različnih vnosnih programov za posamezne vrste poslov, ki so se obdelovali v SDK. V primerjavi s sedanjimi PC-ji je bilo to nekaj podobnega kot DOS 6.22 in znotraj njega Windows 3.11 s kakšnim enostavnim Visual BASIC.
Ker je imela Ljubljana 2 sistema na lokaciji Cankarjeve ulice, ki sta bila direktno povezana s IBM mainframe računalnikom (do komuniciranja ni prišlo nikoli, ker ni bilo kupljeno potrebno programske opreme), enega na Miklošičevi cesti in enega nasproti Gospodarskega razstavišče za Bežigradom, so sistemi dobili imena po posameznih obdelovalnih mestih in sicer S1/01 (Cankarjeva prvo nadstropje), S1/02 (Cankarjeva drugo nadstropje), S1/03 (Miklošičeva) in S1/04 (Bežigrad). Ta imena so ostala do konca in so po njih poimenovali tudi sedanje strežnike, čeprav verjetno malokdo ve zakaj taka imena.
Tako je prišlo poletje 1980. Projekt PUPAK (Projekt Upisa Podataka Automatskom Kontrolom), ki ga je začel razvijati SDK Jugoslavije v Beogradu ob sodelovanju vseh republiških central, je bil že dovolj razvit, da je lahko šel v testiranje v živo. Da pa ne bi bilo podobnega presenečenja kot ob prehodu Ljubljane iz ročnega knjiženja na računalniško obdelavo, je bil prehod postopen in sicer tako, da se je počasi vedno več podatkov plačilnega prometa vnašalo na S/1, kar je bilo odvisno od pripravljenih prostorov in usposobljenosti operaterk in stare iztrošene DATICE so počasi prehajale v pokoj. Zaradi varnosti in rezerve v času pa smo Kranj startali v petek 8. 5. 1981 in Celje v petek 22. 5. 1981. Oba starta sta bila v splošno veselje uspešna in zaključek dnevnega vnosa pravočasen. Ker so bili vneseni podatki praktično čisti, je bil zaključek dnevne obdelave še hitrejši kot običajno!
Zakaj taka prednost vnosa in način dela na S/1
Vsak dan so na centralnem sistemu izdelali »matično« datoteko z vsemi aktivnimi in neaktivnimi ključi v obliki Račun-Namen-Partija-Ekspozitura-Aktivnost, torej brez sedeža, in ker so se ključi v posameznih podružnicah ponavljali, so se na diskete lahko prepisali podatki matične datoteke samo ene podružnice. Prav tako se je dnevno izdelala disketa s kontrolnimi tabelami šifer razčlenjenega prometa za posamezne račune in še nekaj drugih kontrolnih tabel, katerih vsebina se je spreminjala in so bile namenjene kontroli pravilnosti vnosa nalogov plačilnega prometa.
Start Serije/1
Vsakodnevni jutranji zagon je imel točno predpisan vrstni red: vklop vseh perifernih enot in nazadnje CPU, ker je procesor miroval in je čakal na pozive posameznih priključenih enot. Sledilo je čitanje diskete RAM, ki je napolnila znakovni nabor tipkovnice konzole, vpis startnega naslova na disku kjer je bil IPL (Initial Program Load) in vpis tekočega datuma. Tako je bil sistem pripravljen za start posameznih programov in vsi terminali razen konzole so bili še neaktivni.
Sedaj je bilo potrebno iz diskete prepisati matične podatke in jih indeksirati. Če je bil to nov delovni dan in stari vneseni podatki niso bili več potrebni se je pričelo brisati stare podatke. To se je storilo tako, da se je v veliko datoteko (praktično cel disk, ki je imel možnost vpisa do okoli 30.000 slogov) DEFILE (Data Entry FILE) iz diskete prepisalo osnovne programe, sporočila in osnovne tabele. S programom DEBURP (Data Entry Back Up Restore Program) se je vračalo še ostale kontrolne tabele in programe. Ker je bil DEFILE prepisan iz diskete je ta operacija trajala kar nekaj časa, saj se je datoteka DEFILE na disku praktično formatirala, tj. brisali so se nepotrebni podatki in na novo se je razporejal prazen prostor potreben za nadaljnje delo. Ko so bili vrnjeni vsi trenutno potrebni programi in kontrolne tabele, se je startal program IDES, ki je porabil 56 KB spomina. Na prižganih vnosnih terminalih se je prikazal začetni ekran: INTELLIGENT DATA ENTRY SYSTEM, oziroma kasneje PUPAK, ko se je našel način za programiranje začetnih ekranov. Ob različnih prilikah smo postavil v začetni ekran tudi različne čestitke, ali pa kaj podobnega.
Po pritisku na katerokoli tipko se je vsak operater moral predstaviti sistemu in vpisati geslo. Gesla so bila za tri nivoje: osnovno samo za možnost vnosa podatkov, programersko za možnost vnosa podatkov, programiranje in vzdrževanje kontrolnih tabel ter še geslo nadzornika, ki je omogočalo vnos, programiranje, vzdrževanje in kreiranje kontrolnih tabel, sporočil, pregled vnesenih podatkov, pripravo posameznih paketov za prepis na diskete, pregled statusa operaterjev in njihovo trenutno delo, pregled trenutno razpoložljivih vnosnih programov kompletno brisanje vnesenih podatkov in spreminjanje sistemskih gesel. Če je nekdo spremenil geslo nadzornika, ga pozabil in ni bil pred tem nihče prijavljen kot nadzornik, ni bilo več mogoče priti do menija s funkcijami nadzornika, pripravljati posameznih paketov za prepis, ali drugače povedano: ponovno je bilo potrebno vrniti čisti DEFILE in stvar pričeti znova! Na srečo se je našlo tudi fizično mesto na disku, kjer so bila vpisana gesla tako, da se je stvar lahko pokrpala in nič krivim operaterkam ni bilo potrebno ponovno vnašati neprepisanih podatkov.
Pri vnosu podatkov je IDES na konzolo občasno pošiljal poročilo o polnosti datoteke DEFILE od nivoja 4 do 0. Če je slučajno prišlo do nivoja 1, je sistem nekaj časa pošiljal to sporočilo po vsakem vpisanem slogu dokler ni prišel do nivoja 0, kar je pomenilo, da je prostor DEFILE poln in ni več nobenega prostega mesta za vpis. Sistem se je ustavil in potrebno je bilo kar nekaj telovadbe za ponovni zagon oziroma vrniti čisti DEFILE in stvar pričeti znova. To se je redko dogodilo, ker so se vneseni podatki po uspešnem prepisu in uspešni obdelavi na osrednjem sistemu sproti brisali. Podatki različnih statističnih poročil, ki se niso sprotno obdelovali na osrednjem sistemu pa so se morali obvezno prepisati na dva kompleta disket, ker so se že takratne diskete kvarile. Takratne diskete so bile zelo drage, in zato so se veliko uporabljale iste diskete, dokler niso bile fizično tako spraskane, da jih noben stroj ni znal več prečitati oziroma pisati po njih. Pri prepisovanju podatkov na dva kompleta disket se je tudi včasih dogodilo, da kak del na obeh kompletih ni bil čitljiv. Ker je bil zapis sekvenčen se je dalo s programom za kopiranje kopirati dobre sektorje v poljubnem zaporedju iz tako pokvarjenih disket in izgubljen ni bil skoraj noben zapis. Če je med vnašanjem podatkov slučajno prišlo do izpada električne napetosti, ali se je sistem kakorkoli obesil so bili po ponovnem startu IDES izgubljeni samo zapisi, ki so se trenutno vnašali. To praktično pomeni, da je bilo izgubljeno samo toliko zapisov kolikor operaterjev je trenutno pisalo, ker se je vsak vpis, ko je bil kontroliran in dokončan takoj avtomatsko vpisal na disk.
Toliko o samem načinu delovanja Serije/1. V naslednjem delu še nekaj o vnašanju podatkov. Za primer je vnos in možno obdelavo nalogov plačilnega prometa, ker je bil to najmasivnejši dnevni posel, ki se je opravljal na Seriji/1 pa tudi samo delo je bilo maksimalno optimizirano in programje najbolj dodelano. Princip samega vnosa podatkov je bil pri različnih vrstah posla dokaj podoben, razen po vsebini in načinu kontrole posameznih podatkov, ki so se zbirali.
Vnos nalogov PP
Vsako obdelovalno mesto v Ljubljani je imelo vnaprej določene številke paketov za plačilni promet, ker se te dnevno niso smele ponavljati. Po prijavi na sistem je vsaka operaterka vpisala ime programa, ki ga bo trenutno uporabljala, v tem primeru PP in vnaprej določeno številko paketa. S tem je bila trenutna prijava končana in sistem jo je postavil v zgornji levi del ekrana, ki je bil razdeljen na 24 vrstic in 80 kolon, na prvo polje (Vir Informacije) za vnos minusnega stavka. Po vnosu vsakega posameznega polja je sistem ta vnos prekontroliral in takoj zvočno in z izpisom opozoril na morebitno napako, zato operaterki praktično ni bilo potrebno stalno gledati v ekran. Po uspešno vnesenem minusnem slogu se je sistem premaknil na prvo polje (SEDEŽ) plusnega stavka, ki je bil na desni polovici ekrana malo pod zapisom minusnega stavka. Tu se je pokazala prva prednost vnosa podatkov na S/1, saj je bilo polje SEDEŽ programirano tako, da se je s pritiskom tipke ENTER v polje avtomatsko vpisal domači sedež in kurzor je šel na polje RAČUN. Polje SEDEŽ je bilo programirano tudi tako, da so se lahko določeni ključi, ki so se masovno ponavljali dobili s pritiskom na določeno črko in sistem je napolnil polje SEDEŽ, RAČUN, NAMEN in PARTIJA ter postavil kurzor v naslednje polje, ki se je zahtevalo pri določenem viru informacije. Hkrati je bila tudi opravljena kontrolna primerjava z matično, če je vpisani ključ pravilen, aktiven in sistem je v SEDEŽ vpisal še poslovalnico oziroma ekspozituro, kjer je bil račun odprt. Po vnosu šifer razčlenjenega prometa, ki so se kontrolirale glede na vrsto računa in zneska je bil en nalog obdelan, zapisan na disk in kurzor se je ponovno postavil na polje sedež čakajoč na nov vnos. Istočasno se je na ekranu tudi prikazala nova trenutna vsota vnesenih nalogov in nova trenutna razlika za vnesene naloge v LC (logični celoti), ki se je vnašala. V polju sedež je bil možen tudi vnos vejice, kar je sprožilo možnost kontrole delne vsote. To je bilo uporabno pri vnosu nalogov ZA (zbirnih aviz ali pošt), da se je preverilo še računsko točnost že vnesenih podatkov v nedokončani LC. Konec in zaključek vnosa posamezne LC je bila pika v polju sedež. Če je bila vsota vnesenih podatkov enaka vpisanemu znesku minusnega stavka, se je kurzor ponovno postavil v prvo polje minusnega stavka in čakal nadaljevanje, drugače pa je sistem zvočno in z izpisom opozoril na razliko v LC. Dolžnost operaterke je bila, da je z listanjem skozi LC z razliko to razliko popravila. Postopek vnosa posameznih LC se je ponavljal skozi ves paket. Vnosi podatkov v posamezna polja so se sproti kontrolirali. Vnašalo se je samo v polja, ki jih je zahteval posamezen Vir Informacije. Vsako polje plusnega stavka se je lahko dupliciralo s tipko DUP in tako je bila še dodatno pospešena možnost hitrejšega vnosa. Tak način vnosa podatkov s pomočjo okrajšav in dupliciranja posameznih polj je bil sicer dvorezen meč, saj je bila pri neprevidnem vnašanju bistveno povečana možnost napačnega usmerjanja posameznih nalogov. V povprečju pa je bilo za vnos posameznega naloga PP pritisniti okoli 18 različnih tipk.
Ko je bilo vneseno in pravilno dokončano dogovorjeno število paketov za posamezno ŠKATLO, se je vnesel še dnevnik klasiranja (DNKL) za določeno škatlo z vnaprej določenim vrstnim redom posameznih paketov PP, ker so operaterke vsako dokončano LC sproti oddajale v klasirnico. DNKL je bil osnova za komprimiran prepis vnesenih nalogov na nivoju paketa in škatle na poseben del diska. Ko je bil ta prepis končan, se je v DEFILE lahko zbrisalo že prepisane pakete PP, se s tem sprostilo prostor in hkrati povečalo možno hitrost vnosa, ker sistem ni bil več toliko obremenjen z izračunavanjem še razpoložljivega praznega prostora. Iz tega dela diska so se paketi PP s posebnimi programi na nivoju škatle prepisali na diskete (BACDI) ali trak (BACTR). V praksi se je v glavnem prepisovalo na diskete, ker je bilo “fizično lažje” rokovati s 4 do 5 disketami kot pa prenašati najmanjši magnetni trak, pa še tračna enota na S/1 ni bila med najzanesljivejšimi. Diskete oziroma trak so se naprej obdelovali na centralnem sistemu. Ker so bili podatki praktično čisti ni bilo potrebno veliko dodatnih popravkov in kjer je bila organizacija obdelave postavljena tako se je lahko pristopilo k izdelavi kontrolnih konsignacij, zbirnih aviz in zaključku dneva.
SDK Ljubljana je kontrolne konsignacije izdelovala na posameznih obdelovalnih mestih, kjer se je po končanem prvem delu vnosa na S/1 iztiskalo kontrolne konsignacije za prvo škatlo in po končanem kompletnem vnosu še konsignacije za drugo škatlo. Tiskanje je bilo dokaj hitro, saj se nikjer ni tiskalo nepotrebnih levih ničel. Na koncu se je lahko iztiskalo še zbirne avize. Tiskanje ZA se je kasneje v praksi uporabljalo v ekspozituri Domžale, kjer je bila kompletna obdelava narejena na S/1, ker je podružnica Ljubljana nabavila odpisano S/1 iz Beograda, ko je ta prešel na uporabo drugačnih računalnikov in tehnologije. Po končanem dnevnem delu na S/1 se je lahko stiskala še OPSTATS - operaterska statistika. V tem paketu so bili podatki o delu posameznega operaterja: katere vrste posla je vnašal, od kdaj do kdaj je vnašal, število vnesenih slogov, hitrost pisanja, nedelovni čas. Ta paket je bil nekaj časa osnova za dodatno stimulativno nagrajevanje operaterk. To idejo je kasneje nekdo iz SDK Centrale v Ljubljani hotel nekako prenesti na PC-je, vendar brezuspešno.
Zahtevki za vnos posameznih vrst posla so se stalno dopolnjevali in vnosni programi so počasi postajali vse kompleksnejši, prav tako pa so se pojavili zahtevki za popolnoma nove vrste poslov in na nekaterih S/1, ki so imele veliko vnosnih terminalov se je pojavil problem nezmožnosti hkratnega vnosa več različnih poslov ali pa tudi nezmožnost vnosa enega posla na vse terminale. Pojavil se je problem pomanjkanja spomina. Tako se je nekje poleti-jeseni leta 1984 dokupil dodatni spomin po 128 KB za vsak sistem. Po instalaciji dodatnega spomina je je prerazporedilo vnosne terminale na IDES in IDES2 ter vsakemu dodelil 56 KB spomina. Občasno se je sicer kateri od sistemov (parity check) obesil, ker se nikakor nismo mogli dogovoriti za potrebno ponovno generacijo sistemov zaradi razširitve. Stvar je bila nekako pokrpana in delovala, vendar ne s polno zanesljivostjo. V tem času je bil tudi že v polnem razmahu TK način prenosa podatkov in podatki, ki so se vnašali so imeli že tako obliko kot današnji nalogi PP, torej je bilo iz naloga potrebno prepisati bistveno več podatkov, kar je upočasnilo vnos. IBM ni več vzdrževal operacijskega sistema CPS. Intertrade oziroma Center Za Razvoj Programske Opreme (CZRPO) je začel ponujati IBM operacijski sistem EDX – Event Driven eXecutive. Imel je programski jezik EDL (Event Driven Language), ki je bil boljši (naprednejši) od assemblerja v CPS. EDX je imel vgrajen tudi IDES z nekaj več možnostmi kot IDES v CPS. CZRPO je kasneje ta IDES predelal, poslovenil maske (morda prevedel tudi v druge jezike) in ga skupaj z EDX lansiral pod imenom VESNA. Leta so tekla in pojavljal se je vedno večji zahtevek po masivnejšem TK vnosu. Ker programov za vnos TK zaradi preobsežnosti ni bilo možno izdelati v IDESu pod CPS je padla odločitev o nakupu EDX in VESNE. Programiranje vnosnih programov z znanjem in izkušnjami v IDESU ni delalo posebnih težav in tako je v začetku leta 1987 Beograd, ki je moral kot prvi preiti na EDX s predelavami in pisanjem vseh programov, ki so bili napisani za IDES v VESNO. Prav tako se je pričelo s pisanjem popolnoma novega programa TK za vnos z vsemi elementi, ki jih imajo današnji nalogi PP. Zelo težaško delo, ker sta bila EDX in VESNA dokaj nestabilna sistema, imela sta še polno hroščev, tako da sta se dostikrat obesila iz neznanih razlogov. Kasneje po predelavi vseh vnosnih programom v VESNO, se je v podružnici Kranj instaliral EDX, v Domžalah pa je delovala S/1 iz Beograda. V Domžalah smo tudi preizkušali program VIVA, ki naj bi omogočal komuniciranje po telefonskih linijah s S/1 in IBM mainframe računalnikom v Ljubljani. Ti poizkusi so bili žal brezuspešni, saj nikakor nismo uspeli prenesti podatkov v celoti, ker se je vse skupaj stalno sesuvalo in S/1 se je ustavljala iz nam neznanih razlogov, tehnične podpore s strani CZRPO pa ni bilo več. IBM je tudi prenehal z izdelavo S/1 in občasno so se začeli pojavljati še problemi z rezervnimi deli. CZRPO je tudi razvil neko emulacijo EDX in VESNE za PC-je, kjer naj bi se na posamezen PC, ki bi deloval kot S/1 pod EDX priključilo do 4 vnosne terminale za vnos podatkov v VESNI. V tem času so postajali PC-ji boljši, cenejši in dostopnejši, tako je tudi CZRPO počasi opustil nadaljnje vzdrževanje in razvijanje programja za S/1. Opustil je tudi že dokaj razvit projekt STILIST, ki je bil nekak pisalni stroj in predhodnik PC-PISA na PC-jih (WordStar) in naj bi deloval na S/1.
Po znanih podatkih je bila S/1 večnamenska, saj je lahko s pomočjo različnih priključnih kartic krmilila tudi posamezne stroje. Tako so imeli S/1 instalirane tudi v železarni Jesenice za krmiljenje delovnih procesov in od njih je podružnica Ljubljana nameravala kupiti novo (po letih staro) še originalno zapakirano S/1. Do nakupa ni prišlo, prišlo pa je do nakupa zelo rabljene S/1 iz SDK Beograd s 512 KB delovnega spomina, 64 MB diskom, kvalitetno tračno enoto in zelo hitrim igličnim tiskalnikom. To je bil za tiste čase primeren nakup, saj je s sistemom skupaj prišel originalno instaliran EDX in VESNA. Koliko in v kakšne namene je S/1 uporabljalo podjetje Elektro Ljubljana ni znano. Prev tako ni znano, če so bili še kakšni drugi uporabniki teh sistemov. Žal tudi ni podatka kdaj se je nekdanja SDK dokončno poslovila od teh sistemov in v celoti prešla na delo z osebnimi računalniki.
S/1 je bila vsem uporabnikom v SDK dober primer, kako se tudi na manj zmogljivem računalniku lahko veliko naredi in, da je dobro služila svojemu namenu do konca svoje življenjske dobe, ki je bila v primerjavi z modernimi osebnimi računalniki kar dolga!
Maj 2002
