Archiv der Kategorie: DEC VAX mit SIMH

Emulation der VAX-Reihe von Digital Equipment Corporation mit SIMH

Weitere Gedanken zu den DEC (Micro-) VAX Computern

Veröffentlicht am von
2

In den letzten Monaten haben sich noch ein paar Gedanken zum Thema DEC (Micro-) VAX in meinem Kopf angesammelt, die ich als Nachtrag zu meiner Artikelserie ‚Emulation einer VAX mit SIMH‘ wenigstens auch noch einmal ausformuliert haben wollte.

Zum einen habe ich mal so etwas wie einen Benchmark durchgeführt, in dem ich die Zeit gemessen und verglichen habe, wie lange der Boot-Vorgang mit der emulierten MicroVAX 3800/3900 unter OpenVMS, Ultrix und NetBSD dauert.
Die Kriterien für den „Benchmark“ waren folgende:

  • In der Zeitmessung wird der Selbsttest der Firmware der Zentraleinheit mit dem RAM-Check, der nach dem Einschalten als erstes erfolgt, nicht berücksichtigt. Es wird also nur die Zeit ab dem Bootvorgang des Betriebssystems von der Festplatte bis zum Login-Prompt gemessen.
  • Bei allen drei Betriebssystemen wird keine grafische Benutzeroberfläche geladen. Der Login erfolgt nur auf der Kommandozeile.
  • OpenVMS wird in der letzten für die VAX-Architektur unterstützten Version 7.3 aus dem Jahr 2001 gebootet. (Open-) VMS war das Betriebssystem, welches für und mit der VAX-Architektur in den späten 1970er Jahren durch DEC in den Markt eingeführt wurde. Bei dem Bootvorgang wird auf das Starten von Systemhintergrunddiensten im Wesentlichen voll verzichtet. Es wurde auch kein Netzwerk in der Emulation eingerichtet. Kein DECnet, geschweige den TCP/IP.
  • Ultrix wird in der von DEC letzten veröffentlichten Version 4.5 ausgeführt. Diese erschien im Herbst 1995. Das Netzwerk wurde, soweit es mit den heutigen unter TCP/IP in Version 4 Standard noch kompatibel ist, statisch konfiguriert. Mit dem Bootvorgang werden auch die für Unix-typischen Standarddienste wie Cron, Accounting, Network und SNMPD gestartet.
  • NetBSD wird in der aktuellen Version 9.2 vom Mai 2021 ausgeführt. Als Dienste werden der DHCP-Client-Daemon, inetd, Cron, der Postfix und der SSH-Server während des Bootvorgangs gestartet. Allerdings wurden für den SSH-Server die Schlüssel bereits zuvor generiert. Eine Datenträgerüberprüfung mit fsck wurde aber vermieden.

Als wirklich arbeitsbereit kann hier nur die Installation von NetBSD angesehen werden. NetBSD ist außerdem das einzige Betriebssystem, welches für die VAX-Architektur noch weiter entwickelt wird, somit den heutigen Netzwerkstandards entspricht und dadurch auch moderne Entwicklungen im Bereich Betriebssysteme auf diese inzwischen historische Hardware-Plattform noch bringt. Hier sind nun die Ergebnisse.:

Betriebssystemmm:ss
OpenVMS00:31
Ultrix00:42
NetBSD05:05
Zeit für den Boot-Vorgang

Bevor ich nun die Ergebnisse interpretiere, will ich nochmals auf etwas eingehen, was für Software-Emulatoren wie der SIMH einer ist, gilt. Ein Software-Emulator ist ein Programm, welches einen Computer oder ein Betriebssystem nachbildet. Der größte Nachteil der Software-Emulation ist, dass sie eine hohe Rechenlast auf dem emulierenden System erzeugen. So können, selbst auf modernen Rechnern, zum Beispiel alte Spieleklassiker teilweise nicht flüssig laufen. Die Software-Entwicklung für solche Emulationen ist sehr aufwendig. In meiner Emulation der VAX-Architektur mit SIMH ist es jetzt aber so, dass die Rechenleistung so enorm ist, dass die Ausführung der Betriebssysteme in ihr deutlich schneller als auf der echten, originalen Hardware ist.

  • OpenVMS bootet von allen drei gemessenen Betriebssystemen im SIMH mit etwa 31 Sekunden am schnellsten. OpenVMS – oder ursprünglich nur VMS bezeichnet – wurde aber mit der Entwicklung der VAX-Architektur gleichzeitig mit entwickelt und war so immer auf diese optimiert.
  • Ultrix wurde durch DEC ab 1984 für die VAX-Architektur entwickelt und veröffentlicht. Unix galt in den 1980er Jahren prinzipiell als ein Betriebssystem, welches sehr viele Ressourcen in Anspruch nahm. Ultrix war nicht für alle Computern der VAX-Reihe verfügbar. Auf den Modellen, auf welchen es aber ausgeführt werden konnte, war es dennoch sehr langsam. Mit etwa 42 Sekunden bootet es in meiner Emulation verhältnismäßig schnell.
  • Die aktuelle Version von NetBSD benötigt für den Boot-Vorgang mit 5 Minuten und etwa 5 Sekunden verhältnismäßig extrem lange.

