SVM | |
---|---|
Kehittäjä | IBM , NIIEVM |
OS-perhe | VM |
Ytimen tyyppi | Virtuaalikone |
Lisenssi | Omistusoikeus |
Osavaltio | historiallinen |
Virtuaalikonejärjestelmä ( SVM ) on EU-tietokoneen käyttöjärjestelmä , IBM VM -järjestelmän analogi .
VM (VM ja sen varhainen versio CP / CMS) on ensimmäinen järjestelmä, jossa virtuaalikoneen tekniikka otettiin käyttöön . Virtualisointi CBM:ssä oli johdonmukaista ja täydellistä, erityisesti virtuaalikone pystyi ajamaan toista kopiota CBM-järjestelmästä ja niin edelleen. Lisäksi CBM:n suorittaminen CBM-virtuaalikoneessa oli suositeltu tapa luoda järjestelmästä uusi versio asennusta varten. Tämä tarkoitti erityisesti sitä, että mikä tahansa todellinen tietokonelaite voidaan esittää tavalla tai toisella virtuaalilaitteena virtuaalikoneen. Toistaiseksi millään muulla virtuaalikoneiden toteutuksella ei ole tätä ominaisuutta.
Sosialistisen leirin virtuaalikoneiden järjestelmän muokkasi ensin versiossa 1 Robotron -yritys (GDR) ja sitten versiosta 2 alkaen NIIEVM (Minsk). NIIEVM:n toiminnan ansiosta SVM:tä pidettiin Neuvostoliitossa yhtenä ES:n tietokonejärjestelmäohjelmiston pääkomponenteista, ja siitä tuli myöhemmin perusta ES OS:n versiolle 7 , jota tarjottiin vakiovaihtoehtona käytettäväksi ES:ssä. tietokonejärjestelmät Ryad-3 ja uudemmat. Neuvostoliitossa levinneimpiä olivat SVM 3:n ja 4:n versiot. Versio 5 julkaistiin jo Neuvostoliiton romahtamisen ja ES-tietokonelaitteiden käytön massiivisen luopumisen aikana, joten sitä ei käytetty laajalti ja nimellä "SVM version 6" Minskin asiantuntijat julkaisivat VM:lle paketin, joka tarjoaa maksimaalisen yhteensopivuuden VM-sovellusten kanssa.
Toisaalta syistä, joille ei ole rationaalista selitystä, IBM ei ole koskaan rohkaissut käyttämään VM-käyttöjärjestelmäänsä, ja IBM-markkinointi on aina asettanut VM:n toissijaiseen rooliin suhteessa muihin keskuskonekäyttöjärjestelmiin - MVS, OS. ja jopa DOS, paljon vähemmän teknisesti edistynyt ja käyttäjäystävällinen. Todennäköisesti alhainen budjetti VM:n kehittämiseen alkuperäisenä kokeellisena projektina ei antanut IBM:n taloushallinnolle mahdollista tunnustaa sitä yhtäläiseksi niiden järjestelmien kanssa, joihin käytettiin paljon enemmän rahaa.
Arkkitehtonisesti SVM koostui useista itsenäisistä komponenteista. Keskeinen komponentti oli virtuaalikoneen monitori (VMM, IBM:n nimi on CP, Control Program), joka ohjasi oikean tietokoneen laitteistoa ja toteutti joukon virtuaalikoneita tietyllä konfiguraatiolla. Loput komponentit olivat käyttöjärjestelmiä tai MVM:n ohjaamana toimivien virtuaalikoneiden järjestelmästä riippumattomia ohjelmia: dialoginkäsittelyalijärjestelmä (PDO), verkkotiedostonsiirtoalijärjestelmä (NFT), tilaaja-aseman looginen kytkentäalijärjestelmä (PLC), dump-analyysialijärjestelmä (PAD), kaukosäätimen alijärjestelmän tiedostonsiirto (PDP), laitteiston ohjausalijärjestelmä (PKT), tuotanto- ja ylläpitotyökalut (SSS).
PDO (Conversational Processing Subsystem, IBM-nimi - CMS , Conversational Monitor System, entinen Cambridge Monitor System; käänteinen käännös englanniksi - PTS, Programming and Testing System) oli CBM:n virtuaalikoneen pääkäyttöjärjestelmä, jossa käyttäjät työskentelivät. PDO tarjosi käyttäjälle dialogiliittymän, itse asiassa käyttäjän työ terminaalissa PDO:lla virtuaalikoneessa muistutti työtä henkilökohtaisella tietokoneella. Tämä oli erittäin vakava askel eteenpäin verrattuna ES-tietokoneiden aikaisempiin käyttöjärjestelmiin, joiden dialogiominaisuudet joko puuttuivat kokonaan tai olivat hyvin rajallisia.
Alijärjestelmät PSP, PLC, PAD, PDP, PKT, SGO oli tarkoitettu järjestelmän ylläpitotehtäviin, eivätkä sovellusohjelmoijat ja käyttäjät käyttäneet niitä.
Lisäksi CBM-virtuaalikoneessa oli mahdollista käyttää mitä tahansa ES-tietokoneen käyttöjärjestelmää, joka oli suunniteltu toimimaan todellisella laitteistolla (ns. vieraskäyttöjärjestelmä) - ES OS, ES DOS, ES MOS, MVS jne. Osana ES OS versio 7, erityinen BOS-käyttöjärjestelmä kehitettiin, joka vastaa toiminnallisesti EU:n versiota 6 (SVS), mutta suunniteltu erityisesti toimimaan SVM-virtuaalikoneessa. BOS, toisin kuin suurin osa muista ES-tietokonejärjestelmätyökaluista, oli neuvostoliiton ohjelmoijien itsenäinen kehitystyö, riippumaton IBM:stä. Koska EU-käyttöjärjestelmä oli eräjärjestelmä, PDO-käyttäjät saattoivat siirtää siihen valmiita tehtäväpaketteja ja saada tuloksia virtuaalisen rei'itysohjelman ja virtuaalisen ADCP :n avulla .
Virtual Machine Monitor pystyi teoriassa tukemaan jopa 10 000 virtuaalikonetta yhdessä todellisessa järjestelmässä. Käytännössä samanaikaisesti aktiivisten virtuaalikoneiden määrää rajoitti tietokoneen suorituskyky ja se voi olla useita kymmeniä.
EC Ryad-3:ssa ja sitä uudemmissa tietokoneissa toteutettiin SVM:n mikroohjelmatuki.
SVM:n arkkitehtuuri mahdollisti luonnollisesti tietokoneajan käytön kirjanpidon järjestämisen, mikä oli erittäin tärkeää kalliille monikäyttäjäjärjestelmille. Virtuaalikoneen käyttäjän käytettävissä oleva MVM-komento Q UERY T TIME mahdollisti nykyisen päivämäärän ja kellonajan sekä nykyisessä istunnossa käytettyjen todellisten ja virtuaalisten prosessorien prosessoriajan kokonaismäärän. virtuaalikone. Yksinkertainen REXX -kielinen kirjoitus oli suosittu , joka järjestelmästä poistuessaan antoi tällaisen komennon, kertoi saadun tuloksen järjestelmän koneajan hinnalla ja ilmoitti käyttäjälle kokonaissumman, jonka hänen työnsä maksoi toimivalle organisaatiolle. tietokone. Ohjelmoijalle, joka ei käyttänyt prosessoria intensiivisellä laskennalla, vaan suoritti tavanomaista ohjelmien kehitystä ja virheenkorjausta, EU-1066:ssa tyypillinen koneajan hinta oli noin 10 ruplaa työpäivää kohti (eli se oli suunnilleen yhtä suuri kuin palkat). Resurssiintensiiviset ohjelmat käytön aikana voivat käyttää suuruusluokkaa enemmän prosessoriaikaa. Neuvostoliiton ohjelmoijat eivät tietenkään maksaneet koneajastaan omasta taskustaan, mutta tämä luku osoittaa, että ohjelmoijien työ koodin optimoinnissa kannatti tuolloin hyvin nopeasti.
EU OS:n ja BOS:n käyttömahdollisuuden lisäksi MVM:n hallinnassa itse SAN on suunniteltu siten, että ohjelmien siirtäminen EU-käyttöjärjestelmästä on mahdollisimman helppoa. EU OS -muodossa olevia levyjä oli mahdollista yhdistää PDO-virtuaalikoneeseen ja käynnistää suoraan EU-käyttöjärjestelmän käynnistysmoduulit erityisellä OSRUN- komennolla (tietyin rajoituksin käytettäville järjestelmäkutsuille). Lisäksi useimmat EU-käyttöjärjestelmän sovellukset voitiin yksinkertaisesti kääntää uudelleen PDO:lla saadakseen todellisia PDO-suoritustiedostoja. PDO-järjestelmäkutsut olivat maksimaalisesti yhteensopivia EU-käyttöjärjestelmän kanssa, suurin osa EU-tietokoneiden sovellusohjelmista oli kirjoitettu niiden yhteiselle osajoukolle ja niitä voitiin suorittaa sekä EU OS (ja MCS) -ympäristössä että PDO-ympäristössä.
Virtuaalimuistijärjestelmän tehokkaan käytön varmistamiseksi suunniteltiin varata osa osoiteavaruudesta järjestelmän ohjelmoijan pyynnöstä ns. jaetuille segmenteille. Esimerkiksi tekstieditori, kääntäjä tai ohjelmointikielen tukikirjasto voitaisiin ladata jaettuun segmenttiin, jolloin kaikki niitä käyttävät käyttäjät voisivat tehokkaasti käyttää samaa kopiota virtuaalimuistissa sen sijaan, että luotaisiin erillinen kopio jokaiselle virtuaalikoneelle.
Toisin kuin DOS ES, OS ES ja MVS, jotka tarjosivat erittäin hankalan ja hankalan tiedostonhallintajärjestelmän jokapäiväiseen käyttöön (tarkemmin sanottuna niiden terminologiassa tietojoukoissa), PDO otti käyttöön ns. minilevyjen konseptin, jolla on mahdollisuus käyttää oma tiedostojärjestelmä. Minilevy oli virtuaalinen levylaite, jota emuloi VMM. Minilevy voitiin alustaa PDO-tiedostojärjestelmässä, jolloin se sisälsi yhden tiedostohakemiston. Tiedostotunnus koostui tiedoston nimestä (enintään 8 merkkiä), tunnisteesta (enintään 8 merkkiä) ja tiedostotilasta (1 asemakirjain ja 1 käyttötilan numero). Nimen osat erotettiin välilyönnillä, tiedostotila voitiin jättää kokonaan pois tai vain aseman kirjain voitiin määrittää. Esimerkiksi tiedosto nimeltä PROFILE EXEC A1 on EXEC -tyyppinen PDO-järjestelmän käynnistystiedosto (jollakin komentosarjakielellä) pääkäyttäjän minilevyllä A tavallisella käyttötilalla 1 .
SAN-tiedostojen rakenne vastasi EU:n käyttöjärjestelmän tietokokonaisuuksien rakennetta (lukuun ottamatta monimutkaisimpia tietokokonaisuuksia), eli jokainen tiedosto oli jaettu tietyn muotoisiin ja pituisiin tietueisiin. Pääasiallinen SAN-tekstitiedostomuoto oli F(80) -muoto , eli kuva virtuaalisesta 80-sarakkeen reikäkorttipakasta .
Minilevyjä voitiin jakaa useiden virtuaalikoneiden kesken, joten minilevyt jaettiin järjestelmäohjelmien kanssa ja käyttäjillä oli pääsy toistensa tietoihin. Tarjottu salasanasuojaus minilevyille lukemista ja kirjoittamista varten.
Jotta PDO olisi yhteensopiva EU DOS:n, EU OS:n ja MBC:n kanssa, se käytti pääasiassa näistä järjestelmistä lainattua ulkoista tiedostojen yhdistämismekanismia. Vaikka SAN-ohjelma voisi avata levyllä olevan tiedoston suoraan nimellään, itse asiassa vain muutama järjestelmäohjelma, kuten tiedostoapuohjelmat, tekstieditori jne., oli järjestetty tällä tavalla. Sovellusohjelmien vakiomekanismi oli yhdistää levyllä (tai laitteessa) oleva tiedosto, jonka tiedostonimi on ohjelmassa käyttäen FI LEDEF -komentoa , joka on annettu ennen ohjelman suorittamista ( DOS-, OS- ja MBC -kielen JCL -kielen DD -käskyn analogi). Esimerkiksi komento FI LEDEF SYSPRINT DISK TEST LISTING tarkoitti, että seuraavien ohjelmien järjestelmälähtö ( SYSPRINT ) kirjoitetaan PDO-minilevyllä olevaan tiedostoon, jonka nimi on TEST LISTING (ja oletettu tila A1 ).
Katkosten ja lyhenteiden käyttö sallittiin useimmissa VMM-, PDO- ja järjestelmäohjelmien komennoissa sekä joissakin komentooperandeissa CBM:n vuorovaikutteisen työn helpottamiseksi. Esimerkiksi sana READER voidaan kirjoittaa yhdeksi lyhenteistä READER , READE , READ , REA , RE , R tai lyhenteenä RDR . Useammin käytetyissä komennoissa ja operandeissa oli lyhyemmät katkaisut, enintään yksi kirjain, harvemmin käytetyissä pitemmät. Syntaksikuvauksessa pakollinen osa lyhennyksestä kirjoitettiin isoilla kirjaimilla tai alleviivauksella, esim.: R READER | RDR .
CBM-versiosta 3 alkaen PDO käytti erittäin edistynyttä X EDIT -tekstieditoria , jota erityisesti REXX-kieli ohjasi täysin. XEDITin REXX-skriptien avulla toteutettiin monia monimutkaisia järjestelmiä, kuten esimerkiksi ohjelmien kollektiivisen versionhallinnan järjestelmiä. Myöhemmin XEDIT-kloonit (KEDIT, SEDIT, THE) toteutettiin erilaisissa henkilökohtaisten tietokoneiden käyttöjärjestelmissä, mutta ne eivät juuri juurtuneet, koska XEDIT-ideologia keskittyi suurelta osin keskuspäätelaitteiden ominaisuuksiin. THE (The Hessling Editor) on tällä hetkellä jaettu GPL :n alla Unix- , z/OS- , MS-DOS- , OS/2- , Windows- , QNX- , Amiga- , BeOS- ja Mac OS X -alustoille . Mielenkiintoista on, että IBM itse jakelee THE:n z/OS-version.
Osana suojattua alkuperänimitystä toimitettiin ohjelmia sähköpostin kanssa työskentelemiseen. Yleensä sähköposti toimi yhden oikean tietokoneen käyttäjien välillä (vanhemmissa EC-tietokoneissa tämä saattoi olla satoja käyttäjiä päätteissä useiden kilometrien säteellä), mutta käyttämällä tietoliikennettä, joka oli tuohon aikaan vielä uteliaisuutta, koneet voitaisiin liittää verkkoon. Lisäksi otettiin käyttöön järjestelmä lyhytsanomien välittömään välittämiseen käyttäjien välillä.
PDO:n tärkeimmät ohjelmointityökalut olivat REXX - skriptikielet ja aikaisemmat EXEC ja EXEC2 , PL/1 :n , Fortranin , Cobolin kokoajat , kääntäjät . Myös monia muita ohjelmointijärjestelmiä on toteutettu SAN:lle, kuten: Pascal , C , Lisp , Prolog , REDUCE symbolic computing system , teknologinen kieli järjestelmäohjelmiston kehittämiseen PLS (ohjelmointikieli) jne.
REXX-kielitulkki sisällytettiin ensimmäisen kerran CBM-version 3 SAN:iin. REXX-kieli yleistyi sittemmin OS/2 -käyttöjärjestelmässä ja otettiin käyttöön myös monissa muissa käyttöjärjestelmissä. CVM:ssä REXX:n suosio käyttäjien keskuudessa oli rajallisempaa kuin OS/2:ssa, koska PDO:n aiempien versioiden komentosarjakieli EXEC2 tarjosi varsin runsaasti mahdollisuuksia ja tarve käyttää monimutkaisempaa REXX-kieltä ilmaantui harvemmin. OS/2:ssa ainoa vaihtoehto REXX:lle oli erittäin rajoitettu .bat /.cmd-tiedostokieli.