MVS - MVS

For annen bruk, se MVS (disambiguation) .

Multiple Virtual Storage (MVS)
IBM logo.svg
Utvikler IBM
Skrevet inn Assembler (XF) , PL/S
OS -familie OS/360
Første utgivelse 1974 ; 47 år siden ( 1974 )
Markedsføringsmål IBM mainframe -datamaskiner
Tilgjengelig i Engelsk
Plattformer System/370 , System/390
Påvirket av TSS
Tillatelse Proprietær
I utgangspunktet gratis
Foregitt av OS/360 MVT , OS/VS2 (SVS)
etterfulgt av MVS/SE, MVS/SP , MVS/XA , MVS/ESA , OS/390 , z/OS
Historien til IBMs hovedframe -operativsystemer
Tidlige datamaskiner for mainframe
Diverse S/360 line OSer
DOS/360 og etterfølgere (1966)
OS/360 og etterfølgere (1966)
VM -linje
TPF linje
UNIX og Unix-lignende

Multiple Virtual Storage , mer ofte kalt MVS , var det mest brukte operativsystemet på system/370 og System/390 IBM mainframe -datamaskiner . IBM utviklet MVS, sammen med OS/VS1 og SVS , som en etterfølger til OS/360 . Det er ikke relatert til IBMs andre mainframe -operativsystemlinjer, f.eks. VSE , VM , TPF .

Oversikt

Først utgitt i 1974, ble MVS utvidet med programprodukter med nye navn flere ganger:

  • først til MVS/SE (MVS/System Extensions),
  • ved siden av MVS/SP (MVS/System Product) versjon 1,
  • ved siden av MVS/XA (MVS/eXtended Architecture),
  • ved siden av MVS/ESA (MVS/Enterprise Systems Architecture),
  • deretter til OS/390 og
  • endelig til z/OS (da 64-biters støtte ble lagt til med zSeries- modellene). IBM la til UNIX -støtte (opprinnelig kalt OpenEdition MVS ) i MVS/SP V4.3 og har fått POSIX- og UNIX ™ -sertifiseringer på flere forskjellige nivåer fra IEEE , X/Open og The Open Group . MVS -kjernen forblir grunnleggende det samme operativsystemet. Etter design kjøres programmer skrevet for MVS på z/OS uten endring.

Først beskrev IBM MVS som ganske enkelt en ny versjon av OS/VS2 , men det var faktisk en stor omskriving. OS/VS2 versjon 1 var en oppgradering av OS/360 MVT som beholdt det meste av den opprinnelige koden og, i likhet med MVT, hovedsakelig ble skrevet på samlingsspråk . MVS-kjernen var nesten helt skrevet i Assembler XF , selv om noen få moduler ble skrevet i PL/S , men ikke de ytelsesfølsomme, spesielt ikke Input/Output Supervisor ( IOS ). IBMs bruk av "OS/VS2" understreket kompatibilitet oppover: applikasjonsprogrammer som kjørte under MVT, trengte ikke engang omkompilering for å kjøre under MVS. De samme jobbkontrollspråkfilene kan brukes uendret; verktøy og andre ikke-kjernefasiliteter som TSO gikk uendret. IBM og brukere kalte nesten enstemmig det nye systemet for MVS fra starten, og IBM fortsatte å bruke begrepet MVS i navngivningen av senere større versjoner som MVS/XA.

Evolusjon av MVS

OS/360 MFT (multitasking med et fast antall oppgaver) ga multitasking: flere minnepartisjoner , hver med en fast størrelse, ble satt opp når operativsystemet ble installert og når operatøren redefinerte dem. For eksempel kan det være en liten partisjon, to mellomstore partisjoner og en stor partisjon. Hvis det var to store programmer klare til å kjøre, måtte det ene vente til det andre var ferdig og forlot den store partisjonen.

OS/360 MVT (Multitasking with a Variable number of Tasks) var en forbedring som ytterligere forbedret minnebruk. I stedet for å bruke minnepartisjoner med fast størrelse, tildelte MVT minne til regioner for jobbtrinn etter behov, forutsatt at det var nok sammenhengende fysisk minne tilgjengelig. Dette var et betydelig fremskritt i forhold til MFTs minnestyring, men hadde noen svakheter: hvis en jobb tildelte minne dynamisk (slik de fleste sorteringsprogrammer og databasesystemer gjør), måtte programmererne estimere jobbens maksimale minnekrav og forhåndsdefinere det for MVT . Et jobbtrinn som inneholdt en blanding av små og store programmer, bortkastet minne mens de små programmene kjørte. Helt seriøst kan hukommelsen bli fragmentert , det vil si at hukommelsen som ikke brukes av nåværende jobber, kan deles i ubrukelig små biter mellom områdene som brukes av nåværende jobber, og den eneste løsningen var å vente til noen nåværende jobber er ferdige før noen nye starter.

