OpenVMS - OpenVMS

OpenVMS
Vsi-openvms-logo.svg
DECwindows-openvms-v7.3-1.png
OpenVMS V7.3-1 som kjører den CDE -baserte DECwindows "New Desktop" GUI
Utvikler VMS Software Inc (VSI) (tidligere Digital Equipment Corporation , Compaq , Hewlett-Packard )
Skrevet inn Primært C , BLISS , VAX MACRO , DCL . Andre språk brukes også.
Arbeidstilstand Strøm
Kildemodell Lukket kildekode med åpen kildekode- komponenter, kilde tilgjengelig
Første utgivelse 25. oktober 1977 ; 43 år siden ( 1977-10-25 )
Siste utgivelse V8.4-2L3 / 8. april 2021 ; 6 måneder siden ( 2021-04-08 )
Siste forhåndsvisning V9.1-A / 30. september 2021 ; 16 dager siden ( 2021-09-30 )
Markedsføringsmål Servere (historisk minidatamaskiner , arbeidsstasjoner )
Tilgjengelig i Engelsk , japansk . Historisk støtte for kinesisk (både tradisjonelle og forenklede tegn), koreansk , thai .
Oppdateringsmetode Samtidig oppgraderinger,
rullende oppgraderinger
Pakkeleder PCSI og VMSINSTAL
Plattformer VAX , Alpha , Itanium , x86-64
Kernel typen Monolitisk kjerne med lastbare moduler
Påvirket VAXELN , MICA , Windows NT
Påvirket av RSX-11M
Standard
brukergrensesnitt		 DCL CLI og DECwindows GUI
Tillatelse Proprietær
Offesiell nettside www .vmssoftware .com

OpenVMS , ofte referert til som bare VMS , er et multi-user , multiprocessing virtuelt minnebasert operativsystem designet for å støtte tidsdeling , batchbehandling , transaksjonsbehandling og arbeidsstasjonsapplikasjoner . Det ble først kunngjort av Digital Equipment Corporation som VAX/VMS ( Virtual Address eXtension/Virtual Memory System ) sammen med minidatamaskinen VAX -11/780 i 1977. OpenVMS har senere blitt portet til å kjøre på DEC Alpha -systemer, den Itanium -baserte HPE Integrity Servere , og velg x86-64 maskinvare og hypervisorer . Siden 2014 er OpenVMS utviklet og støttet av et selskap ved navn VMS Software Inc. (VSI).

OpenVMS tilbyr høy tilgjengelighet gjennom gruppering og muligheten til å distribuere systemet over flere fysiske maskiner. Dette gjør at grupperte applikasjoner og data kan forbli kontinuerlig tilgjengelige mens operativsystemprogramvare og maskinvare vedlikehold og oppgraderinger utføres, eller når et helt datasenter blir ødelagt. VMS -klynge oppetid på 17 år er rapportert. Kunder som bruker OpenVMS inkluderer banker og finansielle tjenester, sykehus og helsetjenester, teleoperatører, nettverkstjenester og industrielle produsenter. I løpet av 1990- og 2000 -årene var det omtrent en halv million VMS -systemer i drift over hele verden.

Historie

Opprinnelse og navnendringer

Stilisert "VAX/VMS" brukt av Digital

