Was man so beim Aufräumen findet

Schätze aus alter Zeit, die ich beim Aufräumen gefunden habe:

  • Aus meiner PDP-11-Zeit, DECPack und RK02-Platte mit RSX-11M, Band mit der Bibliothek meiner eigenen Unterprogramm-Sammlung
  • Disketten und Bandkassetten
  • TK50-,tk70-, TK85- und Dat-Bandkassetten. Dafür habe ich auch noch die passenden Laufwerke. Das TK50 hat die Installationsdateien einer alten VAX/VMS-Version gespeichert.
  • Den Quellcode für VMS 4.0 auf Mikrofilm. Einen Leser habe ich leider nicht, das liegt nur aus Nostalgie im Regal.
  • Ein Karte, die die Tastenbelegung eines VT-52-Terminals im Editor-Modus zeigt.
  • Eine Mappe mit den Ausdrucken alter Assemblerprogramme für IBM /370 MVS
Veröffentlicht unter Allgemein | Schreib einen Kommentar

Ein alter Kunde meldet sich

Bahn zur Aufnahme des sich mit jedem Durchgang verlängernden Blechs eines Walzwerks

Die Betriebssoftware eines Stahlwerks gliedert sich in mehrere Ebenen, die gewöhnlich als “Level1”, “Level 2” und “Level 3” bezeichnet werden.

Der “Level 1” besteht aus den Automaten oder SPS, die die Anlage auf unterster Ebene steuern.

Bei dem  “Level 2” handelt es sich um Software, die den Produktionsprozess verfolgt, dazu mit allen Automaten kommuniziert, alle Produktionsinformationen sammelt und basierend auf diesen Informationen  die Durchführung einer Schmelze steuert. Schon bei der Planung der Produktion  bestellt der Level 2  die notwenigen  Rohstoffe  beim  Schrottplatz, errechnet aus der angeforderten Stahlgüte Vorgaben zu Dauer, Temperatursteuerung und Zuschlagsstoffen für Schmelze und steuert die Materialzugaben.  Während der Schmelze kommuniziert der Level 2 mit dem Schrottplatz, dem Labor, der Qualitätssicherung. Er informiert die Operateure über alle Details des produktionsverlaufs. Nach Abschluss der Schmelze werden die Stahlmenge, die erzeugte Güte und Verbrauchswerte an den Level 3 zur kommerziellen Behandlung geliefert und an die nachgelagerte Gussstation geliefert.

Der Level 3 ist die kommerzielle Steuerungsebenen. Hier werden Bestellungen zu Schmelzenreihen zusammengestellt, um eine möglichst kontinuierliche Auslastung der Gesamtanlage zu erhalten. Diese Schmelzenreihen gehen dann als Bestellungen an den Level 2, der sie zum Abruf und zur Abarbeitung bereit hält. Nach Abschluss der Abarbeitung der Bestellungen durch den Level 2 verwertet der Level 3 die gemeldeten Produktionsdaten und Ergebnisse für die kommerzielle Behandlung: Lieferungen zusammenstellen, Rechnungswesen, langfristige Datenhaltung zur Qualitätskontrolle etc

Rosin war schon fast zehn Jahre Lieferant für Level 2  Systeme, mit weltweiten Installation, als über eine große deutsche Industrieanlagenbaufirma der Auftrag für die Aktualisierung einer Anlage in Spanien an uns vergeben wurden.

Dieser Auftrag war ein guter Anlass, eine komplette Neuentwicklung unserer Level 2-Software in Angriff zu nehmen, um folgende Ziele zu erreichen: Das neue Systeme sollte multilingual,  Hardware- und Betriebssystem-unabhängig, datenbankunabhängig, und zukunftssicher sein.

Durch moderne Systemware-Methoden wie Objektorientierung, Java aus Entwicklungssprache, und Oracle als Datenbank wurden diese Kriterien erreicht.

Als  Hardware-Plattform wurden Alpha-Server unter OpenVMS gewählt, zu dieser  Zeit der Standard in  Automation. Die  Benutzeroberfläche wurde in englisch und spanisch bereitgestellt, aber schon im ersten Release war sie leicht um weitere Sprachen erweiterbar, auch in arabisch und chinesisch. Die Entwicklung erfolgte weitgehend unter Windows und Unix, die Portierung auf OpenVMS  erfolgte fortlaufend während de Erstellung, sodass die aktuelle Entwicklungsstand jederzeit auf allen drei Betriebssystemen lauffähig war. Parallel liefen Tests mit Opensource-Datenbanken wie Postgres und Mysql.