Wie gesagt, gelten die gemessenen Zeiten nur für meine SIMH-Emulationen und die Boot-Vorgänge kann man als wahnsinnig schnell erachten. Der Betreiber des YouTube-Kanals digital diggings präsentiert und führt ausschließlich auf seinen DEC-Rechnern der VAX-Architektur OpenVMS aus. Obwohl OpenVMS von der Ausführungsgeschwindigkeit das Betriebssystem mit der besten Performance ist, wird man beim Anschauen seiner Videos aber schnell feststellen, dass dieser bei der Wiedergabe seiner Aufnahmen, diese um ein bis zu 20facher Beschleunigung abspielt, damit die Wiedergabe für den Zuschauer sich nicht ganz so in die Ewigkeit hinzieht. Rechnet man die Abspielzeiten der beschleunigten Boot-Vorgänge für die einfachen Wiedergabegeschwindigkeiten hoch, so ist festzustellen, dass ein Boot-Vorgang selbst mit OpenVMS um ein Vielfaches als mein gemessener Wert überschreitet. Wie lange müssen dann die Boot-Vorgänge mit Ultrix und NetBSD dauern? 1 bis 1,5 Stunden bei NetBSD?

Links:

Über die Weihnachtsfeiertage habe ich mich mal bei YouTube mit ein paar Videos von Eisenbahnern berieseln lassen. Hauptsächlich kleine Dokumentationen, Aufnahmen von Modellbahnanlagen und Führerstandsmitfahrten. Dabei bin ich aber auch auf den YouTube-Kanal von Alwin Meschede gestoßen. So wie ich das von ihm verstanden habe, war er zu mindesten oder ist vielleicht noch selber als Triebfahrzeugführer tätig. Durch sein Studium der Betriebswirtschaftslehre kann ich mir durchaus vorstellen, dass er nicht mehr nur als reiner Lokführer tätig ist. Durch seine zahlreichen Videos, in denen es ihm weniger um Lokomotiven und Züge geht, sondern er beispielsweise eher über die unterschiedlichen Arten von Gleisbetten, Zugsicherungssystemen oder Gegebenheiten von Hochgeschwindigkeits-Neubaustrecken referiert, wird klar, dass er ein großes Fachwissen über das System Eisenbahn besitzt und über deren strukturelle Organisation in Deutschland sehr gut Bescheid weiß. So habe ich dann aus Neugier mir seinen zweiteiligen Vortrag über die Linienförmige Zugbeeinflussung LZB 100 angeschaut. Dabei schweift er bei dem Punkt über den Aufbau einer LZB 100 Steuerstelle ab und erwähnt, dass bei den LZB 72 Steuerstellen als Prozessrechner Computer der MicroVAX-Reihe zum Einsatz kamen, – wenn sie nicht noch bis heute weiterbetrieben werden.
Ab diesen Punkt kann ich mich noch gut erinnern, denn ich hatte im Sommer 2018 einmal die Gelegenheit, bei der DB Netz AG eine Betriebszentrale kurz zu besichtigen. Bei dem Rundgang dann durch den EMR-Schaltraum habe ich dann in einem Regal eine alte VAXstation entdeckt, die aber nicht mehr in Benutzung schien. Und nun habe ich auch verstanden, warum ich bei dem Rundgang durch die Betriebszentrale noch eine VAXstation antreffen konnte. Die Deutsche Bundesbahn hatte in den 1980er Jahren für der Projektierung der Linienförmige Zugbeeinflussung 72 (kurz LZB 72) Computer der Reihe MicroVAX als Prozessrechner in den Steuerstellen eingesetzt. Und so ist in der von mir besichtigten Betriebszentrale der Deutschen Bahn eine VAXstation noch übrig geblieben.

Links:

Und damit bin ich nun an dem Punkt, wo Computer der VAX-Reihe der Digital Equipment Corporation eingesetzt wurden.

  • Im Bereich Banken-/Versicherungswesen. (Hörensagen)
  • Andere Bereiche für Services.
  • Als Prozessrechner für die Linienförmige Zugbeeinflussung der Deutschen (Bundes-) Bahn.
  • In der chemischen Industrie als Mess- und Prozessrechner. Konkret bei einem früheren Arbeitgeber von mir. Den Computer selber habe ich nicht mehr zu Gesicht bekommen. In einem alten EMR-Schaltraum bin ich aber auf ein serielles Terminal vom Typ VT420 von DEC gestoßen. DEC hatte dieses Terminal-Modell im Jahr 1990 in den Markt eingeführt. Auf Nachfrage an die Kollegen der IT, berichteten diese mir, dass sie „vor kurzem“ erst noch alte klobige Festplatten in den Schrott entsorgt hatten. Ich konnte daraus entnehmen, dass die Festplatten wohl im Format 5,25″ volle Bauhöhe waren. Festplatten diesen Umfang wurden in der Regel in den Modellreihen MicroVAX und vielleicht auch VAXstation verbaut. Sicher bin ich mir bei letzterem da aber leider nicht hundertprozentig. Es ist eher nur eine Vermutung.

Links:

Zuletzt habe ich noch ein wenig in der Google-Bildersuche nach Fotos der MicroVAX I und MicroVAX II gestöbert. Dabei bin ich auf das MicroVAX II Museum gestoßen, dessen Betreiber des Blogs leider nirgendwo namentlich erwähnt wird. Eine E-Mail-Adresse als Kontakt konnte ich bisher bedauerlicherweise auch nicht ausfindig machen.
Wie aber der Name des Blogs nun schon verrät, beschäftigt sich dieses kleine Privatmuseum im Wesentlichen für den Erhalt von Computern der Modellreihe MicroVAX II. Es gibt aber auch Teile (als reine Ausstellungsobjekte) anderer VAX-Modelle. Die Highlights sind aber eindeutig die beiden funktionsfähigen MicroVAX II Computer Tarzan und Jane. Das wirklich Bemerkenswerte an den beiden aus den späten 1980er Jahren stammenden Computern ist aber, dass sie nicht mehr in ihren Originalgehäusen, sondern in wohnzimmertauglichen, schön anzusehenden und leisen PC-Gehäusen betrieben werden. Die Gehäuse sind moderne ATX-Gehäuse mit Plexiglas als Front und Seitenpartie, die beleuchtet sind. Die MicroVAX II Jane besitzt sogar ein LCD-Display mit einer Diagonale von 6,5″ und LED-Backlight. Die MicroVAX II Tarzan besitzt hingegen ein POS-VFD-RS232-Display, welches 2 × 20 Zeichen anzeigt und direkt an den Konsolenanschluss angeschlossen ist, um eine sehr genaue Zeit anzuzeigen, während auf der Maschine ein NTP-Server läuft. Es wurden zusätzlich noch die Festplatten gegen SD-Karten als Festspeicherlaufwerke ersetzt, die über SCSI2SD-Konverter am SCSI-Controller betrieben werden und über eine Speicherkapazität von 16 Gigabyte verfügen.

