Historik om IBM mainframe -operativsystemer - History of IBM mainframe operating systems

Den historie operativsystemer, der kører på IBM mainframes er en bemærkelsesværdig kapitel i historien om mainframe operativsystemer , på grund af IBM 's mangeårige position som verdens største hardware leverandør af mainframe-computere .

Formentlig har de operativsystemer, som IBM leverede til kunder til brug på sine tidlige mainframes, sjældent været meget innovative, undtagen de virtuelle maskinesystemer , der begyndte med CP-67 . Men virksomhedens velkendte ry for at foretrække gennemprøvet teknologi har generelt givet potentielle brugere tillid til at vedtage nye IBM-systemer ret hurtigt. IBMs nuværende mainframe -operativsystemer, z/OS , z/VM , z/VSE og z/TPF , er bagudkompatible efterfølgere af operativsystemer, der blev introduceret i 1960'erne, selvom de naturligvis er blevet forbedret på mange måder.

Både IBM-leverede operativsystemer og dem, der leveres af andre, diskuteres her, hvis de især bruges på IBM-mainframes.

Før System/360

IBM var langsom med at introducere operativsystemer: General Motors producerede General Motors OS i 1955 og GM-NAA I/O i 1956 til brug på sine egne IBM-computere; og i 1962 udgav Burroughs Corporation MCP og General Electric introducerede GECOS , i begge tilfælde til brug for deres kunder.