2003 wurde der Level 2 beim Kunden installiert, in Betrieb gesetzt und übergeben.

Nach fast neunzehn Jahren meldet sich der Kunde zu unserer Überraschung  im Herbst 2021 mit einem Problem. Das große Rätselraten, was denn nach so vielen Betriebsjahren nun Sorgen bereiten könnte, löste sich auf überraschende Weise:  Die IT-Mannschaft, die sich mit dem System auskennt, geht in Rente, das Systems selbst hat sich aber als so stabil erwiesen, dass man es gerne weiterbetreiben möchte. Die Lösung ist die Übernahme der Betreuung durch uns – dem Kunden kommt dabei zu Gute, dass das System inzwischen für andere Einsätze  deutlich weiterentwickelt wurde, und der Kunde nunmehr auch von den Neuerungen profitieren kann.

Inzwischen sind die Servercomputer auf lokale Umgebungen in Linz und Ronda geclont, erste Probleme durch die Änderungen, die der Kunden in den letzten Jahren eingearbeitet hatte, gelöst, und ein Plan für die nächsten Upgrades erstellt.

Und es macht Spass, wieder mit OpenVMS zu arbeiten

Foto und Text: Dieter Roßbach

Veröffentlicht unter Allgemein | Schreib einen Kommentar

Austausch der SAN-Hardware

Alpha-Hardware mit OpenVMS am SAN ist eine gute Idee, da man dadurch Cluster aus mehreren Systemen bilden kann, die sich dann eine Systemplatte teilen und so die Vewaltung der Gesamtumgebung deutlich vereinfachen. Das gleiche gilt natürlich auch für die Datenplatten, der Clustermanager synchronisert die Zugriffe und stellt den Inhalt quasi lokal zur Verfügung. Zudem steht eine clusterweite Quorum-Platte zur Verfügung, die hilft, die Konsistenz des Clusters beim Ausfall einer oder mehrerer Rechner aufrecht zu erhalten. Dazu kommen noch die weiteren Vorteile des SANs: Bereitstellung von großen virtuellen Platten, Raidlevel, die die CPU-Leistung der Rechner nicht beeinträchtigen und eine schnelle Anbindung über Glasfaser.

Für VMS gibt es aber eine entscheidende technische Voraussetzung: das SAN muss das Betriebssystem unterstützen. Und hier kommen die MSA-Lösungen von DEC/Compaq/HP ins Spiel: die können das. Die erste erschwingliche Lösung war MSA1000. Sie erlaube eine vollständig redundante Konfiguration mit bis zu drei Plattenboxen und je zwei Controllern und Glasfaser-Switchen. Pro Box konnten bis zu 14 SCSI-Platten installiert werden, die dann boxenübergreifend in den gängigen Raid-Leveln genutzt werden. Die dadurch generierten logischen Platten konnten eine oder mehrere LUNs bedienen. Zudem war die Lösung offen, ein gemischter Betrieb mit VMS-, Unix-, Windows- und ESX-Servern war problemlos möglich.

Solch ein SAN hatte ich mit 3 ALPHAs unter OpenVMS 8.4 und 2 IBM-Servern unter ESX in Betrieb.

Nun ist diese Hardware mittlerweile recht alt und damit nicht mehr sinnvoll betreibbar, die Gründe dafür sind:

  • SCSI-Platten sind inzwischen teuer geworden.
  • Der Stromverbrauch ist durch die alten Platten sehr hoch
  • Größenbeschränkung des möglichen Plattenplatzes auf maximal 42 Laufwerke mit insgesamt 12 TB
  • Die Fibre-Switche sind dedizierte Lösungen, die über Einschübe in die Boxen angeschlossen werden. Bei Defekten muss der Einschub gegen gleiche Module ersetzt werden, die neu kaum, und wenn dann teuer zu beschaffen sind.