Links:

Emulation einer VAX mit SIMH: OpenVMS

Veröffentlicht am von

In der dritten und letzten Runde habe ich schließlich auf meiner emulierten MicroVAX das ursprünglich von der Digital Equipment Corporation entwickelte OpenVMS installiert. OpenVMS – bis 1991 nur VMS – steht für Virtual Memory System und war zur Zeit seiner Erstveröffentlichung 1977 ein ausgesprochen fortschrittliches 32-Bit-Betriebssystem, das Mehrbenutzer- und Multitasking-fähig war. Es war zudem eines der ersten Betriebssysteme mit virtueller Speicherverwaltung, welches auch die Namensgebung begründet. Das Betriebssystem wurde gleichzeitig mit der VAX-Computerreihe veröffentlicht und für diese entwickelt. Für die Entwicklung von VMS war unter anderem David Neil Cutler verantwortlich, der 1988 von Microsoft bei DEC abgeworben wurde, um das seinerzeit neue Betriebssystem Windows NT zu entwerfen und die Entwicklung zu leiten. Das hatte zur Folge, dass es deutliche Ähnlichkeiten von VMS und Windows NT gibt.
Die Firma DEC wurde im Jahr 1998 von Compaq übernommen und damit auch die Weiterentwicklung von OpenVMS. Da Compaq selber wiederum im Jahr 2002 von Hewlett Packard übernommen wurde, gingen Weiterentwicklung und Vertrieb von OpenVMS auch an HP. Im Jahr 2014 hat HP Weiterentwicklung und Vetrieb mit OpenVMS 8.4 beendet. Dies übernimmt seitdem die eigens dafür gegründete VMS SOFTWARE INC (kurz: VSI) in Lizenz.

Seit der Veröffentlichung von VMS mit der Version 1.0 im Jahr 1977 bis zum jetzigen Zeitpunkt, hat das Betriebssystem insgesamt 4 Hardware-Plattformen unterstützt.: bis zur Version 7.3 im Jahr 2001 war dies die VAX-Architektur. Ab 1992 kam auch die von DEC entwickelte „Alpha AXP“ RISC Prozessor-Architektur hinzu, die von Anfang an auch eine 64-Bit-Architektur war. Die letzte für Alpha-Prozessoren erschienene OpenVMS-Version wurde von VSI im Jahr 2017 mit der Versionsnummer V8.4-2L2 veröffentlicht.
Durch die Übernahme von Compaq durch HP im Jahr 2001, wurde OpenVMS für die 64-Bit Itanium Architektur portiert. Die Itanium-Architektur (kurz: IA-64) wurde von HP und Intel gemeinsam entwickelt. Die Unterstützung der Itanium-Architektur soll mit dem letzten Update für OpenVMS 8.4 eingestellt werden.
Schon seit einiger Zeit wird durch HP und der VMS SOFTWARE INC an einer Portierung von OpenVMS auf die x86-64 Architektur hingearbeitet. Mit der künftig erscheinenden OpenVMS Verson 9.0 soll nur noch die 64-Bit CISC-Architektur unterstützt werden.

