vom OpenVMS-Fachberater Bob Gezelter
Ich bin gefragt worden "Warum OpenVMS wählen?"
Das ist eine berechtigte Frage. Während eine präzise Antwort vom Kontext abhängt, lautet die allgemeine Antwort:
"OpenVMS bietet eine robuste Plattform und ein robustes Framework zur Erstellung und zum Betreiben von Software."
Die Vorzüge von OpenVMS zeigen sich nicht nur während der Entwicklung, sondern während des gesamten Lebenszyklus des Systems. Test, Produktion, Verbesserung und andere Phasen des Zyklus profitieren alle. Kosten und Risiken werden über die Laufzeit des Systems reduziert.
Das ist eine wichtige Unternehmens-Angelegenheit und nicht nur eine technische Feinheit. Ein gut strukturiertes OpenVMS-System entwickelt sich viel reibungsloser als eines auf anderen Plattformen. Das wird offensichtlich, wenn Cluster eine durchgängige Verfügbarkeit der Applikation über Jahrzehnte aufrechterhalten, während sich sowohl Hard- wie auch Software weiterentwickeln. Die Cluster-Verfügbarkeit bleibt bestehen, trotz CPU-Upgrades, Änderungen der CPU-Architektur, Systemupdates und Änderungen bei Datenspeichern, Netzwerken und individuellen Applikationen. Die Benutzer könnten nicht einmal bemerken, dass sich etwas geändert hat.
Das läuft der gängigen Meinung zuwider, dass alle Betriebssysteme im Grunde gleich sind; was für Windows® and Unix®-Derivate zutrifft, müsse für alle Betriebssysteme gelten. Die Meinung ist in Mode gekommen, dass Betriebssysteme unwichtig sind, dass wir uns in einer Post-Betriebssystem-Welt befinden. Das wird oft von einem Kommentar begleitet wie "Frameworks und virtuelle Maschinen zählen". Das ist nicht die ganze Wahrheit.
Alle drei Begriffe sind schwamming definiert; es gibt erhebliche Überlappungen zwischen ihnen. Daher sagen die verbundenen Aussagen wenig aus. Framework ist eine relativ junge Wortschöpfung; selbst Wikipedia hat nur Zitate zurück bis in die 1990er. Virtuelle Maschine ist seit den frühen 1960ern in Gebrauch; es aber außerhalb eines Betriebssystem-Kontexts zu verwenden bedeutet, sich auf eine Klassifikations-Ablenkung einzulassen.
Frameworks sind wichtig. Aber zu behaupten, "OpenVMS hat keine Frameworks" ist falsch. OpenVMS beinhaltet, was andere diverse unabhängige, sich gegenseitig verstärkende Frameworks nennen würden, benennt sie aber nicht so. Das ist nicht überraschend, weil der Begriff Framework nicht im allgemeinen Gebrauch war, als VAX/VMS 1977 entworfen wurde.
In OpenVMS eingebaute Frameworks sind u.a. logische Namen, Input/Output und Lock-Management. Jedes deckt einen unterschiedlichen Aspekt der Programmierumgebung ab. Die Frameworks, die einander ergänzen, sind orthogonal, aber sorgfältig in das Ganze integriert. Anders als andere Betriebssysteme verwendet OpenVMS gemeinsame innere Komponenten über äußere Schnittstellen, ein Feature, das andere Systeme nicht nutzen.
Die erwähnten Frameworks ergänzen sich gegenseitig. Sie überschneiden sich, ohne sich zu überlappen. Sie sind i.allg. unabhängig voneinander. Zugrunde liegen bei allen die Mechanismen des Asynchronous System Trap (AST) und die Sicherheits-/Zugriffsschutz-Komponenten, die ebenfalls als Frameworks gelten könnten, aber fundamentalere Elemente von OpenVMS sind. Allerdings reichen ASTs sogar noch früher zurück und sind ein grundlegender Mechanismus, um die zugrundeliegende API zu erweitern, ein Feature, dass als entscheidend für ein Framework erachtet wird.
Diese Frameworks machen die wahre Mächtigkeit der OpenVMS-Architektur für gewöhnliche Applikations-Programme verfügbar. Die Mehrzahl der Applikationen benötigt die Erkenntnis nicht, dass sie im Cluster laufen (über die impliziten Garantien hinaus, die clusterweites Locking gibt). Während Locks auch direkt verwaltet werden können, werden sie überwiegend implizit als grundlegende Technologie durch die Record Management Services (RMS) verwendet.
OpenVMS zeigt, dass grundlegende Schnittstellen nicht völlständig durch äußere Schnittstellen gekapselt werden müssen. Die Erzeugung von ASTs und der Bereich der Sicherheit sind im direkten Zugriff von Programen, wie sich auch von anderen OpenVMS-Einrichtungen genutzt werden. Diese fundamentalen Schnittstellen sind direkt sichtbar, wie auch indirekt durch RMS-, Lock-Management- und Timer-Dienste.
Das Konzept der virtuellen Maschine wurde von IBMs Forschungslabor in Cambridge entwickelt, als Antwort auf eine Anfrage der Advanced Research Projects Agency (ARPA) nach einem EDV-Dienstprogramm. Das System, das später als MULTICS bekannt wurde (ein geistiger Vorfahre von OpenVMS) war der Konkurrenz-Vorschlag eines Teams am Massachusetts Institute of Technology (MIT).
Als ARPA den MIT-Vorschlag unterstützte, entschied sich IBM, sein Konzept einer virtuellen Maschine intern weiterzuverfolgen, was zur VM/370 führte.
OpenVMS führt das Konzept des virtuellen Benutzers weiter. Virtuelle Maschinen sind ein anderes, komplementäres Konzept. In Kombination verwendet, eröffnen sie neue Möglichkeiten für flexible und effiziente IT-Operationen, wie ich in meinem kürzlichen Vortrag Evolving OpenVMS Environments: An Exercise in Continuous Computing ausgeführt habe. Ein weiteres Eingehen auf diese Abschweifung behalte ich mir für eine zukünftige Kolumne vor.
Diese nicht-überlappende Überschneidung zwischen virtualisierter Hardware und virtuellen Umgebungen hat sehr pragmatische Implikationen. Zum Beispiel hatte kürzlich ein Klient mit einem offensichtlichen Hardwareversagen in einem in die Jahre gekommenen Platten-Array zu tun. Eine unkomplizierte Lösung war möglich durch die inhärente geräte-unabhängige Art der OpenVMS-I/O im benutzer-virtualisierten Kontext.
Das Problem wurde behoben, indem eine logische Platte mit der gleichen Größe wie der kaputte Platten-Array in einem weiteren Speichergerät erzeugt wurde. Ich definierte einen logischen Namen, um alle Bezüge auf das kaputte Platten-Array auf die neu eingerichtete logische Platte umzuleiten. Damit war die Applikation wieder funktionsfähig.
Wenn ich gewollt hätte, hätte ich den logischen Namen für eine einzelne Gruppe, einen Benutzer, Prozess oder eine Applikation definieren können, wie in dem Artikel Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters beschrieben, der in der Ausgabe Februar 2004 des OpenVMS Technical Journal veröffentlicht worden ist.
Dies ist ein sehr grober Überblick. Zugegebenermassen existiert eine Fülle von feineren Details in diesem Gesamtbild, aber diese Einzelheiten sollten nicht von den grundlegenden Fakten ablenken.
In diesem Zusammenhang sollten auch die niedrigen Betriebskosten von OpenVMS erwähnt werden, wie in dem Whitepaper Total Cost of Ownership for Entry-Level and Mid-Range Clusters beschrieben.
OEMs und ISVs müssen Produkte an Kundenanlagen ausliefern, von mittlerer bis großen Größen, mit einer Vielzahl von Systemen. Das gilt auch für Firmen-IT-Abteilungen, die oft als firmeneigene ISVs oder OEMs fungieren. Im Ergebnis machen die Betriebskosten schnell den Löwenanteil der IT-Ausgaben aus.
Der einfachste Weg zur Kostensenkung ist es, die operative Komplexität zu verringern. Die Virtualisierung der Benutzerumgebung, wie sie OpenVMS zur Verfügung stellt, zusammen mit den darunterliegenden, in OpenVMS eingebauten Frameworks, bietet ein Fundament, das die Komplexität verringert. Diese Reduktion der Komplexität verhindert viele potentielle Probleme. Die schnellste Antwort auf ein Problem ist, es nie auftreten zu lassen. Um einen alten Film frei zu zitieren: "Wenn das Telefon je klingelt, haben wir versagt."
Auch bin ich sicher, dass ein richtig entworfenes System in der Lage ist, von einem kleinen Desktop mit einem Benutzer zu einer Umgebung der Betriebs-Klasse mit hunderten oder tausenden Benutzern ohne Änderungen an der Applikation zu skalieren. OpenVMS allein bietet diese beispiellose, nahtlose Applikations-Skalierbarkeit von einem einzelnen Desktop zu einer Betiebs-Umgebung mit tausenden von Benutzern, von denen jeder seine eigenen Anforderungen an Performance, Betrieb und Sicherheit hat.
Anders als virtuelle Maschinen, von denen jede getrennt gemanagt werden muss, kann ein OpenVMS-Cluster als eine Einheit verwaltet werden, mit einer erheblichen Kostenersparnis.
Ob Sie Entwickler oder Endbenutzer sind, die Wirtschaftlichkeit, Flexibilität und Verlässlichkeit von OpenVMS sind beeindruckend.
Leserfragen zur Verwendung von DCL und andere, auf OpenVMS bezogene Fragen sollten an OpenVMSConsultant (at) OpenVMS.org adressiert werden. Obwohl ich nicht versprechen kann, alle Nachrichten zu beantworten, werde ich es versuchen, wie es meine Zeit erlaubt. Der OpenVMS-Fachberater begrüßt Fragen von Lesern über OpenVMS und verwandte Technologien. Bitte senden Sie Ihre Fragen an den OpenVMS Consultant.
Windows® ist ein Warenzeichen der Microsoft Corporation
Unix® ist ein Warenzeichen von The Open Group
Über den Autor:
Robert Gezelter, CDP, CSA, CSE, Software Consultant, hat mehr als 30 Jahre internationale Erfahrung mit der Fachberatung im privaten und öffentlichen Sektor. Er ist regelmäßiger Gastredner auf technischen Konferenzen weltweit, einschließlich des HP Technology Forums. 2004 hat die IEEE Computer Society Mr. Gezelter in ihr Distinguished Visitors Program berufen, das Redner auf Veranstaltungen von IEEE-Verbänden in ganz Nordamerika vermittelt. Außerdem hat er zahlreiche technische Artikel und Buchkapitel verfasst, einschließlich zweier Kapitel in dem kürzlich erschienenen Computer Security Handbook, 5. Auflage.
Kürzlich hat er begonnen, Ruminations - An IT Blog über IT-Themen zu schreiben, die nicht mit OpenVMS in Verbindung stehen.
Die Tätigkeit seiner Firma betont detaillierte technische Expertise in den Bereichen Computer-Architekturen, Betriebssysteme, Netzwerke, Sicherheit, APIs und verwandte Themen. Mr. Gezelter hat mit OpenVMS seit der ersten Release von VAX/VMS 1977 gearbeitet.
Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international, mit Arbeitsbereichen, die von individuellen Telefon-Fragen bis zu größeren Projekten reichen.
Im Web ist er über den Website seiner Firma unter http://www.rlgsc.com zu erreichen.
Original auf www.openvms.org
|