Faktisk blev de første operativsystemer til IBM-computere skrevet af IBM-kunder, der ikke ønskede at få deres meget dyre maskiner (2 millioner dollars i midten af 1950'erne) til at sidde inaktive, mens operatører konfigurerede job manuelt, og derfor ønskede de en mekanisme for at opretholde en kø af job.

Operativsystemerne beskrevet nedenfor kørte kun på få processormodeller og var kun egnede til videnskabelige og tekniske beregninger. Brugere med andre IBM -computere eller andre applikationer skulle klare sig uden operativsystemer. Men en af IBMs mindre computere, IBM 650 , introducerede en funktion, som senere blev en del af OS/360 : hvis behandlingen blev afbrudt af en "tilfældig behandlingsfejl" (hardwarefejl), kunne maskinen automatisk genoptage fra det sidste kontrolpunkt i stedet for kræver, at operatørerne genstarter jobbet manuelt fra begyndelsen.

Fra General Motors 'GM-NAA I/O til IBSYS

General Motors 'Research division producerede GM-NAA I/O til sin IBM 701 i 1956 (fra en prototype, GM Operating System, udviklet i 1955), og opdaterede den til 701's efterfølger. I 1960 overtog IBM -brugerforeningen SHARE det og producerede en opdateret version, SHARE Operating System .

Endelig overtog IBM projektet og leverede en forbedret version kaldet IBSYS med IBM 7090 og IBM 7094 computere. IBSYS krævede 8 bånddrev (færre hvis systemet havde et eller flere diskdrev). Dens hovedkomponenter var: et kortbaseret Job Control -sprog, som var hovedbrugergrænsefladen; kompilatorer til FORTRAN og COBOL ; en montør ; og forskellige hjælpeprogrammer, herunder et sorteringsprogram .

I 1958 tilpassede University of Michigan Executive System GM-NAA I/O til at producere UMES , hvilket var bedre egnet til det store antal små job, der blev skabt af studerende. UMES blev brugt indtil 1967, da det blev erstattet af MTS timesharing -systemet.

BESYS

Bell Labs producerede BESYS (undertiden kaldet BELLMON) og brugte det indtil midten af 1960'erne. Bell stillede den også til rådighed for andre uden beregning eller formel teknisk support.

FORTRAN Monitor System

Før IBSYS producerede IBM et båndbaseret operativsystem til IBM 709 , 7090 og 7094 computere, hvis eneste formål var at kompilere FORTRAN- programmer-faktisk var FMS og FORTRAN-kompilatoren på samme bånd.

Tidlig tidsdeling og virtuelle maskinesystemer

MIT 's Fernando Corbató producerede de første eksperimentelle tidsdelingssystemer , såsom CTSS , fra 1957 til begyndelsen af 1960'erne ved hjælp af let modificerede IBM 709 , IBM 7090 og IBM 7094 mainframes; disse systemer var baseret på et forslag fra John McCarthy . I 1960'erne oprettede IBMs egne laboratorier eksperimentelle tidsdelingssystemer ved hjælp af standard mainframes med hardware- og mikrokodeændringer for at understøtte virtuel hukommelse : IBM M44/44X i begyndelsen af 1960'erne; CP-40 fra 1964 til 1967; CP-67 fra 1967 til 1972. Virksomheden frigav endda CP-67 uden garanti eller teknisk support til flere store kunder fra 1968 til 1972. CP-40 og CP-67 brugte modificerede System/360 CPU'er , men M44/44X var baseret på IBM 7044 , en tidligere generation af CPU, som var meget anderledes internt.

Disse eksperimentelle systemer var for sent til at blive indarbejdet i System/360 -serien, som IBM annoncerede i 1964, men opfordrede virksomheden til at tilføje virtuel hukommelse og virtuelle maskinfunktioner til sine System/370 -mainframes og deres operativsystemer i 1972:

M44/44X viste, at en delvis tilgang til virtuelle maskiner ikke var god nok, og at stød kunne alvorligt reducere hastigheden på virtuelle hukommelsessystemer. Thrashing er en tilstand, hvor systemet kører meget langsomt, fordi det bruger meget af sin tid på at blande virtuelle hukommelsessider mellem fysisk hukommelse og diskfiler.
IBM lærte af CP-40 og CP-67: hvordan man gør håndteringsproblemet håndterbart; at dens andre virtuelle hukommelse og virtuelle maskinteknologier var tilstrækkeligt hurtige og pålidelige til at kunne bruges i kommercielle systemer med stor volumen, som var dens kerneforretning. Især overbeviste IBM's David Sayre virksomheden om, at automatiseret styring af virtuel hukommelse konsekvent kunne udføre mindst lige så godt som de bedste programmeringsdesignede overlay- ordninger.

I 1968 brugte et konsulentfirma ved navn Computer Software Systems den udgivne version af CP-67 til at oprette en kommerciel tidsdelingstjeneste. Virksomhedens tekniske team omfattede 2 rekrutter fra MIT (se CTSS ovenfor), Dick Orenstein og Harold Feinleib. Efterhånden som det voksede, omdøb virksomheden sig til National CSS og ændrede softwaren for at øge antallet af betalende brugere, den kunne understøtte, indtil systemet var tilstrækkeligt anderledes til, at det berettigede et nyt navn, VP/CSS . VP/CSS var leveringsmekanismen for National CSS 'tjenester indtil begyndelsen af 1980'erne, da den skiftede til IBM's VM/370 (se nedenfor).

Universiteter producerede tre andre S/360 tidsdelende operativsystemer i slutningen af 1960'erne:

Den Michigan Terminal System (MTS) blev udviklet i 1967 af et konsortium af universiteter ledet af University of Michigan . Alle versioner kørte på IBM's mainframes, der havde virtuel hukommelse, startende med S/360-67 . MTS forblev i brug indtil 1999.
McGill University i Montreal begyndte at udvikle MUSIC (McGill University System for Interactive Computing) i 1969. MUSIC blev forbedret flere gange og understøttede til sidst tekstsøgninger, webpublicering og e -mail samt softwareudvikling. MUSIC blev markedsført af IBM hovedsageligt til uddannelsesinstitutioner som et omkostningseffektivt operativsystem til sin hardware og blev til sidst et IBM Systems Product (MUSIC / SP eller Multi-User System for Interactive Computing / System Product) i 1985. Den sidste officielle version blev udgivet i 1999.
ORVYL og WYLBUR blev udviklet af Stanford University i 1967-68 til IBM S/360-67. De leverede nogle af de første tidsdelingsfunktioner på IBM S/360-computere.

System/360 operativsystemer

Op til begyndelsen af 1960'erne var IBM's low-end og high-end-systemer inkompatible-programmer kunne ikke let overføres fra det ene til det andet, og systemerne brugte ofte helt forskellige eksterne enheder (f.eks. Diskdrev). IBM konkluderede, at disse faktorer øgede dets design- og produktionsomkostninger for både hardware og software til et uholdbart niveau og reducerede salget ved at afskrække kunderne fra at opgradere. Så i 1964 annoncerede virksomheden System/360 , en ny serie computere, som alle brugte de samme eksterne enheder, og hvoraf de fleste kunne køre de samme programmer.

IBM havde oprindeligt til hensigt, at System/360 kun skulle have et batchorienteret operativsystem, OS/360. Der er mindst to redegørelser for, hvorfor IBM senere besluttede, at det også skulle producere et enklere batchorienteret operativsystem, DOS/360 :

fordi den fandt ud af, at OS/360 ikke ville passe ind i den begrænsede hukommelse, der er tilgængelig på de mindre System/360 -modeller;
eller fordi det indså, at udviklingen af OS/360 ville tage meget længere tid end forventet, og introducerede DOS/360 som en af en række stop-huller for at forhindre System/360-hardwaresalg i at kollapse-de andre var BOS/360 (Basic Operativsystem, til de mindste maskiner) og TOS/360 (Tape Operating System, til maskiner med kun tapedrev).

System/360s operativsystemer var mere komplekse end tidligere IBM -operativsystemer af flere årsager, herunder:

De var nødt til at understøtte multiprogrammering -skifte til at køre en anden igangværende applikation, da den aktuelle applikation blev blokeret og vente på, at I/O- operationer (f.eks. Disklæsning) blev gennemført. Uden multiprogrammering ville de hurtigere CPU'er i området have brugt det meste af deres tid på tomgang og ventet på langsomme I/O -operationer. Derfor skulle operativsystemerne være de virkelige mestre i systemerne, for at levere de tjenester, applikationerne gyldigt anmodede om, og for at håndtere nedbrud eller fejlopførsel i et program uden at stoppe andre, der kørte på samme tid.
De skulle understøtte en meget bredere vifte af maskinstørrelser. Hukommelsen varierede fra 16 KB til 1 MB og processorhastigheder fra et par tusinde instruktioner pr. Sekund til 500.000.
De skulle understøtte en lang række applikationskrav. Nogle applikationer behøvede f.eks. Kun at læse sekventielle filer igennem fra start til slut; andre havde brug for hurtig, direkte adgang til specifikke poster i meget store filer; og et par applikationer brugte næsten al deres tid på at lave beregninger, med meget lidt læsning eller skrivning af filer.

Dette gjorde udviklingen af OS/360 og anden System/360 -software til et af de største softwareprojekter, nogen havde forsøgt, og IBM løb hurtigt i problemer med enorme tid- og omkostningsoverskridelser og et stort antal fejl . Disse problemer blev kun forstørret, fordi IBM først skulle udvikle Basic Programming Support/360 (BPS/360) for at udvikle og teste System/360 -operativsystemer på ægte hardware . BPS blev brugt til at udvikle de værktøjer, der var nødvendige for at udvikle DOS/360 og OS/360, samt de første versioner af værktøjer, det ville levere med disse operativsystemer - kompilatorer til FORTRAN og COBOL , hjælpeprogrammer inklusive Sort , og frem for alt samleren det nødvendig for at bygge al anden software.

IBM's konkurrenter udnyttede forsinkelserne i OS/360 og System/360 til at annoncere systemer rettet mod det, de mente var de mest sårbare dele af IBM's marked. For at forhindre, at salget af System/360 kollapser, frigav IBM fire stop-gap-operativsystemer:

Grundlæggende operativsystem/360 (BOS/360), som blev indlæst fra et diskdrev eller bånddrev og understøttede bånddrev og et par diske. Dette system blev leveret til betatestkunder og kan have været en tidlig version af DOS/360.
TOS/360 , som var designet til at give en opgraderingssti til kunder, der havde IBM 1401 -computere med bånddrev og uden diske.
DOS/360 , som blev bygget af udviklerne af BOS/360 og TOS/360 (IBM's division for små virksomheder computere) og blev til et almindeligt operativsystem, hvis efterkommer z/VSE stadig er meget udbredt.
Operativsystem/360 (OS/360) med kun optionen Primary Control Program (PCP), som ikke understøtter multiprogrammering.

Da IBM annoncerede S/360-67 , annoncerede det også et timesharing- operativsystem, TSS/360 , der ville bruge de nye virtuelle hukommelsesfunktioner i 360/67. TSS/360 var sent, og tidlige udgivelser var langsomme og upålidelige. På dette tidspunkt kørte det alternative operativsystem CP-67 , udviklet af IBMs Cambridge Scientific Center , godt nok til, at IBM kunne tilbyde det "uden garanti" som en timesharing-facilitet for et par store kunder. CP-67 ville blive VM/370 og til sidst z/VM . IBM tilbød i sidste ende tre udgivelser af en TSS/370 PRPQ som en migrationssti for sine TSS/360 -kunder og droppede den derefter.

Traumerne ved at producere System/360 -operativsystemerne gav et boost til den nye disciplin inden for software engineering , forsøget på at anvende videnskabelige principper for udvikling af software og styring af softwareprojekter . Frederick P. Brooks , der var senior projektleder for hele System/360-projektet og derefter fik et specifikt ansvar for OS/360 (som allerede var for sent), skrev en anerkendt bog, The Mythical Man-Month , baseret på stødte på problemer og erfaringer under projektet, hvoraf to var:

At kaste ekstra ressourcer (især personale) til et projekt, der kæmper, bliver hurtigt uproduktivt eller endda kontraproduktivt på grund af kommunikationsproblemer. Dette er "Mythical Man-Month" syndromet, der gav bogen dens titel.
Efterfølgeren til et vellykket system løber ofte ind i vanskeligheder, fordi det bliver overbelastet med alle de funktioner, folk ønskede, havde været i det tidligere system. Brooks kaldte dette " anden systemeffekten " og nævnte OS/360 som et meget omfattende eksempel.

DOS/360

Mens OS/360 var det foretrukne operativsystem til de avancerede System/360-maskiner, var DOS/360 det sædvanlige operativsystem for de mindre kraftfulde maskiner. Det leverede et sæt hjælpeprogrammer , en makro -assembler og kompilatorer til FORTRAN og COBOL . Support til RPG kom senere, og til sidst et PL/I -undersæt. Og det understøttede en nyttig række filorganisationer med adgangsmetoder til at hjælpe med at bruge dem:

Sekventielle datasæt blev normalt læst en post ad gangen fra start til slut.
I indekserede ( ISAM ) filer blev en bestemt sektion af hver post defineret som en nøgle, der kunne bruges til at slå bestemte poster op.
I filer med direkte adgang ( BDAM ) skulle applikationsprogrammet angive den fysiske placering på disken for de data, den ønskede at få adgang til. BDAM -programmering var ikke let, og de fleste kunder brugte det aldrig selv, men det var den hurtigste måde at få adgang til data på diske, og mange softwarevirksomheder brugte det i deres produkter, især databasesystemer som ADABAS , IDMS og IBM's DL/I .

Sekventielle filer og ISAM-filer kan gemme enten poster med fast længde eller variabel længde, og alle typer kan optage mere end én diskvolumen.

DOS/360 tilbød også BTAM , en datakommunikationsfacilitet, der var primitiv og svær at bruge efter nutidens standarder. Men BTAM kunne kommunikere med næsten enhver type terminal, hvilket var en stor fordel på et tidspunkt, hvor der næsten ikke var nogen standardisering af kommunikationsprotokoller.

Men DOS/360 havde betydelige begrænsninger sammenlignet med OS/360 , som blev brugt til at styre de fleste større System/360 -maskiner:

Den første version kunne kun køre et program ad gangen. En senere forbedring tillod 3 på samme tid i en af 3 "partitioner", hvis størrelse blev angivet af hver kunde, da DOS/360 blev installeret.
Den JCL, den brugte til at indsende job, var designet til at være let for low-end-maskiner at behandle, og som et resultat fandt programmører det ikke let at læse eller skrive.
Der var ikke noget spooling- undersystem for at forbedre effektiviteten af brugskort og printerbrug. I slutningen af 1960'erne begyndte et uafhængigt softwarefirma at sælge en spooler kaldet GRASP.
DOS/360 havde ingen flytende loader , så brugere måtte linke redigere en separat eksekverbar version af hvert program for hver partition, hvor programmet sandsynligvis ville blive kørt.
Eksekverbare programmer blev gemt i Core Image Library, som ikke genvinde plads, da programmer blev slettet eller erstattet af nyere versioner. Når Core Image Library blev fuldt, skulle det komprimeres af et af hjælpeprogrammerne, og dette kunne standse udviklingsarbejde i op til en halv dag.
Dens applikationsprogrammeringsinterface var forskellig fra OS/360. DOS/360 -programmer, der er skrevet på sprog på højt niveau, f.eks. COBOL, havde brug for små ændringer, før de kunne bruges sammen med OS/360, og samlingsprogrammer havde brug for større ændringer.

IBM forventede, at DOS/360 -brugere snart ville opgradere til OS/360, men trods sine begrænsninger blev DOS/360 verdens mest udbredte operativsystem, fordi:

System/360 hardware sælges meget godt
Over 90% af de 360 solgte systemer var modeller 20, 30 og 40
De fleste af disse billigere modeller havde langt mindre kernehukommelse end krævet af OS/360.

DOS/360 kørte godt på System/360-processorer, som mellemstore organisationer havde råd til, og det var bedre end de "operativsystemer", disse kunder havde før. Som følge heraf bruges dens efterkommer z/VSE stadig meget i dag fra 2005.

OS/360

OS/360 inkluderede flere understøttelsesniveauer, en enkelt API og meget delt kode. PCP var en stop-gap-version, der kun kunne køre et program ad gangen, men MFT (" Multiprogrammering med et fast antal opgaver") og MVT (" Multiprogrammering med et variabelt antal opgaver") blev brugt indtil i det mindste sent 1970’erne, godt fem år efter at deres efterfølgere var blevet lanceret. Det er uklart, om opdelingerne mellem PCP, MFT og MVT opstod, fordi MVT krævede for meget hukommelse til at kunne bruges på mellemklasse-maskiner, eller fordi IBM skulle frigive en multiprogrammeringsversion af OS (MFT) hurtigst muligt.

PCP, MFT og MVT havde forskellige metoder til styring af hukommelse (se nedenfor), men gav meget lignende faciliteter:

Den samme applikationsprogrammeringsgrænseflade (API), så applikationsprogrammer kunne overføres mellem PCP, MFT og MVT uden selv at skulle genkompilere .
Den samme JCL , som var mere fleksibel og lettere at bruge end DOS/360.
De samme faciliteter ( adgangsmetoder ) som DOS/360 til læsning og skrivning af filer (sekventiel, indekseret og direkte) og til datakommunikation ( BTAM ).
En yderligere filstruktur, partitioneret og adgangsmetode ( BPAM ), som hovedsageligt blev brugt til styring af programbiblioteker. Selvom partitionerede filer skulle komprimeres for at genvinde ledig plads, stoppede dette sjældent udviklingsarbejde, som det gjorde med DOS/360's Core Image Library, fordi PCP, MFT og MVT tillod et ubestemt antal partitionerede filer, og hvert projekt havde generelt mindst en.
Et filnavnsystem, der tillod filer at blive administreret som hierarkier, f.eks. PROJECT.USER.FILENAME .
En spooling facilitet (som DOS/360 manglede).
Applikationer kunne oprette underopgaver, som tillod multiprogrammering inden for det ene job.

Erfaringerne viste, at det ikke var tilrådeligt at installere OS/360 på systemer med mindre end 256 KB hukommelse, hvilket var en almindelig begrænsning i 1960'erne.

MFT

Ved installation af MFT angiver kunderne op til fire "partitioner", hukommelsesområder med faste grænser, hvor applikationsprogrammer kan køres samtidigt. MFT Version II (MFT-II) hævede grænsen til 52.

MVT

MVT var betydeligt større og mere kompleks end MFT og blev derfor brugt på de mest kraftfulde System/360 CPU'er. Den behandlede al hukommelse, der ikke blev brugt af operativsystemet, som en enkelt pulje, hvorfra sammenhængende "regioner" kunne tildeles som krævet af et ubestemt antal samtidige applikationsprogrammer. Denne ordning var mere fleksibel end MFT'er og brugte i princippet hukommelsen mere effektivt, men kunne udsættes for fragmentering - efter et stykke tid kunne man opdage, at selvom der var nok ledig hukommelse i alt til at køre et program, blev den opdelt i separate bidder, ingen af som var stor nok.

I 1971 blev Time Sharing Option (TSO) til brug med MVT tilføjet. TSO blev meget udbredt til programudvikling, fordi det gav: en redaktør; muligheden for at indsende batchjob, få besked om deres afslutning og se resultaterne uden at vente på udskrevne rapporter fejlfindere for nogle af de programmeringssprog, der bruges på System/360. TSO kommunikerede med terminaler ved hjælp af TCAM ( Telecommunications Access Method ), som til sidst erstattede den tidligere Queued Telecommunications Access Method (QTAM). TCAMs navn antyder, at IBM håbede, at det ville blive standardadgangsmetoden for datakommunikation, men faktisk blev TCAM næsten udelukkende brugt til TSO og blev stort set afløst af VTAM fra slutningen af 1970'erne og fremefter.

TP -skærme

System/360's hardware og operativsystemer er designet til behandling af batchjobs, som i ekstreme tilfælde kan køre i timevis. Som følge heraf var de uegnede til transaktionsbehandling , hvor der er tusindvis af arbejdsenheder om dagen og hver tager mellem 30 sekunder og meget få minutter. I 1968 frigav IBM IMS til håndtering af transaktionsbehandling, og i 1969 udgav det CICS , et enklere transaktionsbehandlingssystem, som en gruppe af IBMs medarbejdere havde udviklet til en kunde. IMS var kun tilgængelig for OS/360 og dets efterfølgere, men CICS var også tilgængelig for DOS/360 og dens efterfølgere. Denne type produkt var i mange år kendt som en "TP (teleprocessing) monitor". Strengt taget var TP -skærme ikke operativsystemkomponenter, men applikationsprogrammer, der administrerede andre applikationsprogrammer. I 1970'erne og 1980'erne konkurrerede flere tredjeparts TP-skærme med CICS (især Taskmaster, COM-PLETE, Shadow og Intercomm), men IBM forbedrede gradvist CICS til det punkt, hvor de fleste kunder opgav alternativerne.

Særlige systemer til flyselskaber

I 1950'erne ekspanderede flyselskaberne hurtigt, men denne vækst blev holdt tilbage af vanskeligheden ved at håndtere tusindvis af bookinger manuelt (ved hjælp af kortfiler). I 1957 underskrev IBM en udviklingskontrakt med American Airlines om udvikling af et edb -reservationssystem, der blev kendt som SABER . Det første eksperimentelle system gik live i 1960, og systemet overtog alle bookingfunktioner i 1964 - i begge tilfælde ved hjælp af IBM 7090 mainframes. I begyndelsen af 1960'erne påtog IBM sig lignende projekter for andre flyselskaber og besluttede snart at producere et enkelt standard bookingsystem, PARS , til at køre på System/360 computere.

I SABER og tidlige versioner af PARS var der ingen adskillelse mellem applikation og operativsystemkomponenter i softwaren, men i 1968 opdelte IBM den i PARS (applikation) og ACP (operativsystem). Senere versioner af ACP fik navnet ACP / TPF og derefter TPF (Transaction Processing Facility), da ikke-luftfartsvirksomheder vedtog dette operativsystem til håndtering af store mængder onlinetransaktioner. Den seneste version er z/TPF .

IBM udviklede AVS og dens efterfølgere, fordi: i midten af 1960'erne IBMs standard operativsystemer ( DOS / 360 og OS / 360 ) var batch -orienterede og kunne ikke håndtere et stort antal korte transaktioner hurtigt nok; selv dens transaktionsmonitorer IMS og CICS , der kører under kontrol af standard-operativsystemer til almindelige formål, er ikke hurtige nok til at håndtere reservationer på hundredvis af flyrejser fra tusindvis af rejsebureauer.

Den sidste "public domain" -version af ACP, deraf den sidste "gratis" version, var ACP 9.2, som blev distribueret på en enkelt mini-rulle med et ledsagende manuelt sæt (ca. to dusin manualer, der optog måske 48 lineære tommer hylde plads) og som kunne gendannes til IBM 3340 diskdrev, og som derved ville give et fuldt funktionelt ACP -system.

ACP 9.2 var primært beregnet til bankkort (MasterCard, et al.) Og andre "finansielle" applikationer, men det kunne også bruges til reservationer af flyselskaber, da ACP på dette tidspunkt var blevet et mere generelt OS .

Faktisk havde ACP på det tidspunkt indarbejdet et "hypervisor" -modul (CHYR), som understøttede et virtuelt operativsystem ... normalt VS1 , men muligvis også VS2 ... som en "gæst", med hvilken programudvikling eller filvedligeholdelse kunne udføres samtidigt med onlinefunktioner.

I nogle tilfælde blev produktionsarbejde kørt under VS2 under hypervisoren, herunder muligvis IMS DB.

System/360 Model 20

Den Model 20 blev mærket som en del af System / 360 interval, fordi det kunne være forbundet med nogle af de samme ydre enheder, men det var en 16-bit maskine og ikke helt program-kompatibelt med andre medlemmer af System / 360 rækkevidde. Tre operativsystemer blev udviklet af IBMs laboratorier i Tyskland til forskellige 360/20 konfigurationer; DPS - med diske (minimum hukommelse krævet: 12 KB); TPS - ingen disk, men med bånd (minimum hukommelse kræves: 8 KB); og CPS-kortbaseret (baseret på minimum hukommelse: 4 KB). Disse havde ingen direkte efterfølgere, siden IBM introducerede System/3 -serien af små virksomhedscomputere i 1969, og System/3 havde et andet internt design end 360/20 og forskellige eksterne enheder fra IBM's mainframes.

System/360 Model 44

Dette var en anden processor, der brugte System/360 periferiudstyr, men havde et andet internt design. Den 360/44 designet til videnskabelige beregninger under anvendelse af flydende komma tal, såsom geologiske eller meteorologiske analyser. På grund af de interne forskelle og den specialiserede type arbejde, som det var designet til, havde 360/44 sit eget operativsystem, PS/44. En emulator til manglende System/360 -instruktioner tillod Model 44 at køre OS/360. 360/44 og PS/44 havde ingen direkte efterfølgere.

System/370 og virtuelle hukommelsesoperativsystemer

Da System/370 blev annonceret i 1970, tilbød det i det væsentlige de samme faciliteter som System/360, men med cirka 4 gange processorhastighederne for System/360-CPU'er til samme pris. Så annoncerede IBM i 1972 "System/370 Advanced Functions", hvoraf hovedelementet var, at fremtidigt salg af System/370 ville omfatte virtuel hukommelseskapacitet , og dette kunne også eftermonteres eksisterende System/370 CPU'er. Derfor forpligtede IBM sig også til at levere forbedrede operativsystemer, som kunne understøtte brugen af virtuel hukommelse.

De fleste af de nye operativsystemer blev adskilt fra deres forgængere ved tilstedeværelsen af "/VS" i deres navne. "VS" står for "Virtual Storage" - IBM undgik udtrykket "virtuel hukommelse", angiveligt fordi ordet "hukommelse" kan tolkes for at betyde, at IBM -computere kunne glemme ting.

Alle nutidens IBM-mainframe-operativsystemer undtagen z/TPF er efterkommere af dem, der er inkluderet i meddelelsen "System/370 Advanced Functions"-z/TPF er en efterkommer af ACP , systemet, som IBM oprindeligt udviklede til at understøtte applikationer med store reservationer til flyselskaber .

DOS/VS

DOS/VS var efterfølgeren til DOS/360 og tilbød lignende faciliteter med tilføjelse af virtuel hukommelse. Ud over den virtuelle hukommelse leverede DOS/VS andre forbedringer:

Fem hukommelsespartitioner i stedet for tre. Senere udgivelser øgede dette til syv.
En flytende loader, så det ikke længere var nødvendigt at linke-redigere en separat kopi af hvert program for hver partition, hvor det skulle køre.
En forbedret spooling -komponent, POWER/VS.

DOS/VS blev efterfulgt af betydelige opgraderinger: DOS/VSE og VSE/SP (1980'erne), VSE/ESA (1991) og z/VSE (2005).

OS/VS1

OS/VS1 var efterfølgeren til MFT og tilbød lignende faciliteter med tilføjelse af virtuel hukommelse. IBM frigav temmelig mindre forbedringer af OS/VS1 indtil 1983, og meddelte i 1984, at der ikke ville være flere. OS/VS1 og TSS/370 er de eneste IBM System/370 -operativsystemer, der ikke har moderne efterkommere.

Det særlige realtidsoperativsystem (SRTOS), Programmering RPQ Z06751, var en variant af OS/VS1 udvidet til at understøtte realtids-computing . Det var målrettet mod industrier som energiforvaltning af elværker og olieraffinaderier.

OS/VS2 og MVS

OS/VS2 Release 1 ( SVS ) var en erstatning for MVT med virtuel hukommelse; mens der var mange ændringer, bevarede den den overordnede struktur. Men i 1974 udgav IBM, hvad den beskrev som OS/VS2 Release 2, men som var en stor omskrivning, der var opad-kompatibel med den tidligere OS/VS2 SVS. Det nye systems mest mærkbare funktion var, at det understøttede flere virtuelle adresserum - forskellige applikationer troede, at de brugte det samme udvalg af virtuelle adresser, men det nye systems virtuelle hukommelsesfaciliteter kortlagde disse til forskellige områder af rigtige hukommelsesadresser. Som et resultat blev det nye system hurtigt kendt som " MVS " (Multiple Virtual Storages), det originale OS/VS2 blev kendt som "SVS" (Single Virtual Storage). IBM accepterede selv denne terminologi og stemplede MVS's efterfølgere "MVS/...".

De andre særpræg ved MVS var: dets hovedkatalog skulle være et VSAM -katalog; den understøttede "tæt koblet multiprocessing" (2 eller flere CPU'er deler den samme hukommelse og kopi af operativsystemet); det omfattede en Systemressourcemanager (omdøbt til Workload Manager i senere versioner), som tillod brugere at indlæse yderligere arbejde på systemet uden at reducere ydelsen af job med høj prioritet.

IBM har frigivet flere MVS -opgraderinger: MVS/SE , MVS/SP Version 1, MVS/XA (1981), MVS/ESA (1985), OS/390 (1996) og i øjeblikket z/OS (2001).

VM/370

VM/370 kombinerede en virtuel maskinfacilitet med et enkeltbrugersystem kaldet Conversational Monitor System (CMS); denne kombination gav tidsdeling ved at tillade hver bruger at køre en kopi af CMS på sin egen virtuelle maskine. Denne kombination var en direkte efterkommer af CP/CMS . Den virtuelle maskinfacilitet blev ofte brugt til at teste ny software, mens normalt produktionsarbejde fortsatte med en anden virtuel maskine, og CMS timesharing -systemet blev meget udbredt til programudvikling.

VM/370 blev efterfulgt af en række opgraderinger: VM/SEPP ("System Extensions Program Product"), VM/BSEPP ("Basic Systems Extensions Program Product"), VM/SP (System Product), VM/SP HPO (" High Performance Option "), VM/XA MA (" Extended Architecture Migration Aid "), VM/XA SF (" Extended Architecture System Facility "), VM/XA SP (" Extended Architecture System Product "), VM/ESA (" Enterprise Systems Architecture ") og z/VM . IBM også produceret valgfrie mikrokodeopdatering hjælper til VM og efterfølgere, at fremskynde hypervisor 's emulering af privilegerede instruktioner (dem, der kun operativsystemer kan bruge) på vegne af 'gæst' operativsystemer. Som en del af 370/Extended Architecture tilføjede IBM instruktionen Start Interpretive Execution (SIE) for at muliggøre en yderligere hastighed af CP -hypervisoren.

Tekniske noter

Tidsdeling

Tidsdeling (eller timesharing) er baseret på ideen om, at computere er meget hurtigere end mennesker, så mens en menneskelig bruger læser, hvad en computer lige har vist på en skærm, kan computeren udføre noget nyttigt arbejde for en anden bruger. Store tidsdelingssystemer kan have hundredvis eller endda tusinder af samtidige brugere, og den hukommelse, der kræves af deres programmer og data, tilføjer generelt meget mere end den fysiske hukommelse, der er knyttet til computeren. Tidsdelingssystemer løser dette problem ved forskellige kombinationer af:

virtuel hukommelse, beskrevet nedenfor.
bytte: Når operativsystemet venter på svar fra en bruger, en tidsskive er slut, eller operativsystemet forsøger at frigøre reel lagerplads, kan det gemme en brugers programmer og data på en disk eller tromme og læse dem tilbage i hukommelsen, når brugeren sender et svar, ressourcer frigøres, eller en anden bruger byttes ud på grund af tidsskiftet . Bytte kræver ikke virtuel hukommelse; det blev implementeret på OS/360 uden virtuel hukommelse. Det overfører alle en brugers programmer og data mellem hukommelse og disk/tromme og er hovedsageligt drevet af brugerens svar på oplysninger, der vises af systemet.

Virtuel hukommelse

Virtuel hukommelse er en hukommelseshåndteringsteknik, ved hvilken programmer er lavet til at fungere, som om de har mere hukommelse til rådighed end dem, der rent faktisk er knyttet til computeren. Kører programmernes kode og data kan være spredt over flere områder af fysisk hukommelse eller endda placeret på en disk/tromle, indtil det er nødvendigt.

Hovedkomponenterne i et IBM virtuelt hukommelsessystem er:

Virtuel hukommelse , der består af alle hukommelsesadresser, som CPU -hardware har adgang til. Virtuel hukommelse er en abstraktion, så systemer kan let have mere virtuel end ægte hukommelse.
Sider , blokke i fast størrelse, som al virtuel hukommelse er opdelt i. De fleste IBM-operativsystemer bruger 4 KB (4.096-byte) sider, selvom nogle ældre systemer kørte ganske godt med 2 KB (2.048-byte) sider. Nyere IBM System z -systemer understøtter også 1 MB store sider ud over de normale 4 KB -sider.
Ægte hukommelse , tilfældig adgangshukommelse (RAM) knyttet til computersystemet.
Siderammer , realiseret ved at dele al reel hukommelse i stykker, der er lig med systemets sidestørrelse. Virtuel-memory -sider skal placeres i real-memory page frames , før de kan bruges af CPU og I / O-kanaler.
Page Tables spore placeringen af hver virtuel-hukommelse side, enten i en real-hukommelse side ramme eller på disk / tromme, i en sidefil . Kritisk til hukommelsesstyring, sidetabelindgange registrerer også sidste gang, hver side blev åbnet.
Dynamisk adresseoversættelseshardware (undertiden kaldet en "DAT -boks" i tidlige systemer på grund af dets separate kabinet) er integreret i selve CPU'en og deltager i hver hukommelsesreference. Hvis sidetabellen viser siden i en ægte hukommelsesramme, oversætter DAT den virtuelle adresse til en rigtig adresse og giver adgang til hukommelsen færdig. Hvis siden der henvises til på den anden side ikke er i den rigtige hukommelse, genererer DAT -hardwaren en afbrydelse (internt signal), som opfordrer personsøgerens tilsynsførende til handling.
Den Paging tilsynsførende (en del af operativsystemet) styrer alt hukommelse, både virkelige og virtuelle, flytte sider mellem reelle hukommelse og disk / tromle efter behov, holder Side Table opdateret, servicering anmodninger hukommelse tildeling, og rydde op efter sig selv. Når belastningen på systemet øges, kan der refereres til en side, når alle siderammer er i brug. Når dette sker, identificerer personsøgerens supervisor typisk den side, der ikke er blevet læst eller skrevet i det længste tidsinterval (mindst senest brugt), kopierer siden til personsøgerfilen (på disk eller tromle), opdaterer sidetabellen , og bruger den nyligt tilgængelige sideramme til at opfylde hukommelsesanmodningen.

Når det fungerer korrekt, beholder det virtuelle hukommelsessystem aktive sider i ægte hukommelse, inaktive dem på disk/tromle og muliggør mere effektiv udførelse af systemets arbejdsbyrde.

Virtuel maskine

Virtuelle maskinteknikker gør det muligt for flere operativsystemer ("gæst" -operativsystemer) eller anden software at køre på den samme computer, så hver tror, at den har en hel computer for sig selv, og hver af disse simulerede hele computere kaldes en "virtuel maskine". Operativsystemet, der virkelig styrer computeren, kaldes normalt en hypervisor . To af hypervisorens hovedkomponenter er:

Virtuel hukommelsesstyring. Hver virtuel maskine ser ud til at have en komplet række adresser fra 0 til et stort antal, og virtuelle hukommelsesteknikker forhindrer forskellige virtuelle maskiner i at forvirre hinanden.
Simulering af "privilegerede" funktioner på vegne af "gæst" -operativsystemerne. "Privilegerede" funktioner er dem, der gør det muligt for programmer at overtage hele eller i det mindste store dele af computeren, og normalt afslutter operativsystemer straks ethvert andet program, der forsøger at bruge dem. Men "gæst" -systemer mener, at de er berettiget til at bruge disse funktioner, så hypervisoren registrerer deres forsøg på at gøre det og kører de privilegerede funktioner på deres vegne ved hjælp af virtuelle hukommelsesteknikker for at forhindre dem i at ødelægge hukommelsesområder, der bruges af andre "gæst" operativsystemer.

Se også

Referencer

Yderligere læsning

Brooks, Jr., Frederick P. (1975). " The Mythical Man-Month: Essays on Software Engineering ", Addison-Wesley. ISBN 0-201-00650-2 . (Genoptrykt med rettelser, januar 1982)
IBM mainframe -operativsystemer: Tidslinje og kort forklaring til IBM System/360 og videre , Dave Morton.
En wiki dedikeret til IBM Mainframe Computers

Languages

In other projects