So viel zur Versionsgeschichte von OpenVMS. Der Betreiber der Webseite VaxHeaven (http://www.vaxhaven.com/VaxHaven) hat einige Images von CD-ROMs, Magnetbändern und Lochstreifen zusammen getragen und bietet sie wieder zum Download an. Dabei handelt es sich um Images von den OpenVMS-Installations-Medien, den Dokumentations- und Software-Produktbibliotheken.

OpenVMS 7.3 First Login
OpenVMS 7.3 First Login

Als OpenVMS Installations-Image hatte sich für mich nur die Version 7.1 für meine emulierte (Micro-) VAX angeboten. Nach der Installation hat sich aber herausgestellt, dass auf der Installations-CD von OpenVMS 7.1 nicht der TCP/IP Protokoll-Stapel von DEC mitgeliefert wurde. Version 7.1 wurde im Jahr 1996 noch von DEC veröffentlicht. Nach etwas Recherche im Internet bin ich dann doch noch auf die OpenVMS Version 7.3 fündig geworden. Dies war die letzte Version für die VAX-Architektur und wurde 2001 von Compaq veröffentlicht. Diese enthielt dann auch den TCP/IP Protokoll-Stapel.

Die Installation von (Open-) VMS läuft im Prinzip genauso ab wie diese von DECs ULTRIX. Es wird als erstes von dem Installations-Image – bei der realen Hardware also die Installations-CD oder das Magnetband – gebootet, die Ziel-Festplatte ausgewählt auf der im Anschluss alle „Sicherungssets zum Wiederherstellen“ des Systems für die Installation kopiert werden – im meinem Fall die erste mit der Bezeichnung DUA0 – und dann das System neu gestartet um von der Festplatte DUA0 die Installation und Einrichtung zu starten. Was zum Glück bei der Installation von OpenVMS im Gegensatz zu ULTRIX unter dem SIMH-Emulator wegfällt, ist der Umstand, dass man die Laufwerksbezeichnungen in einem Installations-Skript anpassen muss. OpenVMS sieht die Hardwarekennung RQ vom Emulator und kann mit diesen direkt arbeiten.
Im Verlauf des Installationsprozesses wird nach der lokalen Zeit gefragt. Es wird nochmals nach dem Quellinstallationsmedium (CD-Image) gefragt und sichergegangen, dass dieses auch gemountet wurde. Es wird auch gefragt, welche Softwarekomponenten installiert werden sollen – einschließlich DECwindows mit Motif wie bei ULTRIX. Ich habe zur Sicherheit alles mit ‚yes‘ bestätigt. Auch wird DECnet-Plus für die Netzwerkkonfiguration mit TCP/IP benötigt.
Man darf sich aber nicht wundern, die Angaben des benötigten und des zu verbleibenden Speicherplatz auf der Festplatte wird in Blöcken angegeben anstatt in Kilo-, Mega- oder Gigabyte. Da ein Block immer mit einer Größe von 512 Byte bemessen wird, lässt sich die Angabe in Byte recht schnell erahnen, beziehungsweise berechnen.
Wo es wieder einen signifikanteren Unterschied zu ULTRIX, sowie der restlichen Unix- und Linux-Welt gibt, ist die Anzahl der User-Accounts die bereits während der Installation eingerichtet werden. Zum einen gibt es den ‚SYSTEM‘-Account, der vergleichbar mit dem Root-Account bei Unix und Linux ist. Der Account SYSTEST bietet eine geeignete Umgebung zum Ausführen von UETP, einem Testpaket für Benutzerumgebungen auf eigenständigen Systemen. Darüber hinaus wird der Account FIELD angelegt, der dazu dient, ein System testen zu können.
Der Installer verlangt dann den ‚SCSNODE name‘ – also einen Hostnamen, sowie eine ‚SCSSYSTEMID‘, eine ID zur Identifikation des Rechners innerhalb eines VAX-Clusters.
Anschließend erwartet der Installer die Lizenzschlüssel, aber man kann dies auch erstmal verneinen und die Lizenzaktivierung hinterher nach der Installation durchführen. Letztendlich wird noch nach der Zeitzone gefragt und ob zurzeit die Sommerzeit vorherrscht oder nicht. Letztendlich wird noch DECnet-Plus installiert und es muss sichergestellt sein, dass das Installationsmedium gemountet ist, um die Komponenten installieren zu können. Abschließend erzeugt der Installer ein neues System-Image und fährt VMS herunter.
Nach dem ersten und jeden weiteren Bootvorgang meldet sich OpenVMS und wartet auf den Login. Der Prompt ist dabei nicht sofort zu sehen, dass heißt, vor dem Login muss immer einmal Return gedrückt werden. Ansonsten gibt OpenVMS auf der Systemkonsole immer die Auditmeldungen aus.
Insgesamt betrachtet ist die Installation von OpenVMS sehr einfach, wenn man mal beachtet, dass es sich dabei eigentlich um ein Enterprise-System handelt. Die Installation verlangt im Gegensatz zu DECs Ultrix nur sehr wenige technische Details, was sehr angenehm ist.

OpenVMS 7.3 TCP/IP Configuration
OpenVMS 7.3 TCP/IP Configuration ohne gültiger Lizenz

Danach geht es daran, das System netzwerkfähig zu bekommen. Allerdings ist es zu diesem Zeitpunkt nur möglich unter OpenVMS DECnet einzurichten. Der TCP/IP Protokoll-Stapel muss von der Installations-CD nachträglich installiert werden. Da meine eingesetzte OpenVMS Version 7.3 aus dem Jahr 2001 stammt, sind sämtliche Komponenten zum Glück mit einem heimischen IPv4-Netz kompatibel, während hingegen bei dem ULTRIX Final-Release 4.5 eine aus heutiger Sicht mit veralteten Funktionen ausgestattete Bind-Version enthalten ist und so keine Namensauflösung mehr möglich ist.
Leider ist es mir aber prinzipiell nicht mehr möglich, IPv4 unter meinem emulierten OpenVMS zu konfigurieren. Grund ist, dass für die Nutzung der Netzwerkfunktionalitäten OpenVMS mit einer gültigen Lizenz versehen werden muss. Für die Nutzung einer OpenVMS-Installation ohne kommerzielle Absichten hatte HP das OpenVMS-Hobbyist-Programm mal ins Leben gerufen gehabt. So konnte man sich nach Registrierung eine Hobbyisten-Lizenz mit einer Laufzeit von einem Jahr ausstellen lassen. Seit Mai letzten Jahres hat HP aber keine neuen Hobbyisten-Lizenzen mehr ausgestellt. Grund ist, dass man mit der Einstellung von OpenVMS 8.4 und der Veröffentlichung von Version 9.0 als ersten x86-64 Port ein neues ‚Community License Program‘ ab diesem Jahr auf die Beine stellen möchte. Die letzten von HP noch ausgestellten Hobbyisten-Lizenzen werden am 15. März dieses Jahres auslaufen. Möchte man also noch die Möglichkeit haben und in den Genuss von OpenVMS mit voller TCP/IP Netzwerkfunktionalität zu genießen, so gibt es noch im Rahmen des ‚Student Hobbyist License Programs‘ das Angebot, das FreeAXP Kit herunterzuladen. Dabei handelt es sich um die Emulation eines virtuellen Alpha-Server mit OpenVMS 8.4, welche auf einem 64-Bit Windows ausgeführt werden kann. Allerdings wird auch zum 15. März diese Lizenz ablaufen. Auch gibt es bei dem Kit keine Möglichkeit DECwindows mit Motif auszuführen. Ich bin ja mal gespannt, ob die VMS SOFTWARE INC wieder ein attraktives Lizenzierungsmodell für Leute wie mich auf die Beine stellt, die das Betriebssystem einfach nur mal ausprobieren, kennen lernen und damit ein wenig herumspielen möchten. Mich hätte es nämlich auch dringend interessiert, ob OpenVMS mit DECwindows und Motif auch so langsam auf meinem Linux-Host ist wie ULTRIX mit DECwindows und Motif, oder ob es vielleicht flüssiger läuft. – Im Internet gibt es nämlich Besitzer von originalen VAX-Computern, die berichten, das ULTRIX – wenn es überhaupt auf ihren Geräten zu installieren ist – nur sehr langsam ist im Vergleich zu (Open-) VMS.

VSI OpenVMS Student-Package
VSI OpenVMS 8.4-22 Student-Package

Auch wenn ich OpenVMS unter meiner emulierten MicroVAX leider doch nicht auf Grund der fehlenden Lizenzierunsgmöglichkeit in mein heimisches Netz integrieren kann, bin ich schon echt froh, dass ich es überhaupt zum Laufen bekommen habe.

Als Kommandozeileninterpreter und Skriptsprache steht unter OpenVMS die DIGITAL Command Language (DCL) zur Verfügung. Die Kommandos und deren Syntax unterscheiden sich deutlich denen von DOS und Linux/Unix. Bisweilen sind die Befehle sehr umständlich, wie zum Beispiel die Angabe um auf die oberste Verzeichnisebene eines Laufwerkes zu gelangen. Da steckt also viel Potenzial, das System kennenzulernen und zu erforschen. Der Hauptantrieb, weshalb ich mir OpenVMS überhaupt mal anschauen wollte, ist die Eigenschaft, dass bei der DCL alle Dateien und Verzeichnisse zwei Dateierweiterungen.
besitzen.:
Die Dateinamen und Verzeichneichnisse bestehen aus Namen, Datei-Typ und Versionsnummer (z. B. NAME.TYP;1), NAME und TYP sind jeweils Ketten von bis zu 39 alphanumerischen Zeichen. Geänderte Dateien werden als eine neue Version gespeichert, die sich in einer inkrementierenden Versionsnummer nach einem Semikolon im Dateinamen unterscheidet (NAME.TYP;1 → NAME.TYP;2). Dies wurde später auch von ISO 9660 übernommen. Die ältere Version wird vom System nicht gelöscht, dies kann der Benutzer mit den DELETE- oder PURGE-Befehlen bedarfsweise tun. Die maximal mögliche Versionsnummer ist 32767. Ist diese erreicht, kann keine neue Version der Datei mehr angelegt werden. Ein Aufräumen und Umbenennen ist selbstverständlich möglich.

Links:

Emulation einer VAX mit SIMH: Ultrix

Veröffentlicht am von

In der zweiten Runde habe ich auf meiner emulierten MicroVAX das von der Digital Equipment Corporation entwickelte ULTRIX installiert. ULTRIX ist die Unix-Variante für die VAX- sowie die DECstation- und DECsystem-Rechnerfamilien von DEC, die erstmals im Jahr 1982 veröffentlicht wurde.
Das erste native VAX UNIX-Produkt von DEC war Ultrix-32, basierend auf 4.2BSD mit einigen Nicht-Kernel-Funktionen von System V, und wurde im Juni 1984 veröffentlicht. Später wurde es um Funktionen von BSD4.3 und Unix System V Release 2 ergänzt. Mit ULTRIX-11 bot DEC noch eine Implementation für die Minicomputer der Reihen PDP11 und Micro/PDP-11 an. Die letzte Version von ULTRIX war die Version 4.5 für DECstation und DECsystem mit RISC-CPU, sowie der VAX-Architektur. Sie wurde im November 1995 veröffentlicht.
ULTRIX unterstützte sowohl TCP/IP als auch DECnet, ebenso beherrschte es neben SMTP auch Mail-11. Ursprünglich wurde für die VAXstations unter Ultrix-32 die Desktopumgebung Ultrix Workstation Software (UWS) basierend auf dem X Window System verwendet. Mit der Verbreitung von X Version 11 (X11) wurde die DECwindows-Umgebung eingeführt, welche auch Grundlage für die Gestaltung des späteren Motif der OSF war.

Die letzte von DEC veröffentlichte ULTRIX Version 4.5 habe ich auch im Internet als CD-ROM Image gefunden. Hat man im Emulator von dem Installationsmedium gebootet, so steht man auch schon vor der ersten Hürde. Da es sich nicht um (originale) Hardware handelt, stimmen die Laufwerksbezeichnungen für CD-ROM Laufwerk und Festplattenlaufwerk nicht überein. Die Lösung ist, dass die Bezeichnung in dem Installationsprogramm angepasst werden müssen. Und das ist zum Glück keine wilde Sache, denn bei dem Installationsprogramm handelt es sich lediglich nur um ein etwas umfangreiches Shellscript. Allerdings stand ich dann vor der nächsten Hürde. Das minimale System des Installationsmediums, welches in den Computer geladen wurde, besitzt noch nicht einmal den vi als Texteditor. Es steht lediglich nur der noch ältere und zeilenorientierte ed als Texteditor zur Verfügung. Ich habe mich daher bereits im Vorfeld mit der Bedienung dessen ein wenig auseinander gesetzt gehabt. – Und es ist noch nicht mal das Programm cat auf der Shell verfügbar, mit dem man sich den Inhalt des Installationsskripts ausgeben lassen könnte. Auch hier ist man auf umständliche Weise auf den ed angewiesen.

ULTRIX war nie Jahr 2000-kompatibel. Also habe ich mich exakt um 25 Jahre in die Vergangenheit gebeamt, also in den November 1995. Die Zeit in der ULTRIX 4.5 veröffentlicht wurde und ich so langsam begann mich für Computer zu interessieren.

Login ULTRIX
Login ULTRIX mit DECwindows

Man ist aus heutiger Sicht durchaus erstaunt, wie übersichtlich doch die Config-Datei für den ULTRIX-Kernel ist. Es gibt lediglich sieben Optionen, die zusätzlich hineinkonfiguriert und kompiliert werden können. Ein Menuconfig, respektive Xconfig hat unter Linux über die Jahre hingegen deutlich an Optionen und Komplexität zugenommen.

Man ist ja froh, dass ULTRIX neben DECs eigenem DECNet auch irgendwann TCP/IP-Protokollfamilie aus der BSD-Welt mit übernommen hat. Ich konnte dem Host zwar eine IPv4 Adresse und das Gateway konfigurieren, aber das Routing über den nächsten Hopp hinaus habe ich nicht hinbekommen, so dass Computer aus anderen Netzen leider nicht zu erreichen sind. Auch die Namensauflösung von Domains funktioniert leider nicht. Dies liegt wahrscheinlich an der bereits veralteten Bind-Version. Das Problem scheint zu sein, dass ULTRIX sogenannte inverse Abfragen sendet, um eine IP-Adresse einem Hostnamen zuzuordnen. Die meisten DNS-Server unterstützen diese inversen Abfragen aber nicht mehr.

ULTRIX wird von dem Installationsprogramm so installiert und eingerichtet, dass der Systembenutzer root leider kein eigenes Heimatverzeichnis /root/ erhält. Alle Dateien werden also in die oberste Wurzelverzeichnisebene erstellt. Da ich ein Freund von Ordnung bin, habe ich das nachgebessert, so wie ich es von Linux und den modernen BSD-Unix gewohnt bin. Verzeichnis /root/ erstellen und alle .xxx-Dateien in dieses verschieben. Interessanterweise gibt es unter ULTRIX die Datei /etc/shadow nicht. Die Passwörter der User werden verschlüsselt auch in der Datei /etc/passwd abgelegt.

Motif DECwindows
Motif DECwindows

Selbst das Release des letzten großen ULTRIX-Updates ist (nicht nur) aus heutiger sehr minimalistisch und unkomfortabel auf der Commandline-Shell. Es fehlt an erster Stelle schon an einer vernünftigen Shell. Selbst die Korn-Shell unter ULTRIX unterstützte noch keine Commandline-History und die Tabulator-Autovervollständigung der Befehle. Auch gibt es kein (GNU-)tar, dass in einem Rutsch gezipte tar-Archive dekomprimiert und in die Ordnerstruktur zurückextrahiert. Stattdessen muss ein Archiv jedes mal mit dem ineffizienten uncompress dekomprimiert und tar extrahiert werden.
Mal ganz davon abgesehen, dass außer dem Standard C-Compiler keine Skript-Programmiersprache wie Perl auf dem System verfügbar ist.
Der Hardwaresammler und Websitebetreiber Joachim Buss hatte sich mal die Mühe gemacht und eine eigene ULTRIX Freeware CD-ROM mit etwas GNU-Software, welche man auch eher aus dem Linux-Umfeld kennt, zusammengestellt und bietet diese als Download im Internet an. Das war im Jahr 2002. Das heißt, dass die Versionen der Programme aus heutiger Sicht auch schon wieder sehr veraltet sind, aber dank einer Bash, dem Midnight Commander, wget und Skriptsprachen wie Perl oder Python, macht es die Bedienung von ULTRIX deutlich komfortabler. Es ist auch zu empfehlen, sich als Erstes den GNU C-Compiler und GNU make zu installieren. So lässt sich nämlich GNU tar nicht mit dem Standard C-Compiler von ULTRIX bauen. GNU tar ist aber in der Lage ein tar-Archiv mit einem Befehl gleichzeitig zu dekomprimieren und extrahieren. Des Standard-tar unter ULTRIX kann ein Archiv nur extrahieren und dazu muss es aber vorher erst mit bzip2 separat dekomprimiert worden sein.
Einige Programme sind auf dieser CD-ROM als Quellcode vorhanden, während bei anderen wie dem Midnight Commander bereits vorkompilierten Programmbinaries einschließlich der Dokumentation als Archiv enthalten sind. Bei Diesen müssen die Dateien lediglich im Dateisystem entsprechend den Pfaden nachgehend kopiert werden.
So lässt sich das System um einige nützliche Programme, der GNU X11-Umgebung und Window-Manager erweitern. Es gibt aber auch einen SSH-, DHCP-, sowie einen Apache-Server für das ULTRIX.

Das letzte ULTRIX-Release war so rudimentär, dass es noch nicht einmal Aliase gab. Auch in vielen anderen Dingen ist das ULTRIX anders aufgebaut. So werden zum Beispiel die Heimatverzeichnisse der User nicht in dem Verzeichnis /home/ angelegt, wie es heute bei Linux und den BSD-Systemen die Konvention ist, sondern im Verzeichnis /usr/users/. Das Dialogbasierte Programm erlaubt die Speicherung der User-Verzeichnisse aber auch an eine andere beliebige Stelle des Dateisystems, ganz wie es dem Systemadministrator beliebt. Hier eine tabellarische Übersicht über die Unterschiede zwischen den einzelnen Unix-Derivaten und Linux. (eigenes DokuWiki)

ULTRIX DECwindows DECterminal 1
ULTRIX DECwindows DECterminal 1

Am Ende habe ich auf meinem Linux-Host, der die Emulation bewirtet, noch das Programmpaket xserver-xephyr installiert. Dieses erlaubt die Entgegennahme von einer X11-Session eines Host innerhalb eines Netzwerkes und stellt die Bildschirminformationen in einem separaten Fenster dar. Somit lässt sich die Ausgabe des X-Window-Servers vom Ultrix auch darstellen und das System über das grafische DECwindows mit Motif mit Maus und Tastatur bedienen. Allerdings hat sich das System bei mit ab diesem Punkt immer recht schnell die Karten gelegt und es funktionierte nicht über einen längeren Zeitraum. Mal ließen sich die Standard-Applikationen nicht starten oder das System brach nach einigen wenigen Minuten die X-Windows-Session wieder ab und warf mich auf das Login-Fenster zurück. Ich vermute – und das ist insgeheim auch meine Hoffnung – dass das Acer-Notebook als Host-Computer mit seinem AMD Athlon X2 Dual Core als Prozessor nicht leistungsstark genug für die Emulation ist.

ULTRIX DECwindows DECterminal 1
ULTRIX DECwindows DECterminal 2

Update 16. Mai 2021 14:05 Uhr:

Das sich die Standard-Applikationen von DECwindows sich oft nicht öffnen ließen, lag daran, dass ich das Fenster mit der dxconsole meistens geschlossen hatte. Damit die DECwindows-Programme sich immer starten lassen, sollte die dxconsole wenigstens als Icon minimiert im Hintergrund weiter ausgeführt werden. Allerdings lässt sich das Programm Paint prinzipiell nicht starten. Es muss wohl fehlerhaft sein, da auch andere User das Problem haben.
Aber es bleibt immer noch zu klären, warum mich nach wie vor die X-Windows-Session immer wieder nach ein paar Minuten ausloggt und mich wieder zum grafischen Login-Fenster zurückbringt.

Links:

Emulation einer VAX mit SIMH: Bilder zu der Original-Hardware

Veröffentlicht am von

Nun berichte ich in dieser Artikel-Serie über Hardware und zeige auf, welche Betriebssysteme sich auf dieser betreiben lässt, ohne selber einen eigenen visuellen Eindruck von ihr abgeben zu können. Um ehrlich zu sein, ich selber bin noch nie mit einem Computer, oder mit deren Peripherie, von der Digital Equipment Corporation in Berührung gekommen. Stattdessen hatte ich in den letzten rund 6 Jahren dreimal die Möglichkeit Zutritt zu Räumlichkeiten zu bekommen, wo jedes mal ein Stück DEC-Hardware im Begriff einzustauben war.

Die Erste war mit einem VT420 Terminal, welches die EMR-Technik eines seinerzeit bereits stillgelegtem Betriebes meiner alten Chemie-Firma noch herumstehen hatten. Der Kollege von der IT-Abteilung merkte dazu an, dass die dazugehörige Computer-Hardware bereits einige Monate zuvor verschrottet wurden. Im Juni 2015, keine ganzes Jahr später, besuchte ich mit Bekannten den Tag der offenen Tür bei der Deutschen Nationalbibliothek in Frankfurt. Bei der Führung durch deren Inhouse betriebenen, kleinen Rechenzentrum, war in einer Ecke des Raums auf einem rollbaren Pult von mir wieder eine VT420 Terminal auszumachen. Auf meine Frage, ob denn das Terminal aus musealem Zweck abseits der deutlich moderneren Computer-Hardware da stehe, versicherte aber ein Angestellter, dass das Terminal ganz gut und gerne noch für die Konfigurations- und Wartungsarbeiten der Router und Switche genutzt wird. Vor zwei Jahren hatte man mir im Rahmen eines Vorstellungsgespräches bei einem großen, deutschen Transportunternehmen noch deren Betriebszentrale gezeigt. Dort stand dann auch noch eine vollständige VAXstation samt Monitor ungenutzt im Regal neben der anderen EMR- und Computertechnik.

DEC VT420 Serial Terminal
DEC VT420 Serial Terminal

Der amerikanische YouTuber TrackZero hatte vor gut zwei Monaten ein Video veröffentlicht, in dem er seine im Laufe des Jahres erstandene MicroVAX 3800 in Einzelteilen präsentiert und dann zusammenbaut.
In meinem Blog-Artikel zu der von mir mit SIMH zu emulierenden Hardware habe ich mich für die MicroVAX 3900 entschieden.
MicroVAX 3800 und MicroVAX 3900 wurden gemeinsam unter dem Code-Namen „Mayfair III“ 1989 als High-Ende-Modelle der MicroVAX-Familie durch DEC auf den Markt gebracht. Beide Computer sind im wesentlichen völlig identisch. Sie arbeiten beide mit dem gleichen KA655-CPU-Modul und unterstützten bis zu 64 MiB ECC-RAM. Die kleinere MicroVAX 3800 unterscheidet sich aber von ihrem größeren Schwester-Modell insofern, da sie nicht das mehr als 19″ breite, sondern ein kleineres auf Rollen beweglicheres Gehäuse besitzt. Dadurch konnte sie aber auch nur eine Festplatte mit einer Speicherkapazität von maximal 1,2 Gigabyte aufnehmen, währende die größere 3900 mit einer Festplatte von bis zu 1,5 Gigabyte Speicherkapazität ausgestattet werden konnte.

MicroVAX3900
MicroVAX3900 (Quelle: The NetBSD Foundation, VAX Hardware Reference: www.netbsd.org)
Quelle: YouTube-Kanal TrackZero

In einem später folgendem Video wird TrackZero noch seine nachträglich erstandene Video Card für seine VAX präsentieren. – Ich werde gespannt auf sein!

Links:

Emulation einer VAX mit SIMH: NetBSD

Veröffentlicht am von

NetBSD ist ein unixoides Betriebssystem, bei dem die einzelnen Komponenten des Userland mit den Fähigkeiten des Kernels optimal abgestimmt sind. Dies wird dadurch erreicht, dass der Kernel und fast das ganze Userland aus einer Hand stammen. Großer Wert wird darauf gelegt, dass sich das System auf allen Architekturen gleich verhält. NetBSD versteht sich sowieso darauf, auf vielen Computer-Architekturen ausgeführt werden zu können, von denen inzwischen viele einen historischen Charakter haben. – Nicht umsonst gibt es den alten Witz.: ‚NetBSD läuft auf allen Geräten. Selbst auf einem Toaster.‘

Die Portierung von NetBSD auf die VAX-Architektur der Digital Equipment Corporation war erstmals mit der NetBSD-Version 1.2 im Oktober 1996 abgeschlossen. Seitdem wird der VAX-Port kontinuierlich weiter entwickelt. Trotzdem ist NetBSD ein modernes Betriebssystem am Puls der Zeit. So war NetBSD auch das erste unter den Open Source-Betriebssystemen, welches die USB-Schnittstelle mit der Version 1.4 im Mai 1999 unterstützte. Selbst unter Linux wurde die Unterstützung für USB erst mit Kernel 2.4 im Januar 2001 realisiert.

Boot NetBSD 9.1 MicroVAX 3900 1
Boot NetBSD 9.1 MicroVAX 3900

Ich selber habe meinen ersten Kontakt mit NetBSD mit Erscheinen der Version 4.0 aufgenommen. – Das war im Jahr 2008. Motivation war damals für mich, dass das Betriebssystem selber nur aus einem kleinen Basissatz mit den wichtigsten Programmen (also dem Useland) besteht und so trotz Fehlen einer grafischen Benutzeroberfläche mit Maus, stattdessen mit einer ncurses-ähnlichen Menü-Steuerung extrem fix auf dem Computer installiert werden kann. Nach dem ersten Boot auf das installierte System war und ist man nur mit dem vi als Texteditor ausgestattet, gezwungen das System durch editieren von Dateien und den Kommandozeilenprogrammen des Basissystems zu konfigurieren und sich einzurichten. Das war für mich der Hebel, einen Zugang zu der Shell zu bekommen. Schneller und deutlich angenehmer als, wenn ich mich zum Beispiel mit Linux From Scratch erst einmal durch lange Anleitungen lesen hätte müssen und die nötigen Programme sowie Bibliotheken aus dem Sorce-Code erst in Binädaten kompiliert werden müssen.

Inzwischen ist das Programm sysinstall – so heißt der ncurses-ähnliche Installer nämlich – nochmals verbessert worden. So lassen sich über ihn inzwischen unter anderem auch die Quellpfade für die pre-kompilierten Programmpakete sowie das Archiv der Programmpakete mit dem Quellcode konfigurieren und beziehen, den lokalen NTP-Zeitserver aktivieren, den Displaymanager xdm für den automatischen, grafischen Login systemweit aktivieren oder einen eingeschränkten User-Account erstellen.
Im Prinzip verläuft die Installation und Einrichtung des Systems auf der VAX-Architektur genau so wie bei der x86 PC-Version (32 und 64 Bit). Das einzige, was im Gegensatz zu den x86 PC-Versionen zum Glück wegfällt, ist die Partition mit der MBR-/GPT-Formatierung. Während des Boots des Installationsmediums muss aber noch ein Terminal ausgewählt werden, sonst kann verständlicherweise das sysinstall-Programm nicht starten. – Es stehen als Terminal-Emulation VT100, VT220, Ansi und XTerm zur Verfügung, wobei die Darstellung von der Ansi-Emulation im SIMH-Emulator absolut furchtbar aussieht.
War ich nach der Installation von dem NetBSD 7.x im SIMH ziemlich angenervt, weil der Init-Prozess bei jedem Booten von der HDD nach der gewünschten Terminal-Emulation fragt, wird bei NetBSD 9.x das System ohne der Emulation gestartet. Es kann sein, dass da die Skripte vor Veröffentlichung nicht vollständig implementiert wurden. Die Umgebungsvariable muss also nachträglich noch händisch gesetzt werden.

In meinem Doku-Wiki habe ich die knappe Konfigurationsdatei für die SIMH-Emulation für NetBSD dokumentiert.

Boot NetBSD 9.1 MicroVAX 3900 2
Login NetBSD 9.1 MicroVAX 3900

Da zum heutigen Veröffentlichungszeitpunkt dieses Beitrags NetBSD 9.1 erst 12 Tage zur Verfügung steht, wurden noch keine pre-kompilierten pkgsrc-Programmpakete für den VAX-Port auf den Servern zur Verfügung gestellt. Waren für NetBSD 8.2 noch 476 Binärpakete verfügbar, gibt es für NetBSD 9.0 nur noch 26 Pakete zur Auswahl. Ich denke, dass aufgrund der aus heutiger Sicht extrem begrenzten Leistungsfähigkeit der VAX-Architektur die Computermodelle längst nicht mehr auch nur für halbwegs sinnvolle Aufgabengebiete eingesetzt werden können, wird an der Menge der angebotenen Programmpakete auch kein Zuwachs mehr zu erwarten sein.
Der NetBSD-User John Klos hatte mal das Experiment gewagt und auf seiner VAXStation 4000/VLC mit 24 Megabyte RAM unter Version 9.0 Perl in der Version 5.30.3 aus den Quellen kompiliert. Das Kompilat stand erst nach exakt 9 Tagen, 15 Stunden, 6 Minuten und 48 Sekunden zur Verfügung.

Mit der Veröffentlichung von Version 2.8 war im Dezember 2000 die Portierung von OpenBSD auf DECs VAX-Architektur abgeschlossen und die Weiterentwicklung begonnen. OpenBSD selber ist von dem ehemaligen NetBSD-Mitinitiator und -entwickler Theo de Raadt im Jahr 1995 gegründet worden, nachdem dieser von seiner ehemaligen Community ausgeschlossen wurde. Nach der Veröffentlichung von Version 5.8 im Jahr 2015 wurde dann die Weiterentwicklung von OpenBSD auf die VAX-Reihe wieder aufgegeben.

Links: