| SVM | |
|---|---|
| Dezvoltator | IBM , NIIEVM |
| Familia OS | VM |
| Tipul de kernel | Mașină virtuală |
| Licență | Proprietate |
| Stat | istoric |
Sistemul de mașini virtuale ( SVM ) este un sistem de operare pentru computerul UE , un analog al sistemului IBM VM .
VM (VM și versiunea sa inițială CP/CMS) este primul sistem în care a fost implementată tehnologia mașinilor virtuale . Virtualizarea în CBM a fost consecventă și completă, în special, o mașină virtuală putea rula o altă copie a sistemului CBM și așa mai departe. Mai mult, rularea CBM pe o mașină virtuală CBM a fost metoda recomandată pentru generarea unei noi versiuni a sistemului pentru instalare. În special, aceasta însemna că orice dispozitiv computerizat real poate fi reprezentat printr-o metodă sau alta ca un dispozitiv virtual pe o mașină virtuală. Până acum, nicio altă implementare a mașinilor virtuale nu are această proprietate.
Sistemul de mașini virtuale din tabăra socialistă a fost adaptat mai întâi în versiunea 1 de către întreprinderea Robotron (GDR), iar apoi, din versiunea 2, dezvoltat de NIIEVM (Minsk). Datorită activității NIIEVM, SVM a fost considerat în URSS ca una dintre componentele principale ale software-ului sistemului informatic ES și ulterior a devenit baza pentru versiunea 7 a ES OS , care a fost oferită ca opțiune standard pentru utilizare pe ES. sisteme informatice Ryad-3 și mai mari. Cele mai răspândite în URSS au fost versiunile SVM 3 și 4. Versiunea 5 a fost lansată deja în timpul prăbușirii URSS și a abandonării masive a utilizării echipamentelor informatice ES și, prin urmare, nu a fost utilizată pe scară largă și sub numele de „SVM versiunea 6" Specialiștii de la Minsk au lansat un pachet de programe pentru VM, oferind compatibilitatea maximă a acestuia cu aplicațiile VM.
Pe de altă parte, din motive care nu au o explicație rațională, IBM nu a încurajat niciodată utilizarea sistemului său de operare VM, iar VM-ul a fost întotdeauna poziționat de marketingul IBM într-un rol secundar în raport cu alte sisteme de operare mainframe - MVS, OS și chiar DOS, mult mai puțin avansat din punct de vedere tehnologic și ușor de utilizat. Cel mai probabil, bugetul mic pentru dezvoltarea VM ca proiect experimental inițial nu a permis managementului financiar al IBM să-l recunoască ca fiind egal cu acele sisteme pentru care s-au cheltuit mult mai mulți bani.
Din punct de vedere arhitectural, SVM a constat din mai multe componente independente. Componenta centrală era monitorul mașinii virtuale (VMM, numele IBM este CP, Control Program), care controla hardware-ul unui computer real și implementa un set de mașini virtuale cu o anumită configurație. Componentele rămase au fost sisteme de operare sau programe independente de sistem ale mașinilor virtuale care rulează sub controlul MVM: subsistemul de procesare a dialogurilor (PDO), subsistemul de transfer de fișiere în rețea (NFT), subsistemul de comutare logică a stației de abonat (PLC), subsistemul de analiză de descărcare (PAD), transferul de fișiere subsistem de control la distanță (PDP), subsistemul de control hardware (PKT), instrumente de generare și întreținere (SSS).
PDO (Conversational Processing Subsystem, nume IBM - CMS , Conversational Monitor System, anterior Cambridge Monitor System; traducere inversă în engleză - PTS, Programming and Testing System) a fost principalul sistem de operare al mașinii virtuale din CBM, în care lucrau utilizatorii. PDO a oferit utilizatorului o interfață de dialog, de fapt, munca utilizatorului la terminalul în PDO pe o mașină virtuală semăna cu munca pe un computer personal. Acesta a fost un pas înainte foarte serios în comparație cu sistemele de operare anterioare ale computerelor ES, ale căror capacități de dialog erau fie complet absente, fie foarte limitate.
Subsistemele PSP, PLC, PAD, PDP, PKT, SGO au fost destinate sarcinilor de întreținere a sistemului și nu au fost utilizate de programatorii și utilizatorii de aplicații.
În plus, pe mașina virtuală CBM a fost posibil să ruleze orice sistem de operare al computerului ES conceput să ruleze pe hardware real (așa-numitul sistem de operare invitat) - ES OS, ES DOS, ES MOS, MVS etc. ES OS versiunea 7, a fost dezvoltat un sistem de operare BOS special care este echivalent funcțional cu versiunea 6 (SVS) a UE, dar conceput special pentru a rula pe mașina virtuală SVM. BOS, spre deosebire de marea majoritate a altor instrumente ale sistemului informatic ES, a fost o dezvoltare independentă a programatorilor sovietici, independentă de IBM. Deoarece sistemul de operare UE era un sistem batch, utilizatorii PDO puteau transfera pachete de sarcini pregătite în acesta și obțineau rezultate folosind un perforator virtual și un ADCP virtual .
Virtual Machine Monitor a fost teoretic capabil să suporte până la 10.000 de mașini virtuale pe un singur sistem real. În practică, numărul de mașini virtuale active simultan era limitat de performanța computerului și putea ajunge la câteva zeci.
În EC Ryad-3 și în computerele superioare, au fost implementate mijloacele de suport pentru microprograme pentru SVM.
Arhitectura SVM-ului a făcut posibilă organizarea naturală a contabilității utilizării timpului computerului, ceea ce era foarte important pentru sistemele multi-utilizator care erau costisitoare de operat. Comanda MVM Q UERY T IME , disponibilă utilizatorului mașinii virtuale, a făcut posibilă aflarea datei și orei curente, precum și a duratei totale de procesare a procesoarelor reale și virtuale utilizate în sesiunea curentă a mașina virtuală. A fost popular un script simplu în limbajul REXX , care, la ieșirea din sistem, a emis o astfel de comandă, a înmulțit rezultatul obținut cu costul timpului mașinii sistemului și a informat utilizatorul cu privire la suma totală pe care o costă munca sa pentru organizația care operează. calculatorul. Pentru un programator care nu a ocupat procesorul cu calcule intensive, dar a efectuat dezvoltarea și depanarea obișnuite a programelor, pe EU-1066 costul tipic al mașinii a fost de aproximativ 10 ruble pe zi lucrătoare (adică a fost aproximativ egal cu salariile). Programele care consumă mult resurse în timpul funcționării ar putea folosi timp de procesor cu mult mai mult. Desigur, programatorii din URSS nu plăteau pentru timpul mașinii din propriul buzunar, dar această cifră arată că munca programatorilor în optimizarea codului a dat roade foarte repede la acel moment.
Pe lângă posibilitatea utilizării EU OS și BOS sub controlul MVM, PDO-ul în sine a fost conceput astfel încât să fie cât mai ușor posibil transferul de programe din EU OS. A fost posibil să se conecteze discuri în format EU OS la mașina virtuală PDO și să lanseze direct modulele de boot ale EU OS cu o comandă specială OSRUN (cu anumite restricții privind apelurile de sistem utilizate). În plus, majoritatea aplicațiilor pentru sistemul de operare UE ar putea fi pur și simplu recompilate sub PDO pentru a obține executabile PDO reale. Apelurile de sistem PDO erau maxim compatibile cu EU OS, majoritatea programelor de aplicație pentru computerele UE au fost scrise pe subsetul lor comun și puteau fi executate atât în mediul EU OS (și MCS), cât și în mediul PDO.
Pentru a asigura utilizarea eficientă a sistemului de memorie virtuală, s-a avut în vedere alocarea unei părți din spațiul de adrese, la solicitarea programatorului de sistem, pentru așa-numitele segmente partajate. De exemplu, un editor de text, un compilator sau o bibliotecă de suport pentru limbajul de programare ar putea fi încărcat într-un segment partajat și astfel toți utilizatorii care le folosesc ar putea accesa efectiv aceeași copie în memoria virtuală, în loc să creeze o copie separată pentru fiecare mașină virtuală.
Spre deosebire de DOS ES, OS ES și MVS, care au oferit un sistem de gestionare a fișierelor foarte greoi și incomod pentru uzul de zi cu zi (mai precis, în terminologia lor, seturi de date), PDO a implementat conceptul de așa-numitele mini-discuri cu capacitatea de a utiliza propriul sistem de fișiere. Minidiscul era un dispozitiv de disc virtual emulat de un VMM. Mini-discul putea fi formatat în sistemul de fișiere PDO, caz în care conținea un singur director de fișiere. ID-ul fișierului a constat din numele fișierului (până la 8 caractere), extensia (până la 8 caractere) și modul fișier (1 literă de unitate și 1 cifră pentru modul de acces). Componentele numelui erau separate printr-un spațiu, modul fișier putea fi omis în întregime sau putea fi specificată doar litera unității. De exemplu, un fișier numit PROFILE EXEC A1 este un fișier de pornire a sistemului PDO de tip EXEC (într-unul dintre limbajele de scriptare) pe mini-discul A al utilizatorului principal , cu modul de acces obișnuit 1 .
Structura fișierelor PDO corespundea structurii seturilor de date EU OS (cu excepția celor mai complexe tipuri de seturi de date), adică fiecare fișier a fost împărțit în înregistrări de un anumit format și lungime. Principalul format de fișier text din PDO a fost formatul F(80) , adică imaginea unui pachet virtual de cărți perforate cu 80 de coloane .
Mini-discurile puteau fi partajate între mai multe mașini virtuale, astfel încât mini-discurile erau partajate cu programele de sistem și utilizatorii aveau acces la datele celuilalt. Oferă protecție prin parolă pentru mini-discuri pentru citire și scriere.
Pentru a fi compatibil cu EU DOS, EU OS și MBC, PDO a folosit în principal mecanismul extern de asociere a fișierelor împrumutat de la aceste sisteme. Deși un program din PDO putea deschide un fișier de pe un disc direct după numele său, de fapt, doar câteva programe de sistem, cum ar fi utilitare de fișiere, un editor de text etc., au fost aranjate în acest fel. Mecanismul standard pentru programele de aplicație era asocierea un fișier de pe un disc (sau dispozitiv) cu un nume de fișier în program folosind comanda FI LEDEF emisă înainte ca programul să fie executat (un analog al instrucțiunii DD în limbajul JCL pentru DOS, OS și MBC). De exemplu, comanda FI LEDEF SYSPRINT DISK TEST LISTING a însemnat că ieșirea sistemului ( SYSPRINT ) a următoarelor programe ar trebui să fie scrisă într-un fișier de pe minidiscul PDO cu numele TEST LISTING (și modul implicit A1 ).
Trunchieri și abrevieri au fost permise să fie utilizate în majoritatea comenzilor VMM, PDO și programelor de sistem, precum și în unele operanzi de comandă, pentru confortul lucrului interactiv în CBM. De exemplu, cuvântul READER ar putea fi introdus ca una dintre abrevierile READER , READE , READ , REA , RE , R sau ca abreviere RDR . Comenzile și operanzii folosiți mai des aveau trunchieri mai scurte, până la o literă, cele mai rar utilizate aveau altele mai lungi. În descrierea sintaxei, partea obligatorie a trunchierii a fost scrisă cu majuscule sau subliniată, de exemplu: R EADER | RDR .
Începând cu versiunea 3 a CBM, PDO a folosit un editor de text X EDIT foarte avansat , care, în special, era complet controlat de limbajul REXX. Cu ajutorul scripturilor REXX pentru XEDIT, au fost implementate multe sisteme complexe, cum ar fi, de exemplu, sisteme pentru controlul colectiv al versiunilor de programe. Ulterior, clonele XEDIT (KEDIT, SEDIT, THE) au fost implementate în diverse sisteme de operare pentru computere personale, dar nu au prins cu adevărat rădăcini, deoarece ideologia XEDIT era concentrată în mare măsură pe caracteristicile terminalului mainframe. THE (Editorul Hessling) este distribuit în prezent sub GPL pentru platformele Unix , z/OS , MS-DOS , OS/2 , Windows , QNX , Amiga , BeOS , Mac OS X . Interesant este că versiunea z/OS a THE este distribuită chiar de IBM.
În cadrul DOP au fost furnizate programe de lucru cu e-mailul. De obicei, e-mailul funcționa între utilizatorii unui singur computer real (pentru modelele mai vechi de computere EC, acestea puteau fi sute de utilizatori la terminale pe o rază de câțiva kilometri), dar folosind telecomunicații, care erau încă o curiozitate în acele vremuri, diverse mașinile ar putea fi conectate în rețea. De asemenea, a fost implementat un sistem de transmitere instantanee a mesajelor scurte între utilizatori.
Principalele instrumente de programare pentru PDO au fost limbaje de scripting REXX și anterioare EXEC și EXEC2 , asamblatoare , compilatoare de la PL/1 , Fortran , Cobol . De asemenea, pentru PDO au fost implementate multe alte sisteme de programare, precum: Pascal , C , Lisp , Prolog , REDUCE sistem de calcul simbolic , limbaj tehnologic pentru dezvoltarea software-ului de sistem PLS (limbaj de programare) etc.
Interpretul de limbaj REXX a fost inclus pentru prima dată în PDO în versiunea CBM 3. Limbajul REXX a devenit ulterior răspândit în sistemul de operare OS/2 și a fost implementat și pentru multe alte sisteme de operare. În CVM, popularitatea REXX în rândul utilizatorilor a fost mai limitată decât în OS/2, deoarece limbajul de scriptare al versiunilor anterioare de PDO, EXEC2, a oferit oportunități destul de ample, iar nevoia de a utiliza limbajul REXX mai complex a apărut mai rar, în timp ce în OS/2 singura alternativă la REXX a fost limbajul extrem de limitat al fișierelor .bat /.cmd.