På begynnelsen av 1970 -tallet forsøkte IBM å redusere disse vanskelighetene ved å introdusere virtuelt minne (som IBM kalte "virtuell lagring"), noe som tillot programmer å be om adresserom større enn fysisk minne. De opprinnelige implementeringene hadde et enkelt virtuelt adresserom , delt av alle jobber. OS/VS1 var OS/360 MFT innenfor et enkelt virtuelt adresserom; OS/VS2 SVS var OS/360 MVT innenfor et enkelt virtuelt adresserom. Så OS/VS1 og SVS hadde i prinsippet de samme ulempene som MFT og MVT, men virkningene var mindre alvorlige fordi jobber kunne be om mye større adresserom og forespørslene kom ut av et 16 MB basseng selv om fysisk lagring var mindre.

MVS -adresserom - global visning
MVS (delt del av alle adresserom)
App 1 App 2 App 3
Felles virtuelt område (kontrollert av MVS)
Én applikasjons visning
MVS
App 1
Felles virtuelt område

På midten av 1970-tallet introduserte IBM MVS, som ikke bare støttet virtuell lagring som var større enn tilgjengelig ekte lagring, i likhet med SVS, men også tillot et ubestemt antall applikasjoner å kjøre i forskjellige adresserom. To samtidige programmer kan prøve å få tilgang til den samme virtuelle minneadressen, men det virtuelle minnesystemet omdirigerte disse forespørslene til forskjellige områder av fysisk minne. Hvert av disse adresserommene besto av tre områder: et operativsystem (en forekomst delt av alle jobber), et applikasjonsområde unikt for hver applikasjon og et delt virtuelt område som brukes til forskjellige formål, inkludert kommunikasjon mellom jobber. IBM lovet at applikasjonsområder alltid ville være minst 8 MB. Dette gjorde MVS til den perfekte løsningen for forretningsproblemer som skyldes behovet for å kjøre flere applikasjoner.

MVS maksimerte behandlingspotensialet ved å tilby muligheter for multiprogrammering og multiprosessering . I likhet med forgjengerne til MVT og OS/VS2 SVS , støttet MVS multiprogrammering ; programinstruksjoner og tilhørende data planlegges av et kontrollprogram og gis behandlingssykluser. I motsetning til et enkeltprogrammerende operativsystem maksimerer disse systemene bruken av prosesseringspotensialet ved å dele behandlingssykluser mellom instruksjonene knyttet til flere forskjellige programmer som kjører samtidig. På denne måten trenger ikke kontrollprogrammet å vente på at I/O -operasjonen er fullført før du fortsetter. Ved å utføre instruksjonene for flere programmer, kan datamaskinen bytte frem og tilbake mellom aktive og inaktive programmer.

Tidlige utgaver av MVS (midten av 1970-tallet) var blant de første i IBM OS-serien som støttet multiprosessorkonfigurasjoner , selv om M65MP-varianten av OS/360 som kjører på 360 modell 65 og 67 hadde gitt begrenset flerprosessorstøtte. 360 Model 67 hadde også vært vert for flerprosessor-kompatible TSS/360 , MTS og CP-67 operativsystemer. Fordi flerbehandlingssystemer kan utføre instruksjoner samtidig, tilbyr de større prosessorkraft enn enkeltbehandlingssystem. Som et resultat var MVS i stand til å løse forretningsproblemene som ble forårsaket av behovet for å behandle store datamengder.

Flerbehandlingssystemer er enten løst koblet, noe som betyr at hver datamaskin har tilgang til en felles arbeidsmengde, eller tett koblet , noe som betyr at datamaskinene deler den samme virkelige lagringen og styres av en enkelt kopi av operativsystemet . MVS beholdt både løst koblet multiprosessering av Attached Support Processor (ASP) og tett koblet multiprosessering av OS/360 Model 65 Multiprocessing . I tett koblede systemer delte to CPUer samtidig tilgang til samme minne (og kopi av operativsystemet) og eksterne enheter, noe som gir større prosessorkraft og en grad av grasiøs degradering hvis en CPU mislyktes. I løst koblede konfigurasjoner hadde hver av en gruppe prosessorer (enkelt og / eller tett koblet) sitt eget minne og operativsystem, men delte eksterne enheter og operativsystemkomponenten JES3 tillot administrering av hele gruppen fra en konsoll. Dette ga større motstandskraft og lot operatører bestemme hvilken prosessor som skulle kjøre hvilke jobber fra en sentral jobbkø. MVS JES3 ga brukerne mulighet til nettverket sammen to eller flere datasystemer via delte disker og Kanal-til-kanal adaptere (CTCA s). Denne muligheten ble til slutt tilgjengelig for JES2-brukere som Multi-Access SPOOL (MAS).

MVS støttet opprinnelig 24-biters adressering (dvs. opptil 16 MB). Etter hvert som den underliggende maskinvaren utviklet seg, støttet den 31-biters (XA og ESA; opptil 2048 MB) og nå (som z/OS) 64-biters adressering. De viktigste motivene for den raske oppgraderingen til 31-biters adressering var veksten av store transaksjonsbehandlingsnettverk, for det meste kontrollert av CICS , som kjørte i et enkelt adresserom-og DB2- relasjonsdatabasesystemet trengte mer enn 8 MB applikasjon adresserom for å kjøre effektivt. (Tidlige versjoner ble konfigurert til to adresserom som kommuniserte via det delte virtuelle området, men dette påførte en betydelig overhead siden all slik kommunikasjon hadde overført via operativsystemet.)

De viktigste brukergrensesnittene til MVS er: Job Control Language (JCL), som opprinnelig ble designet for batchbehandling, men fra 1970-tallet og fremover også ble brukt til å starte og allokere ressurser til langvarige interaktive jobber som CICS ; og TSO (Time Sharing Option), det interaktive tidsdelingsgrensesnittet , som hovedsakelig ble brukt til å kjøre utviklingsverktøy og noen få sluttbrukerinformasjonssystemer. ISPF er en TSO-applikasjon for brukere på 3270-familieterminaler (og senere også på VM), som lar brukeren utføre de samme oppgavene som TSOs kommandolinje, men på en meny og formorientert måte, og med en fullskjermredigerer og filleser. TSOs grunnleggende grensesnitt er kommandolinje , selv om det senere ble lagt til fasiliteter for skjema-drevne grensesnitt.

MVS tok et stort skritt fremover innen feiltoleranse, bygget på det tidligere STAE-anlegget, som IBM kalte programvaregjenoppretting . IBM bestemte seg for å gjøre dette etter mange års praktisk erfaring fra virkeligheten med MVT i næringslivet. Systemfeil hadde nå stor innvirkning på kundebedrifter, og IBM bestemte seg for å ta et stort designhopp for å anta at til tross for de aller beste programvareutvikling og testteknikker, vil "problemer oppstå." Denne dype antagelsen var avgjørende for å legge til store prosentandeler av feiltoleransekoder i systemet og bidro sannsynligvis til systemets suksess med å tolerere programvare- og maskinvarefeil. Det er vanskelig å få statistisk informasjon for å bevise verdien av disse designfunksjonene (hvordan kan du måle "forhindrede" eller "gjenopprettede" problemer?), Men IBM har i mange dimensjoner forbedret disse feiltolerante programvaregjenoppretting og rask problemløsning funksjoner, over tid.

Denne designen spesifiserte et hierarki av feilhåndteringsprogrammer, i systemmodus (kjerne/'privilegert'), kalt Functional Recovery Routines, og i brukermodus ('oppgave' eller 'problemprogram'), kalt "ESTAE" (Extended Specified Task) Unormal Exit routines) som ble påkalt i tilfelle systemet oppdaget en feil (maskinvareprosessor eller lagringsfeil eller programvarefeil). Hver gjenopprettingsrutine gjorde funksjonen 'hovedlinje' gjenkallelig, fanget feildiagnostiske data som var tilstrekkelig til å feilsøke det forårsakende problemet, og enten 'prøvde på nytt' (oppretter hovedlinjen på nytt) eller 'perkolert' (eskalert feilbehandling til neste gjenopprettingsrutine i hierarkiet).

Dermed registrerte systemet med hver feil diagnostiske data og forsøkte å utføre en reparasjon og holde systemet oppe. Det verste som var mulig var å ta ned et brukeradresserom (en 'jobb') i tilfelle feil som ikke er reparert. Selv om det var et første designpunkt, var det ikke før den siste MVS -versjonen (z/OS), at gjenopprettingsprogrammet ikke bare var sikret sin egen gjenopprettingsrutine, men hver gjenopprettingsrutine har nå sin egen gjenopprettingsrutine. Denne gjenopprettingsstrukturen var innebygd i det grunnleggende MVS -kontrollprogrammet, og programmeringsfasiliteter er tilgjengelige og brukes av applikasjonsprogramutviklere og tredjepartsutviklere.

Praktisk sett gjorde MVS -programvaregjenoppretting problemløsing både enklere og vanskeligere. Programgjenoppretting krever at programmer forlater "spor" av hvor de er og hva de gjør, og dermed letter debugging - men det faktum at behandlingen skrider frem til tross for en feil kan overskrive sporene. Tidlig datafangst på tidspunktet for feilen maksimerer feilsøking, og det finnes muligheter for gjenopprettingsrutiner (oppgave og systemmodus, begge) for å gjøre dette.

IBM inkluderte ytterligere kriterier for et stort programvareproblem som krevde IBM -service. Hvis en hovedkomponent ikke klarte å starte programvaregjenoppretting, ble det ansett som en gyldig feilmelding. Hvis en gjenopprettingsrutine ikke klarte å samle inn betydelige diagnostiske data slik at det opprinnelige problemet kunne løses av data som ble samlet inn av gjenopprettingsrutinen, dikterte IBM -standarder at denne feilen var rapporterbar og måtte repareres. Dermed oppmuntret IBM -standarder til strenge forbedringer når de ble strengt anvendt.

IBM fortsatte å støtte det store verktøyet for brukbarhet Dynamic Support System (DSS) som det hadde introdusert i OS/VS1 og OS/VS2 versjon 1. Dette interaktive anlegget kan påkalles for å starte en økt for å opprette diagnostiske prosedyrer eller påberope allerede lagrede prosedyrer . Prosedyrene fanget opp spesielle hendelser, for eksempel lasting av et program, enhets -I/O, systemprosedyreanrop og utløste deretter aktiveringen av de tidligere definerte prosedyrene. Disse prosedyrene, som kan påberopes rekursivt, tillot lesing og skriving av data og endring av instruksjonsflyt. Programvareopptaksmaskinvare ble brukt.

IBM droppet støtte for DSS med Selectable Unit 7 (SU7), en oppdatering til OS/VS2 Release 3.7 som kreves av programproduktet OS/VS2 MVS/System Extensions (MVS/SE), programnummer 5740-XEl. Brukergruppen SHARE godkjente et krav om at IBM skulle gjenopprette DSS, og IBM ga en PTF for å tillate bruk av DSS etter at MVS/SE ble installert.

IBM droppet igjen støtten til DSS med SU64, en oppdatering til OS/VS2 Release 3.8 som kreves av versjon 2 av MVS/SE.

Program-hendelsesopptak (PER) utnyttelse ble utført ved forbedring av den diagnostiske SLIP-kommandoen med introduksjonen av PER-støtten (SLIP/Per) i SU 64/65 (1978).

Flere kopier av MVS (eller andre IBM -operativsystemer) kan dele den samme maskinen hvis maskinen ble kontrollert av VM/370 . I dette tilfellet var VM/370 det virkelige operativsystemet, og betraktet "gjestens" operativsystemer som applikasjoner med uvanlig høye privilegier. Som et resultat av senere maskinvareforbedringer kan en forekomst av et operativsystem (enten MVS eller VM med gjester eller andre) også oppta en logisk partisjon (LPAR) i stedet for et helt fysisk system.

Flere MVS-forekomster kan organiseres og administreres samlet i en struktur som kalles et systemkompleks eller sysplex , introdusert i september 1990. Forekomster fungerer sammen gjennom en programvarekomponent kalt et Cross-system Coupling Facility (XCF) og en maskinvarekomponent som kalles en Hardware Coupling Facility (CF eller Integrated Coupling Facility, ICF, hvis de ligger på samme maskinvare i hovedrammen). Flere sysplexer kan kobles sammen via standard nettverksprotokoller som IBMs proprietære Systems Network Architecture (SNA) eller, mer nylig, via TCP/IP . Z/OS -operativsystemet (MVS 'siste etterkommer) har også innebygd støtte for å utføre POSIX- og Single UNIX -spesifikasjonsprogrammer . Støtten begynte med MVS/SP V4R3, og IBM har oppnådd UNIX 95 -sertifisering for z/OS V1R2 og senere.

Systemet brukes vanligvis i forretninger og bank, og applikasjoner skrives ofte i COBOL . COBOL -programmer ble tradisjonelt brukt med transaksjonsbehandlingssystemer som IMS og CICS . For et program som kjører i CICS, er spesielle EXEC CICS -setninger satt inn i COBOL -kildekoden. En forhåndsbehandler (oversetter) erstatter disse EXEC CICS -setningene med den riktige COBOL -koden for å ringe CICS før programmet kompileres - ikke helt ulikt SQL som ble brukt til å kalle DB2 . Søknader kan også skrives på andre språk som C , C ++ , Java , samlingsspråk , FORTRAN , BASIC , RPG og REXX . Språkstøtte er pakket som en vanlig komponent kalt "Språkmiljø" eller "LE" for å tillate jevn feilsøking, sporing, profilering og andre språkuavhengige funksjoner.

MVS -systemer er tradisjonelt åpnet av 3270 terminaler eller av PCer som kjører 3270 emulatorer. Imidlertid har mange mainframe -applikasjoner i disse dager tilpassede web- eller GUI -grensesnitt. Operativsystemet z/OS har innebygd støtte for TCP/IP . Systemadministrasjon, tidligere utført med en 3270 -terminal, gjøres nå gjennom Hardware Management Console (HMC) og i økende grad webgrensesnitt. Operatørkonsoller leveres gjennom 2074 emulatorer, så det er usannsynlig at du vil se noen S/390- eller zSeries -prosessorer med en ekte 3270 koblet til den.

Det opprinnelige tegnkodingsskjemaet til MVS og dets eksterne enheter er EBCDIC , men TR-instruksjonen gjorde det enkelt å oversette til andre 7- og 8-biters koder. Over tid la IBM til maskinvareakselererte tjenester for å utføre oversettelse til og mellom større koder, maskinvarespesifikke tjenester for Unicode-transformasjoner og programvarestøtte for f.eks. ASCII , ISO/IEC 8859 , UTF-8 , UTF-16 og UTF-32 . Programvareoversettelsestjenestene tar kilde- og destinasjonskodesider som innganger.

MVS filsystem

Filer, andre enn Unix -filer, kalles riktig datasett i MVS. Navnene på disse filene er organisert i kataloger som er VSAM -filer selv.

Datasettnavn (DSN -er, hovedrammeterm for filnavn) er organisert i et hierarki hvis nivå er atskilt med prikker, f.eks. "DEPT01.SYSTEM01.FILE01". Hvert nivå i hierarkiet kan være opptil åtte tegn langt. Den totale lengden på filnavnet er maksimalt 44 tegn inkludert prikker. Etter konvensjon brukes komponentene atskilt med prikkene til å organisere filer på samme måte som kataloger i andre operativsystemer. For eksempel var det verktøy som utførte lignende funksjoner som i Windows Utforsker (men uten GUI og vanligvis i batchbehandlingsmodus ) - legge til, gi nytt navn til eller slette nye elementer og rapportere alt innholdet i et spesifisert element. I motsetning til mange andre systemer er imidlertid disse nivåene vanligvis ikke faktiske kataloger, men bare en navnekonvensjon (som det originale Macintosh -filsystemet , der mappehierarki var en illusjon vedlikeholdt av Finder). TSO støtter et standardprefiks for filer (ligner et "nåværende katalog" -konsept), og RACF støtter oppsett av tilgangskontroller basert på filnavnmønstre , analogt med tilgangskontroller på kataloger på andre plattformer.

Som med andre medlemmer av OS-familien var MVS datasett rekordorientert . MVS arvet tre hovedtyper fra forgjengerne:

  • Sekvensielle datasett ble normalt lest en post om gangen fra begynnelse til slutt.
  • I BDAM (direkte tilgang) datasett måtte applikasjonsprogrammet spesifisere den fysiske plasseringen av dataene den ønsket å få tilgang til (vanligvis ved å spesifisere forskyvningen fra starten av datasettet).
  • I ISAM datasett ble en spesifisert seksjon av hver post definert som en nøkkel som kan brukes som en nøkkel for å slå opp bestemte poster. Nøkkelen bestod ganske ofte av flere felt, men disse måtte være sammenhengende og i riktig rekkefølge; og sentrale verdier måtte være unike. Derfor kan en IBM ISAM -fil bare ha en nøkkel, tilsvarende hovednøkkelen til en relasjonell databasetabell ; ISAM kunne ikke støtte utenlandske nøkler .

Sekvensielle og ISAM-datasett kan lagre enten poster med fast lengde eller variabel lengde, og alle typer kan oppta mer enn ett diskvolum.

Alle disse er basert på VTOC -diskstrukturen .

Tidlige IBM -databasesystemer brukte forskjellige kombinasjoner av ISAM- og BDAM -datasett - vanligvis BDAM for selve datalagringen og ISAM for indekser.

På begynnelsen av 1970 -tallet introduserte IBMs operativsystemer for virtuelt minne en ny filbehandlingskomponent, VSAM , som ga lignende fasiliteter:

  • Entry-Sequanced Datasets (ESDS) ga fasiliteter som ligner på både sekvensielle og BDAM-datasett, siden de kan leses enten fra start til slutt eller direkte ved å spesifisere en forskyvning fra starten.
  • Nøkkelsekvenserte datasett (KSDS) var en stor oppgradering fra ISAM: de tillot sekundære nøkler med ikke-unike verdier og nøkler dannet ved å sammenkoble ikke-sammenhengende felt i hvilken som helst rekkefølge; de reduserte ytelsesproblemene sterkt forårsaket av overløpsposter i ISAM; og de reduserte risikoen sterkt for at en programvare- eller maskinvarefeil midt i en indeksoppdatering kan ødelegge indeksen.

Disse VSAM -formatene ble grunnlaget for IBMs databasesystemer , IMS/VS og DB2 - vanligvis ESDS for selve datalagringen og KSDS for indekser.

VSAM inkluderte også en katalogkomponent som ble brukt til brukerkataloger og MVS 'hovedkatalog.

Partisjonerte datasett (PDS) var sekvensielle datasett som er delt inn i "medlemmer" som hver kan behandles som sekvensielle filer i seg selv (som en mappe i et hierarkisk filsystem). Den viktigste bruken av PDSer var for programbiblioteker - systemadministratorer brukte hoved PDS som en måte å tildele diskplass til et prosjekt, og prosjektgruppen opprettet og redigerte deretter medlemmene. Andre bruksområder av PDS -er var biblioteker med ofte brukte jobbkontrollprosedyrer (PROC -er) og "kopibøker" av programmeringsspråklige uttalelser, for eksempel postdefinisjoner som ble brukt av flere programmer.

Generasjonsdatagrupper (GDG -er) er grupper med lignende navngitte datasett, som kan refereres til med absolutt generasjonsnummer, eller ved en forskyvning fra den siste generasjonen. De ble opprinnelig designet for å støtte bestefar-far-sønn-sikkerhetskopieringsprosedyrer -hvis en fil ble endret, ble den endrede versjonen den nye "sønnen", den forrige "sønnen" ble "faren", den forrige "faren" ble "bestefaren" "og den forrige" bestefaren "ble slettet. Men man kan sette opp GDG -er med mer enn 3 generasjoner, og noen applikasjoner brukte GDG -er for å samle inn data fra flere kilder og mate informasjonen til ett program - hvert innsamlingsprogram skapte en ny generasjon av filen og det endelige programmet leste hele gruppen som en enkelt sekvensiell fil (ved ikke å spesifisere en generasjon i JCL ).

Moderne versjoner av MVS (f.eks. Z/OS) bruker datasett som beholdere for Unix -filsystemer sammen med fasiliteter for delvis integrering av dem. Det vil si at Unix -programmer som bruker fopen () kan få tilgang til et MVS -datasett, og en bruker kan tildele en Unix -fil som om det var et datasett, med noen begrensninger. Det hierarkiske filsystemet (HFS) (ikke å forveksle med Apples hierarkiske filsystem ) bruker en unik type datasett, mens det nyere z/OS filsystemet (zFS) (ikke forveksles med Sun's ZFS ) bruker en VSAM lineær data Sett (LDS).

Programmer som kjører på nettverkstilkoblede datamaskiner (for eksempel AS/400 ) kan bruke lokale datahåndteringsgrensesnitt til å åpne, administrere og få tilgang til VSAM-postorienterte filer ved å bruke klient-serverprodukter implementert i henhold til Distributed Data Management Architecture (DDM) . DDM er også grunnarkitekturen for MVS DB2 -serveren som implementerer Distributed Relational Database Architecture (DRDA).

Oppgraderinger til MVS

I tillegg til ny funksjonalitet som IBM la til med utgivelser og delutgivelser av OS/VS2, leverte IBM en rekke gratis Incremental Change Releases (ICR) og Selectable Units (SU) og ladbare programprodukter og feltutviklede programmer som IBM til slutt samlet som del av z/OS. Disse inkluderer:

  • ACF/TCAM (5735-RCl)
  • ACF/VTAM (5746-RC3, 5735-RC2)
  • Datafasilitet/enhetsstøtte (DF/DS), 5740-AM7
  • Data Facility Extended Function (DF/EF), 5740-XYQ
  • Data Facility/Data Set Services (DF/DSS), 5740-UT3.
  • Datafasilitet Sort, 5740-SM1
  • OS/VS2 MVS Sequential Access Method-Extended (SAM-E), 5740-AM3
  • MVS/370 Data Facility Product (DFP), 5665-295, erstatter
    • 5740-AM7 Data Facility Device Support (DFDS)
    • 5740-XYQ Data Facility Extended Function (DFEF)
    • 5740-AM3 sekvensiell tilgangsmetode utvidet (SAM-E)
    • 5740-AM8 Access Method Services Cryptographic Option
    • 5748-UT2 3800 verktøy uten nett
  • MVS/XA Data Facility Produktversjon 1 versjon 1, 5665-284
  • MVS/XA Data Facility Produktversjon 2 versjon 1, 5665-XA2
  • MVS/ESA Data Facility Produktversjon 3, 5665-XA3
  • Data Facility Storage Management Subsystem (DFSMS), 5695-DF1
    Erstatter DFP, DF/DSS og DF/HSM
  • OS/VS2 MVS TSO kommandopakke (5740-XT6)
  • TSO Command Processor - FDP 5798 -AYF (PRINT kommando)
  • TSO/VS2 programmeringskontrollanlegg - FDP 5798 -BBJ
  • TSO Programming Control Facility - II (PCF II), FDP 5798 -CLW,
  • TSO Extensions
    Erstatter TSO Command Package, TSO Command Processor og PCF
    • 5665-285 for MVS/370
    • 5665-293 for MVS/XA
    • 5685-025 for MVS/XA
      Første versjon med REXX
  • OS/VS2 MVS/systemutvidelser, 5740-XEl
  • MVS/systemprodukt
    • JES3 versjon 1 5740-XYN
    • JES2 versjon 1 5740-XYS
    • MVS/System Product-JES2 versjon 2, 5740-XC6
    • MVS/System Product-JES3 versjon 2, 5665-291
    • MVS/System Product-JES2 versjon 3, 5685-001
    • MVS/System Product-JES3 versjon 3, 5685-002
    • MVS/ESA-systemprodukt: JES2 versjon 4, 5695-047
    • MVS/ESA-systemprodukt: JES3 versjon 4, 5695-048
    • MVS/ESA-systemprodukt: JES2 versjon 5, 5655-068
    • MVS/ESA-systemprodukt: JES3 versjon 5, 5655-069

Data Facility Product (DFP)

På slutten av syttitallet og begynnelsen av åttitallet kunngjorde IBM:

  • 5740-AM7 Data Facility Device Support (DF/DS)
  • 5740-XYQ Data Facility Extended Function (DF/EF)
  • 5740-AM3 sekvensiell tilgangsmetode utvidet (SAM-E)
  • 5740-AM8 Access Method Services Cryptographic Option
  • 5748-UT2 3800 verktøy uten nett

DF/DS la til ny enhetsstøtte, og IBM kunngjorde at den ikke lenger ville legge til enhetsstøtte til den gratis basen. DF/EF la til Improved Catalog Structure (ICF) som et alternativ til VSAM -kataloger og kontrollvolumer (CVOL -er), men den var full av pålitelighetsproblemer.

Da IBM kunngjorde MVS/SP versjon 2 (MVS/XA), kunngjorde den også Data Facility Product ™ (DFP ™) som en erstatning for og oppgradering til de fem andre produktene ovenfor, som den sa ville trekkes tilbake fra markedsføring fra 1. desember. , 1984. DFP/370 Release 1 (programnummer 5665-295), kunngjort 7. juni 1983, var for MVS/SP versjon 1, MVS/SE og OS/VS2 R3.8, og var valgfri, men MVS/Extended Architecture Data Facility Product (5665-284) var en grunnleggende forutsetning for MVS/SP versjon 2 (MVS/XA). I tillegg til å forbedre datahåndteringsfunksjonene, erstattet DFP gratisversjoner av koblingsredigereren og verktøyene.

Moderne MVS

MVS kjører på Hercules -emulatoren

MVS har nå utviklet seg til z/OS; eldre MVS-utgivelser støttes ikke lenger av IBM, og siden 2007 støttes bare 64-biters z/OS-utgivelser. z/OS støtter kjøring av eldre 24-biters og 31-biters MVS-applikasjoner sammen med nyere 64-biters applikasjoner.

MVS-utgivelser opp til 3,8j (24-bit, utgitt i 1981) var fritt tilgjengelige, og det er nå mulig å kjøre MVS 3.8j-utgivelsen i hovedrammeemulatorer gratis.

MVS/370

MVS/370 er et generisk begrep for alle versjoner av MVS -operativsystemet før MVS/XA. Den System / 370 Architecture, på det tidspunkt MVS ble frigjort, understøttet bare 24-bits virtuelle adresser, slik at MVS / 370 operativsystem -arkitektur er basert på en 24-bit adresse. På grunn av denne 24-biters adresselengden får programmer som kjører under MVS/370 hver 16 MB sammenhengende virtuell lagring.

MVS/XA

MVS/XA , eller Multiple Virtual Storage/Extended Architecture , var en versjon av MVS som støttet 370-XA- arkitekturen, som utvidet adresser fra 24 bits til 31 bits, og ga et 2  gigabyte adresserbart minneområde. Den støttet også en 24-biters eldre adresseringsmodus for eldre 24-biters applikasjoner (dvs. de som lagret en 24-biters adresse i de nedre 24 bitene i et 32-biters ord og brukte de øvre 8 bitene av det ordet til andre formål) .

MVS/ESA

MVS/ESA: MVS Enterprise System Architecture. Versjon av MVS, først introdusert som MVS/SP versjon 3 i februar 1988. Erstattet av/omdøpt til OS/390 sent 1995 og deretter som z/OS .

MVS/ESA OpenEdition: oppgradering til versjon 4 versjon 3 av MVS/ESA kunngjorde februar 1993 med støtte for POSIX og andre standarder. Mens den første utgivelsen bare hadde National Institute of Standards and Technology (NIST) -sertifisering for samsvar med Federal Information Processing Standard (FIPS) 151, ble etterfølgende utgivelser sertifisert på høyere nivåer og av andre organisasjoner, f.eks. X/Open og dens etterfølger, The Open Group . Den inkluderte omtrent 1 million nye kodelinjer, som gir et API -skall, verktøy og et utvidet brukergrensesnitt. Fungerer med et hierarkisk filsystem levert av DFSMS (Data Facility System Managed Storage). Skallet og verktøyene er basert på Mortice Kerns ' InterOpen -produkter. Uavhengige spesialister anslår at det var over 80% kompatibelt med åpne systemer-mer enn de fleste Unix-systemer. DCE2 -støtte kunngjorde februar 1994 og mange applikasjonsutviklingsverktøy i mars 1995. Siden midten av 1995, da alle de åpne funksjonene ble en standard del av vanilje MVS/ESA SP versjon 5 versjon 1, stoppet IBM å skille OpenEdition fra operativsystemet. Under OS/390 V2R6 ble det UNIX System Services , og har beholdt det navnet under z/OS .

OS/390

Hovedartikkel: OS/390

På slutten av 1995 samlet IBM MVS med flere programprodukter og endret navnet fra MVS/ESA til OS/390.

z/OS

Hovedartikkel: z/OS

Det nåværende nivået av MVS markedsføres som z/OS.

Nært beslektede operativsystemer

Japanske storprodusenter Fujitsu og Hitachi både gjentatte ganger og ulovlig innhentet IBMs MVS kildekode og intern dokumentasjon i en av det 20. århundrets mest berømte tilfeller av industrispionasje . Fujitsu stolte sterkt på IBMs kode i MSP -operativsystemet, og Hitachi gjorde det samme for sitt VOS3 -operativsystem. MSP og VOS3 ble sterkt markedsført i Japan, hvor de fremdeles har en betydelig andel av hovedrammen som er installert, men også til en viss grad i andre land, særlig Australia. Selv IBMs feil og feilstavinger i dokumentasjon ble trofast kopiert. IBM samarbeidet med det amerikanske føderale byrået for etterforskning i en stikkoperasjon , og forsyntet motstridende Fujitsu og Hitachi med proprietære MVS- og maskinvareteknologier i løpet av flerårige undersøkelser som kulminerte på begynnelsen av 1980-tallet-undersøkelser som involverte ledende selskaper og til og med noen japanske embetsmenn. Amdahl var imidlertid ikke involvert i Fujitsus tyveri av IBMs intellektuelle eiendom . All kommunikasjon fra Amdahl til Fujitsu var gjennom "Amdahl Only Specifications" som ble grundig renset for IBM -IP eller referanser til IBMs IP.

Etter undersøkelsene nådde IBM oppgjør på flere millioner dollar med både Fujitsu og Hitachi, og samlet betydelige brøkdeler av begge selskapenes fortjeneste i mange år. Pålitelige rapporter indikerer at bosetningene oversteg 500 000 000 dollar.

De tre selskapene har for lengst i minnelighet godtatt mange felles forretningsforetak. For eksempel samarbeidet IBM og Hitachi i 2000 om å utvikle IBM z900 mainframe -modellen.

På grunn av denne historiske kopieringen er MSP og VOS3 riktig klassifisert som "gafler" av MVS, og mange tredjeparts programvareleverandører med MVS-kompatible produkter klarte å produsere MSP- og VOS3-kompatible versjoner med liten eller ingen endring.

Da IBM introduserte sine 64-biters z/Architecture- hovedrammer i år 2000, introduserte IBM også 64-biters z/OS-operativsystemet, den direkte etterfølgeren til OS/390 og MVS. Fujitsu og Hitachi valgte ikke å lisensiere IBMs z/Architecture for sine kvasi-MVS-operativsystemer og maskinvaresystemer, og derfor beholder MSP og VOS3, selv om de fortsatt er nominelt støttet av sine leverandører, de fleste av MVSs 1980-talls arkitektoniske begrensninger til i dag. Siden z/OS fortsatt støtter applikasjoner og teknologier fra MVS-æra-z/OS inneholder fortsatt det meste av MVS-koden, om enn sterkt forbedret og forbedret gjennom flere tiår med utvikling-applikasjoner (og operasjonelle prosedyrer) som kjører på MSP og VOS3 kan flytte til z/OS mye lettere enn til andre operativsystemer.

Se også

Merknader

Referanser

  • Bob DuCharme: "The Operating Systems Handbook, Part 06: MVS" (tilgjengelig online her )
  • Oversikt over OS/VS2 MVS (PDF) . Første utgave. IBM. Juni 1978. GC28-0984-0. Arkivert fra originalen (PDF) 16. mars 2011.

Eksterne linker