Auf die SAN-Plattform kann ich nicht verzichten, da sie die notwendige Flexibilität im Tagesbetrieb bietet. Um zukunftssicher zu sein, muss also eine Lösung her, die die oben genannten Einschränkungen umgeht und natürlich auch die OpenVMS-Systeme weiter unterstützt.

Als einfachste Lösung bietet sich der Wechsel auf die Folgegeneration MSA1500 an: Hier können sowohl SCSI- wie auch SATA-Platten mit einer Gesamtkapazität 96TB von eingesetzt werden, mit der Einschränkung, das nur Platten mit bis zu 1TB unterstützt werden. Für meinen Bedarf ist das vollkommen ausreichend. Die SATA-Platten sind preiswert verfügbar. Als Fibre-Switches können alle auf dem Markt verfügbaren genutzt werden. Ich setzt HP- und Brocade-Geräte ein – wobei der HP-Switch ein umbenannter Brocade ist. Die Verfügbarkeit von preiswerten Ersatz ist also gegeben.

Die Hardware war über Ebay einfach und preiswert zu beschaffen. Für einen reibungslosen Betriebsübergang habe ich erst einmal eine Test- und Migrationsumgebung aus einem Alpha-, einem ESX-Server und einem Fibre-Switch aufgebaut.

Drei 80GB-Platten, 2 im Spiegel und eine als Reserve, reichen für die VMS-Umgebung vollkommen aus. Darauf sind 5 LUNs in verschiedenen Größen abgebildet. Der Datastorage DS1 ist für die Systemplatten der auf ESX betriebenen Debian-Systeme vorgesehen.

Die Testumgebung habe ich dazu genutzt, mit mit der Konfiguration der Fibre-Switche vertraut zu machen – Reset, Zugang trotz nicht bekanntem Admin-Passwort zu bekommen, Konfiguration etc., die Hardware auf Stand zu bringen (Säubern, Pufferbatterien austauschen etc) und dann das Zusammenspiel der einzelnen Komponenten zum Laufen zu bekommen. Im nächsten Schritt habe ich dann die Platten entsprechend der geplanten Aufteilung konfiguriert und das VMS- und ein Debian-System testweise umgezogen. Das alles lief relativ reibungslos, da die eigentliche Konfiguration des MSA1500 sich nicht von der des MSA1000 unterscheidet.

Der Umzug der Systeme ist je nach Plattform unterschiedlich aufwändig.

In Produktion. Das Plattenchassis ist nun voll bestückt. Bei Bedarf können aber noch drei weitere angeschlossen werden.

Der Umzug von VMS-Systemen ist denkbar einfach. Meine regelmäßigen Sicherungen bestehen aus einem Vollabzug aller Platten am Samstag und inkrementellen Sicherungen unter der Woche. Daraus lässt sich ein System mit wenigen Befehlen rekonstruieren. Aus Redundanz- und Sicherheitsgründen halte ich auf jedem Rechner auf einer lokalen Platte eine bootbare Systemplatte bereit. Die wird angestartet, dann die Sicherungsdateien über da Netz kopiert und je nach Platzbedarf auf eine lokale oder eine temporär eingerichtete SAN-Platte abgelegt und dann per Backup/image auf die neuen Zielplatten kopiert. Danach ist die neue Produktionsumgebung fertig und betriebsbereit.

Die Debian-Systeme habe ich per ESX-Funktion umgezogen. Im ersten Schritt wurden alle Systeme auf lokale Platten im Server verschoben und dort wieder gestartet. damit war die Ausfallzeit minimiert und ich konnte die SAN-Hardware in Ruhe umbauen. Dann alles wieder zurück auf das neue SAN und der Umbau war abgeschlossen. Meine Stromrechnung wird es mit danken und die hauseigene Cloudd kann nun auch üppigen Platz bereitstellen.

Veröffentlicht unter Allgemein | Schreib einen Kommentar

Die Wiederbelebung der SGI-Systeme

Funktionsfähige Geräte weg zuwerfen fällt mir schwer. Daher steht im meinen Lager das eine oder andere alte System herum, mit dem man eigentlich nicht viel anfangen kann, so auch die SGI Indy und die O2, die schon lange nicht mehr hochgefahren wurden.