I april 1975 begynte Digital Equipment Corporation på et maskinvareprosjekt, koden kalt Star , for å designe en 32-biters virtuell adresseutvidelse til PDP-11- datalinjen. Et ledsagerprogramvareprosjekt, koden Starlet , ble startet i juni 1975 for å utvikle et helt nytt operativsystem, basert på RSX-11M , for Star-prosessorfamilien. Disse to prosjektene var tett integrert fra begynnelsen. Gordon Bell var VP -leder for VAX -maskinvaren og arkitekturen. Roger Gourd var prosjektleder for Starlet program, med programvare ingeniører Dave Cutler (som senere skulle føre utviklingen av Microsoft 's Windows NT ), Dick Hustvedt , og Peter Lipman fungerer som de tekniske prosjektledere, som hver har ansvar for et annet område av operativsystemet. Star- og Starlet-prosjektene kulminerte med VAX-11/780- datamaskinen og VAX/VMS-operativsystemet. Starlet -navnet overlevde i VMS som et navn på flere av hovedsystembibliotekene, inkludert STARLET.OLBog STARLET.MLB.

"Albert the Cheshire Cat" maskot for VAX/VMS, brukt av DECUS VAX SIG

I september 1984 opprettet Digital en dedikert distribusjon av VMS ved navn MicroVMS for MicroVAX og VAXstation , som hadde betydelig mindre minne og diskplass enn større datidens VAX -systemer. MicroVMS delte opp VAX/VMS i flere sett, som en kunde kan bruke til å installere et delsett av VAX/VMS tilpasset deres spesifikke krav. MicroVMS -sett ble utgitt på TK50 -bånd og RX50 -disketter , tilsvarende VAX/VMS V4.0 til V4.7. MicroVMS ble slått tilbake til VAX/VMS i V5.0 -utgivelsen, da hadde muligheten til å tilpasse en VAX/VMS -installasjon kommet til et punkt der MicroVMS ble overflødig.

Fra 1989 ble en kortvarig distribusjon av VMS ved navn Desktop-VMS solgt med VAXstation- systemer. Den besto av en enkelt CD-ROM som inneholder en bunt med VMS, DECwindows, DECnet, VAXcluster-støtte og en oppsettprosess designet for ikke-tekniske brukere. Desktop-VMS hadde sitt eget versjonsprogram som begynte med V1.0, som tilsvarte V5.x-utgivelsene av VAX/VMS.

I juli 1992 omdøpte Digital VAX/VMS til OpenVMS som en indikasjon for sin støtte til "åpne systemer" bransjestandarder som POSIX og Unix -kompatibilitet, og for å avbryte VAX -tilkoblingen siden porten til Alpha var i gang. OpenVMS -navnet ble først brukt med OpenVMS AXP V1.0 -utgivelsen i november 1992. Digital begynte å bruke OpenVMS VAX i stedet for VAX/VMS med V6.0 -utgivelsen i juni 1993.

Port til DEC Alpha

Se også: DEC PRISM § Legacy , og DEC Alpha § History
"Vernon the Shark" -logoen for OpenVMS

I løpet av 1980 -årene planla Digital å erstatte VAX -plattformen og VMS -operativsystemet med PRISM -arkitekturen og MICA -operativsystemet. Da disse prosjektene ble kansellert i 1988, ble det opprettet et team for å designe nye VAX/VMS -systemer med sammenlignbar ytelse til RISC -baserte Unix -systemer. Etter en rekke mislykkede forsøk på å designe en raskere VAX-kompatibel prosessor, demonstrerte gruppen muligheten for å overføre VMS og dets applikasjoner til en RISC-arkitektur basert på PRISM. Dette førte til opprettelsen av Alpha -arkitekturen. Prosjektet for å port VMS til Alpha begynte i 1989, og ble først oppstartet på en prototype Alpha EV3 -basert Alpha Demonstration Unit i begynnelsen av 1991. Før tilgjengeligheten av Alpha -maskinvare ble Alpha -porten utviklet og startet opp på en emulator ved navn Mannequin , som implementert mange av Alpha -instruksjonene i tilpasset mikrokode på et VAX 8800 -system.

Hovedutfordringen ved å overføre VMS til en ny arkitektur var at VMS og VAX ble designet sammen, noe som betyr at VMS var avhengig av visse detaljer i VAX -arkitekturen. Videre ble en betydelig mengde av VMS-kjernen, lagdelte produkter og kundeutviklede applikasjoner implementert i VAX MACRO- monteringskoden. Noen av endringene som trengs for å koble VMS fra VAX -arkitekturen, inkluderer:

  • Opprettelsen av MACRO-32- kompilatoren, som behandlet VAX MACRO som et språk på høyt nivå , og kompilerte den til Alpha- objektkoden .
  • Opprettelsen av en binær oversetter til VAX til Alpha , kjent som VAX Environment Software Translator (VEST), som var i stand til å oversette VAX -kjørbare filer når det ikke var mulig å kompilere koden for Alpha på nytt.
  • Emuleringen av visse detaljer på lavt nivå om VAX-arkitekturen i PALcode , for eksempel avbruddshåndtering og atomkøinstruksjoner . Dette reduserte mengden VAX-avhengig kode som måtte skrives om for Alpha.
  • Konverteringen av VMS -kompilatorene, hvorav mange hadde sine egne skreddersydde VAX -kodegeneratorer, til å bruke en felles kompilator -backend ved navn GEM .

VMS -porten til Alpha resulterte i opprettelsen av to separate kildekodebiblioteker (basert på et kildekodehåndteringsverktøy kjent som VMS Development Environment , eller VDE) for VAX og for Alpha. Alpha-kodebiblioteket var basert på et øyeblikksbilde av VAX/VMS-kodebasen rundt V5.4-2. I 1992 ble den første versjonen av OpenVMS for Alpha AXP -systemer utgitt , betegnet OpenVMS AXP V1.0 . I 1994, med utgivelsen av OpenVMS V6.1, ble funksjons- (og versjonsnummer) paritet mellom VAX- og Alpha-variantene oppnådd, dette var den såkalte Functional Equivalence-utgivelsen. Beslutningen om å bruke 1.x-versjonsnumreringsstrømmen for kvalitetsutgivelser av pre-produksjon av OpenVMS AXP forårsaket forvirring for noen kunder, og ble ikke gjentatt i de påfølgende portene til OpenVMS til nye plattformer.

Da VMS ble portet til Alpha, ble det opprinnelig igjen som et 32-biters operativsystem. Dette ble gjort for å sikre bakoverkompatibilitet med programvare skrevet for 32-biters VAX. 64-biters adressering ble først lagt til for Alpha i V7.0-utgivelsen. For å la 64-biters kode samvirke med eldre 32-biters kode, skaper OpenVMS ikke et skille mellom 32-biters og 64-biters kjørbare filer, men tillater i stedet at både 32-biters og 64-biters pekere kan brukes innenfor samme kode. Dette er kjent som blandet pekersupport. 64-biters OpenVMS Alpha-utgivelser støtter en maksimal størrelse på virtuelt adresserom på 8TiB (et 43-biters adresserom), som er maksimumet som støttes av Alpha 21064 og Alpha 21164 .

En av de mer bemerkelsesverdige Alpha -funksjonene til OpenVMS var OpenVMS Galaxy - som tillot partisjonering av en enkelt SMP -server å kjøre flere forekomster av OpenVMS. Galaxy støttet dynamisk ressursallokering til kjørende partisjoner, og muligheten til å dele minne mellom partisjoner.

Port til Intel Itanium

"Swoosh" -logo brukt av HP for OpenVMS

I 2001, før oppkjøpet av Hewlett-Packard , kunngjorde Compaq havnen til OpenVMS for Intel Itanium- arkitekturen. Itanium-porten var et resultat av Compaqs beslutning om å avvikle fremtidig utvikling av Alpha-arkitekturen til fordel for å ta i bruk den da nye Itanium-arkitekturen. Porteringen begynte i slutten av 2001, og den første oppstarten fant sted 31. januar 2003. Den første oppstarten besto av å starte opp en minimal systemkonfigurasjon på en HP i2000 -arbeidsstasjon, logge på som SYSTEMbruker og kjøre DIRECTORYkommandoen. Itanium -porten til OpenVMS støtter spesifikke modeller og konfigurasjoner av HPE Integrity Servers . Itanium -utgivelsene fikk opprinnelig navnet HP OpenVMS Industry Standard 64 for Integrity Servers , selv om navnene OpenVMS I64 eller OpenVMS for Integrity Servers er mer vanlig.

Itanium -porten ble oppnådd ved hjelp av kildekoden som er vedlikeholdt til felles i OpenVMS Alpha kildekodebiblioteket, med tillegg av betinget kode og flere moduler der det var nødvendig med spesifikke endringer for Itanium. Mens VAX- og Alpha-arkitekturen var spesielt designet for å støtte behovene på lavt nivå til OpenVMS, var Itanium ikke det. Dette krevde at visse arkitektoniske avhengigheter til OpenVMS ble erstattet eller emulert i programvare. Noen av endringene inkluderer:

  • Den Extensible Firmware Interface (EFI) brukes for å starte OpenVMS på Integrity maskinvare, tar over rollen som System Reference Manual (SRM) firmware på Alpha. Støtte for ACPI ble også lagt til OpenVMS, siden dette brukes til å oppdage og administrere maskinvareenheter på Integrity -plattformen.
  • For Itanium ble funksjonaliteten som ble implementert ved hjelp av PALcode for Alpha flyttet inn i en komponent i OpenVMS -kjernen kalt Software Interrupt Services (SWIS).
  • Itanium -porten vedtok en ny kallestandard basert på Intels Itanium -ringekonvensjon , med utvidelser for å støtte OpenVMS Common Language Environment. Videre erstattet den OpenVMS-spesifikke kjørbare formater som ble brukt på VAX og Alpha med standard Executable and Linking Format (ELF) og DWARF- formater.
  • IEEE 754 ble vedtatt som standard flytende punktformat, og erstattet VAX flytende punktformat som var standard på både VAX- og Alpha -arkitekturen. For bakoverkompatibilitet er det mulig å kompilere kode på Itanium for å bruke VAX flytende punktformat, men det er avhengig av programvareemulering.
  • Operativsystemet ble modifisert for å støtte 50-biters fysisk adressering tilgjengelig på Itanium, slik at 1PiB minne kan adresseres. Itanium-porten beholdt ellers den blandede 32-biters/64-biters pekearkitekturen som ble introdusert i OpenVMS Alpha V7.0.

Som med VAX til Alpha -porten, ble en binær oversetter for Alpha til Itanium gjort tilgjengelig, slik at brukermodus OpenVMS Alpha -programvare kunne portes til Itanium i situasjoner der det ikke var mulig å kompilere kildekoden på nytt. Denne oversetteren er kjent som Alpha Environment Software Translator (AEST), og den støttet også oversettelse av VAX -kjørbare filer som allerede hadde oversatt med VEST.

To forhåndsproduksjoner, OpenVMS I64 V8.0 og V8.1, var tilgjengelige 30. juni 2003 og 18. desember 2003. Disse utgavene var beregnet for HP-organisasjoner og tredjepartsleverandører som var involvert i å overføre programvarepakker til OpenVMS I64 . Den første produksjonsutgivelsen, V8.2, ble utgitt i februar 2005. V8.2 ble også utgitt for Alpha, etterfølgende V8.x -utgivelser av OpenVMS har opprettholdt funksjonsparitet mellom Alpha- og Itanium -arkitekturen.

Port til x86-64

Da VMS Software Inc. (VSI) kunngjorde at de hadde sikret seg rettighetene til å utvikle OpenVMS-operativsystemet fra HP, kunngjorde de også at de hadde til hensikt å overføre OpenVMS til x86-64- arkitekturen. Porteringsinnsatsen gikk samtidig med etableringen av selskapet, samt utviklingen av VSIs egne Itanium- og Alpha-utgivelser av OpenVMS V8.4-x.

X86-64-porten er målrettet mot spesifikke servere fra HPE og Dell , samt visse hypervisorer for virtuelle maskiner . Den første støtten var målrettet mot KVM og VirtualBox . Støtte for VMware ble kunngjort i 2020, og Hyper-V har blitt beskrevet som et fremtidig mål. I 2021 ble det demonstrert at x86-64-porten kjørte på en Intel Atom- basert enbrett-datamaskin .

X86-64-porten er bygget fra det samme kildekodebiblioteket som Alpha- og Itanium-arkitekturen, og bruker betinget kompilering for å administrere den arkitekturspesifikke koden som trengs for å støtte x86-64-plattformen. Som med Alpha- og Itanium-portene, gjorde x86-64-porten noen endringer for å forenkle porting og støtte OpenVMS på den nye plattformen:

  • VSI tok i bruk åpen kildekode LLVM -kompilatorbackend, og erstattet den proprietære GEM -backend som ble brukt i Alpha- og Itanium -portene. En oversetter ble utviklet for å kartlegge GEM IR til LLVM IR, slik at de eksisterende kompilatorfrontene kan gjenbrukes. I tillegg ble Clang- kompilatoren med åpen kildekode vedtatt som den offisielt støttede C ++-kompilatoren for OpenVMS under x86-64.
  • På x86-64 bruker OpenVMS mer omfattende UEFI og ACPI for å oppdage og initialisere maskinvare ved oppstart. Som en del av dette blir VMS nå oppstartet fra en minnedisk, i stedet for den tradisjonelle VMS -oppstartsmekanismen - som var avhengig av oppstartsdrivere som inneholdt en grunnleggende implementering av filsystemet, og som var knyttet til spesifikke maskinvareenheter. Endringene i oppstartsprosessen nødvendiggjorde opprettelsen av en Dump Kernel - dette er en sekundær kjerne som lastes i bakgrunnen ved oppstartstidspunktet og påkalles i tilfelle OpenVMS trenger å skrive en krasjdump til disk.
  • OpenVMS forutsetter tilstedeværelse av fire maskinvaretilgjengelige rettighetsnivåer for å gi isolasjon mellom brukerprogrammer og forskjellige deler av operativsystemet. Mens x86-64 nominelt gir fire privilegienivåer, tilsvarer de bare to av privilegienivåene på VAX, Alpha og Itanium. I x86-64-porten utvides SWIS-modulen (Software Interrupt Services) i kjernen for å etterligne de manglende rettighetsnivåene.
  • Som med Itanium-porten, er kallestandarden for x86-64 en forlengelse av plattformens standardanropskonvensjon, spesielt System V AMD64 ABI . Visse egenskaper ved x86-64-arkitekturen skapte utfordringer for å definere en passende kallestandard. For eksempel, på grunn av det lille antallet generelle registre for x86-64, må MACRO-32-kompilatoren lagre innholdet i de emulerte VAX-registrene i en "pseudoregister" -struktur i minnet i stedet for å bruke prosessorens maskinvareregistre som er gjort på Alpha og Itanium.

Den første oppstarten ble kunngjort 14. mai 2019. Dette innebar å starte OpenVMS på VirtualBox og kjøre DIRECTORYkommandoen. Senere i 2019 ble den første "ekte oppstarten" kunngjort - denne besto av at operativsystemet startet på en helt standard måte, en bruker som logget seg på systemet og kjørte DIRECTORYkommandoen. I mai 2020 ble V9.0 Early Adopter's Kit -utgivelsen gjort tilgjengelig for et lite antall kunder. Dette besto av at OpenVMS-operativsystemet kjørte i en VirtualBox VM med visse begrensninger-mest signifikant var få lagdelte produkter tilgjengelige, og kode kan bare kompileres for x86-64 ved hjelp av krysskompilatorer som kjører på Itanium-baserte OpenVMS-systemer. Etter V9.0 -utgivelsen ga VSI ut en rekke oppdateringer månedlig eller halvårlig som la til ekstra funksjonalitet og hypervisorstøtte. Disse ble betegnet V9.0-A til V9.0-H. I juni 2021 ga VSI ut V9.1 Field Test, som er tilgjengelig for VSIs kunder og partnere. V9.1 leveres som et ISO-bilde som kan installeres på en rekke hypervisorer og på HPE ProLiant DL380- servere som starter med V9.1-A-versjonen.

Arkitektur

Arkitekturen til OpenVMS -operativsystemet, som demonstrerer systemlagene og tilgangsmodusene de vanligvis kjører i

OpenVMS-operativsystemet har en lagdelt arkitektur, som består av en privilegert Executive , en kommandospråktolk som kjører på et mellomliggende nivå av privilegier, og verktøy og kjøretidsbiblioteker (RTL) som kjører i en uprivilegiert modus, men potensielt kan kjøres på et høyere privilegium hvis du har tillatelse til det. Uprivilegert kode påkaller vanligvis funksjonaliteten til Executive gjennom systemtjenester (tilsvarende systemanrop i andre operativsystemer).

OpenVMS 'lag og mekanismer er bygget rundt visse funksjoner i VAX -arkitekturen, inkludert:

Disse VAX-arkitekturmekanismene implementeres på Alpha, Itanium og x86-64 ved enten å kartlegge til tilsvarende maskinvaremekanismer på disse arkitekturen, eller gjennom emulering (via PALcode på Alpha, eller i programvare på Itanium og x86-64).

Executive og Kernel

OpenVMS Executive består av den privilegerte koden og datastrukturer som befinner seg i systemområdet. Executive er videre delt mellom kjernen , som består av koden som kjører i kjernetilgangsmodus, og den mindre priviligerte koden utenfor kjernen som kjører i modusen for eksekutiv tilgang.

Komponentene i Executive som kjører i executive access -modus inkluderer Record Management Services og visse systemtjenester som bildeaktivering. Hovedforskjellen mellom kjernemodus og executive access -modus er at de fleste operativsystemets kjernedatastrukturer kan leses fra executive -modus, men krever at kjernemodus skrives til. Kode som kjører i executive -modus kan bytte til kjernemodus etter ønske, noe som betyr at barrieren mellom kjernen og executive -modus er ment som en beskyttelse mot utilsiktet korrupsjon i motsetning til en sikkerhetsmekanisme.

Den kjernen omfatter operativsystemets sentrale datastrukturer (f.eks sidetabeller, I / O-database, og å planlegge data), og rutinene som opererer på disse strukturene. Kernen beskrives vanligvis som å ha tre store delsystemer: I/O, Process and Time Management, Memory Management. I tillegg implementeres annen funksjonalitet som logisk navnebehandling, synkronisering og systemtjenesteutsendelse inne i kjernen.

Utøvende struktur

I tidlige versjoner av VAX/VMS ble det meste av Executive -koden knyttet til et enkelt kjørbart bilde med navnet SYS.EXE. VAX/VMS 5.0 introduserte Modular Executive , som delte Executive -koden i et antall executive -bilder (også kjent som execlets ) som lastes inn under systemstartstrap. SYS.EXEble værende, men ble redusert til vektorer for systemtjenester, statiske minnelokasjoner for data som er felles for flere executive -bilder og noen grunnleggende støttekode. På OpenVMS for Alpha, Itanium og x86-64, SYS.EXEer delt inn i henholdsvis SYS$BASE_IMAGE.EXEog SYS$PUBLIC_VECTORS.EXEsom inneholder delte minneplasseringer og støttekode, og systemtjenestens utsendelseslogikk.

Utvidelsesmekanismer

OpenVMS lar brukermoduskode med passende privilegier bytte til henholdsvis executive- eller kjernemodus ved hjelp av $CMEXECog og $CMKRNLsystemtjenester. Dette gjør at kode utenfor systemområdet kan ha direkte tilgang til lederens rutiner og systemtjenester. I tillegg til å tillate tredjeparts utvidelser til operativsystemet, brukes Privileged Images av kjerneoperativsystemverktøy for å manipulere operativsystemets datastrukturer gjennom udokumenterte grensesnitt.

OpenVMS tillater også delbare bilder (dvs. delte biblioteker ) å få privilegium, slik at det kan opprettes brukerskrevne systemtjenester , som er privilegerte rutiner som kan kobles til et ikke-privilegert program. Brukerskrevne systemtjenester påkalles ved hjelp av den samme mekanismen som vanlige systemtjenester, noe som forhindrer at det uprivilegerte programmet får privilegiene til koden i det privilegerte delbare bildet. Til tross for hva navnet antyder, brukes brukerskrevne systemtjenester også for å implementere sjeldent brukte operativsystemfunksjoner, for eksempel volummontering.

OpenVMS tilbyr et enhetsdrivergrensesnitt , som gjør det mulig å legge til nye I/O -enheter i operativsystemet.

Filsystem

Hovedartikler: Files-11 og Record Management Services

OpenVMS tilbyr funksjonsrike fasiliteter for filbehandling. Det typiske bruker- og applikasjonsgrensesnittet i filsystemet er Record Management Services (RMS), selv om applikasjoner kan grensesnitt direkte med det underliggende filsystemet gjennom QIO -systemtjenestene . RMS støtter flere postorienterte filtilgangsmetoder og postformater (inkludert fast lengde, variabel lengde og et strømformat der filen behandles som en byte-strøm, lik Unix). RMS støtter også ekstern filtilgang via DECnet, og valgfri støtte for journalføring .

Filsystemene som støttes av VMS omtales som Files-11 On-Disk Structures (ODS), som gir disk-kvoter , tilgangskontrollister og filversjonering . De viktigste strukturnivåene er ODS-2 , som er det originale VMS-filsystemet, og ODS-5 , som utvider ODS-2 med støtte for Unicode- filnavn, saksfølsomhet , harde lenker og symbolske lenker . VMS har også tilgang til filer på ISO 9660 CD-ROM-plater og magnetbånd med ANSI-tapeetiketter .

Ved siden av OpenVMS Alpha V7.0-utgivelsen i 1995, ga Digital ut et loggstrukturert filsystem ved navn Spiralog som var ment som en potensiell etterfølger til Files-11. Spiralog ble levert som et valgfritt produkt, og ble avviklet ved utgivelsen av OpenVMS Alpha 7.2. Spiralogs seponering skyldtes en rekke problemer, inkludert problemer med håndtering av hele volumer. Utviklerne av Spiralog begynte arbeidet med et nytt filsystem i 1996, som ble satt på vent og senere ble gjenopptatt av VSI i 2016 som VMS Advanced File System (VAFS, for ikke å forveksle med Digital's AdvFS for Tru64 ). VAFS vises ikke lenger på de siste veikartene, og i stedet har VSI diskutert porting av GFS2 -filsystemet med åpen kildekode til OpenVMS. En av de viktigste motivasjonene for å erstatte Files-11-strukturene er at de er begrenset til 2TiB-volumer.

Kommandospråktolk

En OpenVMS Command Language Interpreter (CLI) implementerer et kommandolinjegrensesnitt for OpenVMS; ansvarlig for å utføre individuelle kommandoer, samt kommandoprosedyrer (tilsvarende skallskript eller batchfiler ). Standard CLI for OpenVMS er DIGITAL Command Language , selv om andre alternativer også er tilgjengelige.

I motsetning til Unix -skall , som vanligvis kjøres i sin egen isolerte prosess og oppfører seg som alle andre brukermodusprogrammer, er OpenVMS CLIer en valgfri komponent i en prosess, som eksisterer sammen med et kjørbart bilde som prosessen kan kjøre. Mens et Unix-skall vanligvis kjører kjørbare filer ved å opprette en egen prosess ved hjelp av fork-exec , vil en OpenVMS CLI vanligvis laste det kjørbare bildet inn i samme prosess, overføre kontroll til bildet og sikre at kontrollen overføres tilbake til CLI når bildet har avsluttet og at prosessen er returnert til sin opprinnelige tilstand. En CLI blir kartlagt i en prosess private adresserom gjennom utførelse av LOGINOUTbildet, som enten kan utføres manuelt eller automatisk av visse systemtjenester for prosessopprettelse.

På grunn av at CLI er lastet inn i samme adresserom som brukerkode, og at CLI er ansvarlig for å påkalle bildeaktivering og bildeoversikt, blir CLI kartlagt i prosessadresserommet i tilgangstilstand for veileder. Dette er for å forhindre utilsiktet eller ondsinnet manipulering av CLIs kode og datastrukturer etter brukermoduskode.

Funksjoner

VAXstation 4000 modell 96 som kjører OpenVMS V6.1, DECwindows Motif og NCSA Mosaic -nettleseren

Brukergrensesnitt

VMS ble opprinnelig designet for å bli brukt og administrert interaktivt ved hjelp av Digitals tekstbaserte videoterminaler som VT100 , eller papirkopieringsterminaler som DECwriter- serien. Siden introduksjonen av VAXstation -linjen i 1984 har VMS valgfritt støttet grafiske brukergrensesnitt for bruk med arbeidsstasjoner eller X -terminaler .

Kommandolinjegrensesnitt

Hovedartikkel: DIGITAL Command Language
OpenVMS Alpha V8.4-2L1, som viser DCL CLI i en terminaløkt

Den DIGITAL Command Language har fungert som den primære CLI av VMS siden den første utgivelsen. Andre offisielle CLI-er tilgjengelig for VMS inkluderer RSX-11 MCR (bare VAX) og forskjellige Unix-skall . Digital gitt verktøy for å lage tekst-baserte brukergrensesnitt programmer - den Form Management System (FMS) og Terminal Data Management System (TDMS), senere etterfulgt av DECforms . Et grensesnitt på lavere nivå med navnet Screen Management Services (SMG $), som kan sammenlignes med Unix -forbannelser , finnes også.

Grafiske brukergrensesnitt

VWS 4.5 kjører på toppen av VAX/VMS V5.5-2
DECwindows XUI vindusbehandling som kjører på toppen av VAX/VMS V5.5-2

Gjennom årene har VMS gått gjennom en rekke forskjellige GUI -verktøy og grensesnitt:

  • Det originale grafiske brukergrensesnittet for VMS var et proprietært vindussystem kjent som VMS Workstation Software (VWS), som først ble utgitt for VAXstation I i 1984. Det avslørte et API kalt User Interface Services (UIS). Den kjørte på et begrenset utvalg av VAX -maskinvare.
  • I 1989 erstattet DEC VWS med et nytt X11 -basert vindussystem kalt DECwindows . Den ble først inkludert i VAX/VMS V5.1. Tidlige versjoner av DECwindows inneholdt et grensesnitt bygget på toppen av en proprietær verktøykasse som heter X User Interface (XUI). Et lagdelt produkt ved navn UISX ble levert for å la VWS/UIS -applikasjoner kjøre på toppen av DECwindows.
  • I 1991 erstattet DEC XUI med Motif -verktøysettet , og skapte DECwindows Motif . Som et resultat ble Motif Window Manager standard DECwindows -grensesnitt i OpenVMS V6.0, selv om XUI -vindusbehandleren forble som et alternativ.
  • I 1996, som en del av OpenVMS V7.1, ga DEC ut New Desktop -grensesnittet for DECwindows Motif, basert på Common Desktop Environment . På Alpha- og Itanium-systemer er det fortsatt mulig å velge det eldre MWM-baserte brukergrensesnittet (referert til som "DECwindows Desktop") ved påloggingstid. Det nye skrivebordet ble aldri portet til VAX -utgivelsene av OpenVMS.

Versjoner av VMS som kjørte på DEC Alpha -arbeidsstasjoner på 1990 -tallet støttet OpenGL og Accelerated Graphics Port (AGP) grafikkort. VMS gir også støtte for eldre grafikkstandarder som GKS og PHIGS . Moderne versjoner av DECwindows er basert på X.Org Server .

Gruppering

Hovedartikkel: VMScluster

OpenVMS støtter clustering (først kalt VAXcluster og senere VMScluster ), der flere systemer kjører sin egen forekomst av operativsystemet, men deler disklagring, behandling, en distribuert låsebehandling , et felles administrasjons- og sikkerhetsdomene, jobbkøer og utskriftskøer, som gir en enkelt systembildeabstraksjon . Systemene er koblet til enten av proprietær spesialisert maskinvare (Cluster Interconnect) eller et industristandard Ethernet LAN . OpenVMS støtter opptil 96 noder i en enkelt klynge, og tillater klynger med blandet arkitektur, der VAX- og Alpha-systemer, eller Alpha- og Itanium-systemer kan eksistere i en enkelt klynge. VMS -klynger tillater opprettelse av applikasjoner som tåler planlagte eller ikke -planlagte avbrudd i en del av klyngen.

Nettverk

Hovedartikkel: DECnet

Digitals DECnet -protokollpakke er tett integrert i VMS, slik at ekstern pålogging, samt transparent tilgang til filer, skrivere og andre ressurser på VMS -systemer over et nettverk, kan åpnes. Moderne versjoner av VMS støtter både den tradisjonelle Phase IV DECnet-protokollen, så vel som den OSI-kompatible Phase V (også kjent som DECnet-Plus ). Støtte for TCP/IP tilbys av de valgfrie TCP/IP -tjenestene for OpenVMS -lagdelt produkt (opprinnelig kjent som VMS/ULTRIX -tilkoblingen , deretter som ULTRIX Communications Extensions eller UCX). TCP/IP Services er basert på en port i BSD -nettverksstakken til OpenVMS, sammen med støtte for vanlige protokoller som SSH , DHCP , FTP og SMTP . På grunn av det faktum at den offisielle TCP/IP -stakken ikke ble introdusert før i 1988, og det begrensede funksjonssettet for de tidlige versjonene, ble det laget flere tredjeparts TCP/IP -stabler for VMS. Noen av disse produktene forblir under aktiv utvikling, for eksempel TCPware og MultiNet .

Digital solgte en programvarepakke ved navn PATHWORKS (opprinnelig kjent som Personal Computer Systems Architecture eller PCSA) som tillot personlige datamaskiner som kjører MS-DOS , Microsoft Windows eller OS/2 , eller Apple Macintosh å tjene som en terminal for VMS-systemer, eller bruke VMS -systemer som en fil- eller utskriftsserver. PATHWORKS var basert på LAN Manager og støttet enten DECnet eller TCP/IP som en transportprotokoll. PATHWORKS ble senere omdøpt til Advanced Server for OpenVMS , og ble til slutt erstattet med en VMS -port på Samba på tidspunktet for Itanium -porten.

Digital leverte Local Area Transport (LAT) -protokollen som tillot eksterne terminaler og skrivere å bli koblet til et VMS -system via en terminalserver som en av DECserver -familien.

Programmering

Digital (og dets etterfølgerbedrifter) ga et bredt spekter av programmeringsspråk for VMS. Offisielt støttede språk på VMS, enten nåværende eller historiske, inkluderer:

Blant OpenVMSs bemerkelsesverdige funksjoner er Common Language Environment , en strengt definert standard som spesifiserer kallkonvensjoner for funksjoner og rutiner, inkludert bruk av stabler , registre osv., Uavhengig av programmeringsspråk. På grunn av dette er det mulig å kalle en rutine skrevet på ett språk (for eksempel Fortran) fra et annet (for eksempel COBOL), uten å måtte vite implementeringsdetaljene for målspråket. OpenVMS selv er implementert på en rekke forskjellige språk og det vanlige språkmiljøet, og kallestandarden støtter fritt blande av disse språkene. Digital opprettet et verktøy som heter Structure Definition Language (SDL), som gjorde det mulig å generere datatypedefinisjoner for forskjellige språk fra en felles definisjon.

Utviklingsverktøy

Den "grå veggen" av VAX/VMS -dokumentasjon, på Living Computers: Museum + Labs

Digital ga en samling programvareutviklingsverktøy i et lagdelt produkt ved navn DECset (opprinnelig kalt VAXset ). Dette besto av Language-Sensitive Editor (LSE), et versjonskontrollsystem ( Code Management System eller CMS), et byggeverktøy ( Module Management System eller MMS), en statisk analysator ( Source Code Analyzer eller SCA), en profiler ( Performance and Coverage Analyzer eller PCA) samt en testansvarlig ( Digital Test Manager eller DTM). I tillegg er en rekke tekstredigerere inkludert i operativsystemet, inkludert EDT , EVE og TECO .

OpenVMS Debugger støtter alle DEC -kompilatorer og mange tredjeparts språk. Det tillater bruddpunkter, overvåkningspunkter og interaktiv kjøring av programfeilsøking enten ved hjelp av en kommandolinje eller et grafisk brukergrensesnitt . Et par feilsøkere på lavere nivå, kalt DELTA og XDELTA , kan brukes til å feilsøke privilegert kode i tillegg til normal applikasjonskode.

I 2019 ga VSI ut et offisielt støttet integrert utviklingsmiljø for VMS basert på Visual Studio Code . Dette gjør at VMS -applikasjoner kan utvikles og feilsøkes eksternt fra en Microsoft Windows- , macOS- eller Linux -arbeidsstasjon.

Database ledelse

Digital opprettet en rekke valgfrie databaseprodukter for VMS, hvorav noen ble markedsført som VAX Information Architecture -familien. Disse produktene inkluderte:

I 1994 solgte Digital Rdb, DBMS og CDD til Oracle , hvor de fortsatt er under aktiv utvikling. I 1995 solgte Digital DSM til InterSystems , som omdøpte det til Open M , og til slutt erstattet det med deres Caché -produkt.

Eksempler på tredjeparts databasesystemer for OpenVMS inkluderer MariaDB , Mimer SQL og System 1032 .

Sikkerhet

OpenVMS tilbyr forskjellige sikkerhetsfunksjoner og -mekanismer, inkludert sikkerhetsidentifikatorer, ressursidentifikatorer, undersystemidentifikatorer, ACL -er , inntrengingsdeteksjon og detaljert sikkerhetsrevisjon og alarmer. Spesifikke versjoner evaluert ved Trusted Computer System Evaluation Criteria Class C2 og med SEVMS sikkerhetsforbedret utgivelse i klasse B1. OpenVMS har også en ITSEC E3 -vurdering (se NCSC og Common Criteria ). Passord blir hasket med Purdy Polynomial .

Sårbarheter

  • Tidlige versjoner av VMS inkluderte en rekke privilegerte brukerkontoer (inkludert SYSTEM, FIELD, SYSTESTog DECNET) med standard passord som ofte ble forlatt uendret av systemadministratorer. En rekke datamaskinsormer for VMS, inkludert WANK -ormen og julemannen, utnyttet disse standardpassordene for å få tilgang til noder på DECnet -nettverk. Dette problemet ble også beskrevet av Clifford Stoll i The Cuckoo's Egg som et middel der Markus Hess fikk uautorisert tilgang til VAX/VMS -systemer. I V5.0 ble standardpassordene fjernet, og det ble obligatorisk å oppgi passord for disse kontoene under systemoppsettet.
  • En 33 år gammel sårbarhet i VMS på VAX og Alpha, ble oppdaget i 2017 og ble tildelt CVE-IDen CVE - 2017-17482 . På de berørte plattformene tillot denne sårbarheten en angriper med tilgang til DCL -kommandolinjen å utføre et opptrappingsrettighetsangrep . Sårbarheten er avhengig av å utnytte en bufferoverløpsfeil i DCL -kommandoens behandlingskode, muligheten for en bruker til å avbryte et kjørende bilde (program kjørbart ) med CTRL/Yog gå tilbake til DCL -ledeteksten, og det faktum at DCL beholder privilegiene til det avbrutte bildet . Bufferoverløpsfeilen tillot shellcode å bli utført med privilegiene til et avbrutt bilde. Dette kan brukes i forbindelse med et bilde installert med høyere rettigheter enn angriperens konto for å omgå systemsikkerhet.

Kompatibilitet på tvers av plattformer

VAX/VMS inkluderte opprinnelig et RSX-11M- kompatibilitetslag kalt RSX Application Migration Executive (RSX AME) som tillot brukermodus RSX-11M-programvare å kjøre uendret på toppen av VMS. Dette var avhengig av PDP-11-kompatibilitetsmodus implementert i VAX-11- prosessorene. RSX AME spilte en viktig rolle på tidlige versjoner av VAX/VMS, som brukte gjenbrukte visse RSX-11M brukerplassverktøy før opprinnelige VAX-versjoner hadde blitt utviklet. Dette ble avviklet i VAX/VMS V3.0 da alle kompatibilitetsmodus -verktøy ble erstattet med opprinnelige implementeringer. I VAX/VMS V4.0 ble RSX AME fjernet fra basissystemet og erstattet med et valgfritt lagdelt produkt ved navn VAX-11 RSX , som stolte på programvareemulering for å kjøre PDP-11-kode på nyere VAX-prosessorer. En VAX-port på RTEM- kompatibilitetslaget for RT-11- applikasjoner var også tilgjengelig fra Digital.

Ulike offisielle Unix- og POSIX -kompatibilitetslag ble opprettet for VMS. Den første var DEC/Shell - som var et lagdelt produkt bestående av port av versjon 7 Unix Bourne -skallet og flere andre Unix -verktøy til VAX/VMS. I 1992 ga Digital ut POSIX for OpenVMS -lagdelt produkt, som inkluderte et skall basert på Korn Shell . POSIX for OpenVMS ble senere erstattet av åpen kildekode GNV ( GNU 's not VMS) -prosjektet, som først ble inkludert i OpenVMS -medier i 2002. Blant andre GNU -verktøy inkluderer GNV en port av Bash -skallet til VMS. Eksempler på tredjeparts Unix -kompatibilitetslag for VMS inkluderer Eunice .

Digital lisensiert SoftPC (og senere SoftWindows), og solgte det som et lagdelt produkt for både VAX- og Alpha -arkitekturen, slik at Windows- og DOS -applikasjoner kan kjøres på toppen av VMS.

I 1995 kunngjorde Digital Affinity for OpenVMS (også kjent som NT Affinity ) som var ment å tillate OpenVMS å fungere som utholdenhetslaget for Windows NT klient-server-applikasjoner . Som en del av dette initiativet ble en implementering av Distributed Component Object Model (DCOM) lagt til OpenVMS Alpha, som først dukket opp i V7.2-1-utgivelsen.

Åpen kildekode -applikasjoner

Noen av de åpne kildeprogrammene som har blitt portet til OpenVMS inkluderer:

Det er en rekke samfunnsprosjekter for å overføre åpen kildekode-programvare til VMS, inkludert VMS-porter og GNV (GNU's Not VMS).

Hobbyistprogrammer

I 1997 ble OpenVMS og en rekke lagdelte produkter gjort gratis tilgjengelig for hobbyister, ikke-kommersiell bruk som en del av OpenVMS Hobbyist-programmet . Siden den gang har flere selskaper som produserer OpenVMS -programvare gjort produktene sine tilgjengelige under de samme vilkårene, for eksempel Process Software. Før x86-64-porten gjorde alderen og kostnaden for maskinvare som kunne kjøre OpenVMS at emulatorer som SIMH ble et vanlig valg for hobbyistinstallasjoner.

I mars 2020 kunngjorde HPE slutten av OpenVMS Hobbyist -programmet. Dette ble fulgt av VSIs kunngjøring av Community License Program (CLP) i april 2020, som var ment som en erstatning for HPE Hobbyist Program. CLP ble lansert i juli 2020, og gir lisenser for VSI OpenVMS -utgivelser på Alpha- og Integrity -systemer. OpenVMS x86-64 lisenser vil bli gjort tilgjengelig når en stabil versjon er utgitt for denne arkitekturen. OpenVMS for VAX dekkes ikke av CLP, siden det ikke er noen VSI -utgivelser av OpenVMS VAX, og de gamle versjonene fortsatt eies av HPE.

Innflytelse

I løpet av 1980 -årene var MICA -operativsystemet for PRISM -arkitekturen ment å bli den etterfølgeren til VMS. MICA ble designet for å opprettholde bakoverkompatibilitet med VMS -applikasjoner samtidig som den støtter Ultrix -applikasjoner på toppen av den samme kjernen. MICA ble til slutt kansellert sammen med resten av PRISM -plattformen, noe som førte til at Dave Cutler forlot Digital for Microsoft. Hos Microsoft ledet Cutler etableringen av Windows NT -operativsystemet, som var sterkt inspirert av arkitekturen til MICA. Som et resultat anses VMS som en stamfar til Windows NT , sammen med RSX-11 , VAXELN og MICA, og det finnes mange likheter mellom VMS og NT. Denne slekten blir tydeliggjort i Cutlers forord til "Inside Windows NT" av Helen Custer.

Et nå avsluttet prosjekt ved navn FreeVMS forsøkte å utvikle et operativsystem med åpen kildekode etter VMS-konvensjoner. FreeVMS ble bygget på toppen av L4-mikrokjernen og støttet x86-64- arkitekturen. Tidligere arbeid med å undersøke implementeringen av VMS ved bruk av en mikrokjernebasert arkitektur hadde tidligere blitt utført som en prototypeøvelse av DEC-ansatte med bistand fra Carnegie Mellon University ved å bruke Mach 3.0- mikrokjernen som ble portet til VAXstation 3100- maskinvare, ved å ta i bruk en arkitektonisk modell med flere servere.

En uoffisiell derivat av VAX / VMS heter MOS VP ( russisk : Многофункциональная операционная система с виртуальной памятью, МОС ВП , lyser  'Multifunksjonell Operativsystem med Virtual Memory') ble opprettet i Sovjetunionen på 1980-tallet for SM 1700 linjen VAX klon maskinvare. Hovedforskjellen mellom MOS VP og de offisielle digitale utgivelsene var oversettelse av kommandoer, meldinger og dokumentasjon til russisk, og støtte for det kyrilliske skriptet ved bruk av KOI-8- koding. Tilsvarende modifiserte derivater av MicroVMS kjent som MicroMOS VP ( russisk : МикроМОС ВП ) eller MOS-32M ( russisk : МОС-32М ) ble også opprettet.

Tidslinje for store utgivelser

Versjon Leverandør Utgivelsesdato Sluttdato Merknader
Gammel versjon, ikke lenger vedlikeholdt: X0.5 DES Sent 1977 ? Første versjon sendt til kunder
Gammel versjon, ikke lenger vedlikeholdt: V1.0 August 1978 ? Første produksjonsutgivelse
Gammel versjon, ikke lenger vedlikeholdt: V2.0 April 1980 ? VAX-11/750 . Nye verktøy inkludert EDT .
Gammel versjon, ikke lenger vedlikeholdt: V3.0 April 1982 ? VAX-11/730 , VAX-11/725 , VAX-11/782 , ASMP
Gammel versjon, ikke lenger vedlikeholdt: V4.0 September 1984 ? VAX 8600 , MicroVMS, VAXclusters
Gammel versjon, ikke lenger vedlikeholdt: V5.0 April 1988 ? VAX 6000 , SMP , LMF, Modular Executive
Gammel versjon, ikke lenger vedlikeholdt: V1.0 AXP November 1992 ? Første utgivelse for Alpha
Gammel versjon, ikke lenger vedlikeholdt: V6.0 Juni 1993 ? VAX 7000/10000 , TCSEC C2 -samsvar
Gammel versjon, ikke lenger vedlikeholdt: V6.1 April 1994 ? Sammenslåing av VAX og Alpha versjonsnumre
Gammel versjon, ikke lenger vedlikeholdt: V7.0 Desember 1995 Mars 1998 64-biters adressering på Alpha, Fast Path I/O
Gammel versjon, ikke lenger vedlikeholdt: V7.3 Compaq Juni 2001 Desember 2012 Endelig utgivelse for VAX
Gammel versjon, ikke lenger vedlikeholdt: V8.0 HP Juni 2003 Desember 2003 Evalueringsutgivelse for integritetsservere
Gammel versjon, ikke lenger vedlikeholdt: V8.2 Februar 2005 April 2014 Produksjonsutgivelse for Integrity og Alpha
Gammel versjon, ikke lenger vedlikeholdt: V8.4 Juni 2010 Desember 2020 Støtte for HPVM , klynger over TCP/IP
Eldre versjon, men likevel vedlikeholdt: V8.4-1H1 VSI Mai 2015 Desember 2022 Støtte for Poulson -prosessorer
Eldre versjon, men likevel vedlikeholdt: V8.4-2L1 September 2016 Desember 2024 OpenSSL oppdatert til 1.0.2
Januar 2017 TBA Første utgivelse for Alpha fra VSI
Eldre versjon, men likevel vedlikeholdt: V8.4-2L2 Juli 2017 TBA Endelig utgivelse for Alpha
Gjeldende stabil versjon: V8.4-2L3 April 2021 Desember 2028 Endelig utgivelse for Integrity Servers
Gammel versjon, ikke lenger vedlikeholdt: V9.0 Mai 2020 Juni 2021 x86-64 Early Adopter's Kit
Siste forhåndsversjon av en fremtidig utgivelse: V9.1 Juni 2021 H2 2021 x86-64 Felttest
Fremtidig utgivelse: V9.2 April 2022 Desember 2028 x86-64 Begrenset produksjonsutgivelse
Fremtidig utgivelse: V9.2-1 November 2022 Desember 2029 x86-64 Produksjonsutgivelse
Fremtidig utgivelse: V9.2-2 2023 TBA Forbedret klyngesikkerhet
Legende:
Gammel versjon
Eldre versjon, fortsatt vedlikeholdt
Siste versjon
Siste forhåndsversjon
Fremtidig utgivelse

Se også

Referanser

Videre lesning

Eksterne linker