| SVM | |
|---|---|
| Udvikler | IBM , NIIEVM |
| OS familie | VM |
| Kernel type | Virtuel maskine |
| Licens | Proprietære |
| Stat | historisk |
Det virtuelle maskinsystem ( SVM ) er et operativsystem til EU-computeren , en analog af IBM VM -systemet .
VM (VM, og dens tidlige version CP/CMS) er det første system, hvori den virtuelle maskine- teknologi blev implementeret . Virtualisering i CBM var konsekvent og komplet, især en virtuel maskine kunne køre en anden kopi af CBM-systemet, og så videre. Desuden var det at køre CBM på en CBM virtuel maskine den anbefalede metode til at generere en ny version af systemet til installation. Dette betød især, at enhver rigtig computerenhed kunne repræsenteres ved en eller anden metode som en virtuel enhed på en virtuel maskine. Indtil videre har ingen anden implementering af virtuelle maskiner denne egenskab.
Systemet med virtuelle maskiner i den socialistiske lejr blev først tilpasset i version 1 af Robotron enterprise (DDR), og derefter, fra version 2, udviklet af NIIEVM (Minsk). Takket være NIIEVM's aktivitet blev SVM betragtet i USSR som en af hovedkomponenterne i ES-computersystemsoftwaren og blev efterfølgende grundlaget for version 7 af ES OS , der blev tilbudt som en standardmulighed til brug på ES computersystemer Ryad-3 og højere. Den mest udbredte i USSR var versioner af SVM 3 og 4. Version 5 blev frigivet allerede under USSR's sammenbrud og den massive opgivelse af brugen af ES-computerudstyr, og blev derfor ikke meget brugt, og under navnet "SVM version 6" Minsk-specialister udgav en pakkeprogrammer til VM, der giver dens maksimale kompatibilitet med VM-applikationer.
På den anden side har IBM af årsager, der ikke har nogen rationel forklaring, aldrig opfordret til brugen af sit VM-operativsystem, og VM'en har altid været placeret af IBM-marketing i en sekundær rolle i forhold til andre mainframe-operativsystemer - MVS, OS og endda DOS, meget mindre teknologisk avanceret og brugervenligt. Det lave budget for udviklingen af VM'en som et indledende eksperimentelt projekt tillod højst sandsynligt ikke IBM's økonomistyring at anerkende det som lig med de systemer, hvor der blev brugt meget flere penge.
Arkitektonisk bestod SVM af flere uafhængige komponenter. Den centrale komponent var den virtuelle maskine monitor (VMM, IBM's navn er CP, Control Program), som styrede hardwaren på en rigtig computer og implementerede et sæt virtuelle maskiner med en given konfiguration. De resterende komponenter var operativsystemer eller systemuafhængige programmer af virtuelle maskiner, der kørte under kontrol af MVM: dialogbehandlingsundersystemet (PDO), netværksfiloverførselsundersystemet (NFT), abonnentstationens logiske koblingsundersystem (PLC), dump analyse undersystem (PAD), fjernstyring undersystem filoverførsel (PDP), hardware kontrol undersystem (PKT), generation og vedligeholdelse værktøjer (SSS).
PDO (Conversational Processing Subsystem, IBM-navn - CMS , Conversational Monitor System, tidligere Cambridge Monitor System; omvendt oversættelse til engelsk - PTS, Programming and Testing System) var hovedoperativsystemet for den virtuelle maskine i CBM, som brugerne arbejdede i. PDO gav brugeren en dialoggrænseflade, faktisk lignede brugerens arbejde ved terminalen i PDO på en virtuel maskine arbejde på en personlig computer. Dette var et meget alvorligt skridt fremad i sammenligning med de tidligere operativsystemer på ES-computere, hvis dialogmuligheder enten var fuldstændig fraværende eller var meget begrænsede.
Undersystemerne PSP, PLC, PAD, PDP, PKT, SGO var beregnet til systemvedligeholdelsesopgaver og blev ikke brugt af applikationsprogrammører og brugere.
Derudover var det på den virtuelle CBM-maskine muligt at køre et hvilket som helst ES-computeroperativsystem designet til at køre på rigtig hardware (det såkaldte gæste-OS) - ES OS, ES DOS, ES MOS, MVS osv. Som en del af ES OS version 7, et særligt BOS-operativsystem blev udviklet, der funktionelt svarer til version 6 (SVS) af EU, men designet specifikt til at køre på den virtuelle SVM-maskine. BOS var, i modsætning til langt de fleste andre ES-computersystemværktøjer, en uafhængig udvikling af sovjetiske programmører, uafhængig af IBM. Da EU OS var et batchsystem, kunne PDO-brugere overføre forberedte opgavepakker til det og få resultater ved hjælp af en virtuel puncher og en virtuel ADCP .
Virtual Machine Monitor var teoretisk i stand til at understøtte op til 10.000 virtuelle maskiner på et enkelt rigtigt system. I praksis var antallet af samtidig aktive virtuelle maskiner begrænset af computerens ydeevne og kunne nå op på flere tiere.
I EC Ryad-3 og højere computere blev midlerne til mikroprogramstøtte til SVM implementeret.
Arkitekturen i SVM gjorde det muligt naturligt at organisere regnskabet over brugen af computertid, hvilket var meget vigtigt for flerbrugersystemer, der var dyre i drift. MVM-kommandoen Q UERY T IME , tilgængelig for brugeren af den virtuelle maskine, gjorde det muligt at finde ud af den aktuelle dato og klokkeslæt samt den samlede mængde processortid for de rigtige og virtuelle processorer, der blev brugt i den aktuelle session af den virtuelle maskine. Et simpelt script på REXX -sproget var populært , som, når man forlod systemet, udstedte en sådan kommando, multiplicerede resultatet opnået med omkostningerne ved systemets maskintid og informerede brugeren om det samlede beløb, som hans arbejde kostede for den organisation, der opererede computeren. For en programmør, der ikke optog processoren med intensive beregninger, men udførte den sædvanlige udvikling og fejlretning af programmer, på EU-1066 var de typiske omkostninger for maskintid omkring 10 rubler pr. arbejdsdag (det vil sige, det var omtrent lig med løn). Ressourcekrævende programmer under drift kunne bruge størrelsesordener mere processortid. Selvfølgelig betalte programmører i USSR ikke for maskintid af egen lomme, men denne figur viser, at programmørers arbejde med kodeoptimering betalte sig meget hurtigt på det tidspunkt.
Ud over muligheden for at bruge EU OS og BOS under kontrol af MVM, var selve PDO'en designet på en sådan måde, at det blev så let som muligt at overføre programmer fra EU OS. Det var muligt at forbinde diske i EU OS-formatet til den virtuelle PDO-maskine og direkte starte EU OS'ets opstartsmoduler med en speciel OSRUN- kommando (med visse begrænsninger for de anvendte systemkald). Derudover kunne de fleste applikationer til EU OS simpelthen genkompileres under PDO for at få rigtige PDO-eksekverbare filer. PDO-systemopkald var maksimalt kompatible med EU OS, de fleste af applikationsprogrammerne til EU-computere blev skrevet på deres fælles undersæt og kunne udføres både i EU OS (og MCS) miljøet og i PDO-miljøet.
For at sikre en effektiv udnyttelse af det virtuelle hukommelsessystem var det påtænkt at allokere en del af adresserummet efter anmodning fra systemprogrammøren til de såkaldte delte segmenter. For eksempel kunne en teksteditor, en compiler eller et programmeringssprog-understøttelsesbibliotek indlæses i et delt segment, og alle brugere, der bruger dem, vil således effektivt få adgang til den samme kopi i virtuel hukommelse, i stedet for at oprette en separat kopi for hver virtuel maskine.
I modsætning til DOS ES, OS ES og MVS, som leverede et meget besværligt og ubekvemt filhåndteringssystem til daglig brug (mere præcist, i deres terminologi, datasæt), implementerede PDO konceptet med såkaldte mini-diske med mulighed for at bruge sit eget filsystem. Minidisken var en virtuel diskenhed emuleret af en VMM. Mini-disken kunne formateres i PDO-filsystemet, i hvilket tilfælde den indeholdt en enkelt mappe med filer. Fil-id'et bestod af filnavnet (op til 8 tegn), udvidelse (op til 8 tegn) og filtilstand (1 drevbogstav og 1 ciffer i adgangstilstand). Navnets komponenter var adskilt af et mellemrum, filtilstanden kunne udelades helt, eller kun drevbogstavet kunne angives. For eksempel er en fil med navnet PROFIL EXEC A1 en PDO-systemstartfil af EXEC -typen (på et af scriptsprogene) på hovedbrugerens minidisk A , med den sædvanlige adgangstilstand 1 .
Strukturen af PDO-filerne svarede til strukturen af EU OS-datasættene (med undtagelse af de mest komplekse typer af datasæt), det vil sige, at hver fil blev opdelt i poster af et bestemt format og længde. Det primære tekstfilformat i PDO var F(80) -formatet , det vil sige billedet af et virtuelt kortspil med 80- søjlers hulkort .
Mini-diske kunne deles mellem flere virtuelle maskiner, så mini-diske blev delt med systemprogrammer og brugere havde adgang til hinandens data. Forsynet med adgangskodebeskyttelse til minidiske til læsning og skrivning.
For at være kompatibel med EU DOS, EU OS og MBC brugte BOB hovedsageligt den eksterne filassocieringsmekanisme, der var lånt fra disse systemer. Selvom et program i PDO kunne åbne en fil på en disk direkte ved sit navn, var der faktisk kun nogle få systemprogrammer, såsom filværktøjer, en teksteditor osv., der var arrangeret på denne måde.. Standardmekanismen for applikationsprogrammer var at tilknytte en fil på en disk (eller enhed) med et filnavn i programmet ved hjælp af FI LEDEF-kommandoen udstedt før programmet udføres (en analog til DD -sætningen i JCL -sproget for DOS, OS og MBC). For eksempel betød kommandoen FI LEDEF SYSPRINT DISK TEST LISTING , at systemoutputtet ( SYSPRINT ) af følgende programmer skulle skrives til en fil på PDO-minidisken med navnet TEST LISTING (og den underforståede tilstand A1 ).
Trunkeringer og forkortelser fik lov til at blive brugt i de fleste VMM-, PDO- og systemprogrammers kommandoer, såvel som i nogle kommandooperander, for at gøre det lettere for interaktivt arbejde i CBM. For eksempel kan ordet LÆSER indtastes som en af forkortelserne LÆSER , LÆS , LÆS , REA , RE , R eller som forkortelsen RDR . Oftere brugte kommandoer og operander havde kortere trunkering, op til et bogstav, mere sjældent brugte havde længere. I syntaksbeskrivelsen blev den obligatoriske del af trunkeringen skrevet med stort eller understreget, f.eks .: LÆSER | RDR .
Fra og med CBM version 3 brugte PDO en meget avanceret X EDIT -teksteditor , som især var fuldstændig styret af REXX-sproget. Ved hjælp af REXX scripts til XEDIT blev mange komplekse systemer implementeret, som for eksempel systemer til kollektiv versionskontrol af programmer. Efterfølgende blev XEDIT-kloner (KEDIT, SEDIT, THE) implementeret i forskellige pc-operativsystemer, men slog ikke rigtig rod, da XEDIT-ideologien i høj grad var fokuseret på mainframe-terminalfunktionerne. THE (The Hessling Editor) distribueres i øjeblikket under GPL til Unix , z/OS , MS-DOS , OS/2 , Windows , QNX , Amiga , BeOS , Mac OS X-platforme . Interessant nok distribueres z/OS-versionen af THE af IBM selv.
Som en del af PDO'en blev der leveret programmer til at arbejde med e-mail. Normalt fungerede e-mail mellem brugere af én rigtig computer (for ældre modeller af EC-computere kunne dette være hundredvis af brugere ved terminaler inden for en radius af flere kilometer), men ved hjælp af telekommunikation, som stadig var et kuriosum dengang, var der div. maskiner kunne forbindes i netværk. Et system til øjeblikkelig transmission af korte beskeder mellem brugere blev også implementeret.
De vigtigste programmeringsværktøjer til PDO var REXX scriptsprog og tidligere EXEC og EXEC2 , assemblers , compilere fra PL/1 , Fortran , Cobol . Der er også implementeret mange andre programmeringssystemer til PDO, såsom: Pascal , C , Lisp , Prolog , REDUCE symbolic computing system , teknologisk sprog til udvikling af systemsoftware PLS (programmeringssprog) osv.
REXX sprogtolken blev først inkluderet i PDO i CBM version 3. REXX sproget blev efterfølgende udbredt i OS/2 styresystemet og blev også implementeret til mange andre operativsystemer. I CVM var populariteten af REXX blandt brugerne mere begrænset end i OS/2, da scriptsproget i tidligere versioner af PDO, EXEC2, gav ret rige muligheder, og behovet for at bruge det mere komplekse REXX sprog opstod sjældnere, mens i OS/2 var det eneste alternativ til REXX det ekstremt begrænsede .bat /.cmd-filsprog.