Diese Systeme wieder in Betrieb zu nehmen, klingt im ersten Moment ganz einfach. Schließlich funktionierten sie ja tadellos, als sie das letzte Mal ausgeschaltet wurden. Die Realität ist aber doch eine andere: Mäuse bewegen den Zeiger auf dem Bildschirm eher zufällig, alte Monitore melden sich beim Einschalten genau einmal mit einem Blitz – und dann nie wieder- Festplatten geben unschöne Geräusche von sich, die Indy verliert immer ihre IP-Einstellung und zu guter Letzt hat man nach der Zeit auch noch das System/root-Kennwort der O2 vergessen – und wie man die Hintertür ins System öffnet natürlich auch.

Alles in allem ist das also eine nette Aufgabe für arbeitsarme Zeiten, zum Beispiel während der Corona-Beschränkungen.

Die Ursache für den Verlust der IP-Einstellungen nach jedem Neustart war, dass die Batterie des Dallas Chip verbraucht war – und sie ist eingegossen, also nicht so einfach zu ersetzen. China sei Dank gibt es neue Chips für wenig Geld und der Einbau ist simpel.

Das Monitor-Problem ist in so fern nicht einfach zu lösen, also die Indy keinen VGA-Ausgang hat, folglich auch nicht an einem einfachen Bildschirm betrieben werden kann. Er muss mindestens Sync-on-green unterstützen und braucht einen speziellen Adapter. Der Anschluss für den Monitor sieht genauso aus wie der der Solaris-Systeme, aber es gibt Unterschiede, die die Nutzung eines Solaris-Monitorkabels verhindern. Recherchen im Internet führen zu einer etwas schrägen Lösung:

Am Kabelstrecker müssen die Pins 1,2,4,5,6 und 7 entfernt werden, dann funktioniert das, die Indy meldet sich auf dem Bildschirm – und bootet. Die letzte veröffentlichte IRIX-Version ist 6.5, leider meldet sich der Rechner mit 6.2, da ist eine Aktualisierung fällig. Zu Glück liegen hier noch die Original-Installations-CDs von Silicon Graphics im Lager, allerdings hat die Indy kein CD-Laufwerk und das externe SCSI-Gerät ist defekt. Nun waren die SGI-Rechner zu ihrer Zeit sehr innovativ und daher gibt es die Möglichkeit, eine Installation über das Netzwerk durchzuführen – und ich habe ja auch eine O2, die ein internes Laufwerk hat. Die Installation kann also beginnen.

Sie geht wie folgt:

– O2 booten, IP-Adresse und Hostnamen ermitteln – nun gut, die kenne ich ohnehin
– Die Installations-CD #1 einlegen
– Die Indy einschalten. Sobald die Meldung „System Starting up“ erscheint, den Mainteance Mode auswählen, oder die ESC-Taste drücken, falls keine Auswahlmöglichkeit erscheint.
– Vom Menue den Punkt „INSTALL SYSTEM SOFTWARE“ auswählen
– Als Installationequelle „Remote Directory“ auswählen
– Den Namen der O2 eingeben
– Die IP-Adresse der O2 eingeben
– Quellpfad eingeben: /CDROM/dist
Installation vom Menü auswählen
– Auf den Inst-Prompt mit o2:/CDROM/dist „O2 ist dabei durch den Hostnamen zu ersetzen“
– Sobald die Meldung „Install software from [/CDROM/dist]“ erscheint, die nächste CD einlegen.

  • Die Auswahl der Installationspakete treffen und die Installation starten:
  • Inst> keep *
  • Inst> install standard
  • Inst> install prereqs
  • Inst> go

Am Ende Done auswahlen. Dann kann die Indy mit dem aktualisierten System gebotet werden.

CD Sequenz:
– Installations Tools
– Foundation 1
– Foundation 2
– Applications

Im Vergleich zur Indy war die O2 viel einfacher wieder in Betrieb zu nehmen. Sie kann ein einem Standard-VGA-Schirm betrieben werden, Tastatur und Maus werden über PS2-Stecker angeschlossen und ein funktionsfähiges CD-ROM-Laufwerk gibt es. Zwei kleine Probleme gab es zu lösen: die Tastatur war auf französisch eingestellt und das Root-Passwort, dass zur Änderung erforderlich ist, verloren gegangen. Über den Maintance-Mode der Konsole ließen sich beide Probleme leicht lösen.

Veröffentlicht unter Allgemein | Schreib einen Kommentar