Eine emotionale Geschichte der Prozessoren: IBM / 370

Der erste Teil beschrieb viele verschiedene Prozessoren bis Mitte der 90er Jahre. Es gab keinen Platz für IBM-Mainframes, da diese Systeme lange Zeit keine Prozessorchips verwendeten. Die IBM-Mainframes sind jedoch eng mit anderen Computersystemen verwandt und seit langem eines der besten Beispiele für Computertechnologie, an der sich fast jeder auf die eine oder andere Weise orientierte. Übrigens ermöglicht das Format des Habr-Blogs wie Wikipedia die Bearbeitung, wodurch der Inhalt des ersten Teils unter Berücksichtigung der eingegangenen Kommentare und anderer zusätzlicher Informationen erheblich überarbeitet werden konnte.



Dieser Teil konzentriert sich auf den Vergleich der Mainframe-Maschinensprache mit anderen Systemen, die zwischen den 70er und 90er Jahren beliebt waren. Dies sind hauptsächlich x86, 68k, VAX und ARM. Die Systeme 390 und insbesondere Z werden als sehr fragmentarisch angesehen - der Schwerpunkt liegt auf dem System 370.



Die ersten 360-Systeme wurden ab 1965 an Kunden ausgeliefert, die fortschrittlicheren 370-Systeme ab 1970. IBM ist bis heute mit diesen Systemen kompatibel! Überraschenderweise arbeiteten Mainframes vor 390 ausgelieferten Systemen, wie Sie vielleicht seit 1990 vermuten, mit 24-Bit-Adressen, dh sie konnten nicht mehr als 16 Megabyte Speicher adressieren, wie beispielsweise 68000, veröffentlicht 1979 oder 65816oder 32016, veröffentlicht 1982. VAX unterstützte nativ die 32-Bit-Adressierung. Die beliebten Prozessoren 68020 oder 80386, die Mitte der 1980er Jahre auf den Markt kamen, unterstützten ebenfalls 32-Bit-Adressen. Tatsächlich reichten 16 MB Speicher für die besten Systeme der zweiten Hälfte der 80er Jahre bereits nicht aus. Seit 1983 stellt IBM jedoch 370-kompatible Computer her, die als Erweiterung 31 Adressziffern verwenden könnten, wodurch das Speicherproblem für bessere Computer beseitigt wurde. Ungewöhnlich und einzigartig verwendeten diese Erweiterungen und 390-Systeme eine 31-Bit-Adresse anstelle einer vollständigen 32-Bit-Adresse. Im Jahr 2000 kündigte IBM das erste Z-System an, das 64-Bit-Adressierung und -Daten verwendet. Z-Systeme verwenden seit 2008 Prozessorchips. Sie versuchen seit 2007, die Z-Architektur in einem einzigen Chip mit der POWER- Architektur zu kombinieren, aber bisher erfolglos. Bisher ist es nur Intel gelungen, CISC und RISC in einem Chip zu kombinieren - Pentium Pro war 1995 der erste Chip dieser Art.





IBM System / 370-145 mit einem Bandlaufwerk 2401 und einem Drucker anstelle eines Displays, 1971. Es kann überraschend sein, dass in diesem sehr teuren System kein Display vorhanden ist, obwohl Fernseher seit mehr als 20 Jahren in Massenproduktion hergestellt werden.



Übrigens glauben einige Behörden, dass der erste serielle Personal Computer IBM war 5100 , seit 1975 in Produktion, die System 360-Anweisungen über einen Hardware-Emulator ausführen konnten. Verbesserte Versionen davon wurden bis Mitte der 1980er Jahre hergestellt. Der Wang 2200 war jedoch eher der erste . Zu Preisen (ca. 10.000 US-Dollar) waren diese ersten PCs eindeutig nicht für den Heimgebrauch bestimmt.





IBM 5100, APL-Variante



Mit dem Aufkommen der IBM PC-Architektur, die, wie sich herausstellte, jahrzehntelang die Hauptrichtungsrichtung für die Computertechnologie bestimmte, versuchte IBM 1983, fast alle damals besten Computertechnologien in einem PC XT / 370-Produkt zu kombinieren: seinen 370-Systemen IBM PC XT, Motorola 68000 und Intel 8087. Dieses XT / 370 kann als intelligentes Terminal verwendet werden, um mit einem Mainframe wie einem normalen IBM XT zu arbeiten oder um Mainframe-Software direkt auszuführen. Interessanterweise unterstützte der XT / 370 die Verwendung von virtuellem Speicher, für den zwei 68000 erforderlich waren. 1984, mit dem Aufkommen des PC AT, wurde eine verbesserte Version des AT / 370 "Personal Mainframe" veröffentlicht, die im Mainframe-Modus etwa doppelt so schnell war wie der XT. / 370. Die Geschichte solcher Systeme endete hier nicht, da in den 90er Jahren ähnliche Produkte hergestellt wurden, die 390 Systemen entsprachen.Soweit ich weiß, wurde dies für Z-Systeme nicht durchgeführt.



IBM verwendet für seine Mainframes ein eher ungewöhnliches Geschäftsmodell, bei dem Computer nicht verkauft, sondern vermietet werden. Einer der Vorteile eines solchen Modells besteht darin, dass es eine ständige Aufrüstung der Ausrüstung garantiert. Die veraltete Ausrüstung wird automatisch durch eine aktualisierte der entsprechenden Klasse ersetzt. Dieses Modell hat auch Nachteile. Ein besonders wahrnehmbarer Nachteil für diejenigen, die sich mit der Geschichte der Computertechnologie befassen, ist beispielsweise die Tatsache, dass gebrauchte Computer fast immer entsorgt werden und es daher fast unmöglich ist, sie in einem Museum zu finden.



Überrascht, ein Live-IBM 4361-System in LCM zu finden! Es besteht jedoch Grund zu der Annahme, dass dies möglicherweise kein echtes Eisen ist. Aus irgendeinem Grund haben Museumsbesucher keinen Zugriff auf diesen Computer. Es ist auch nicht klar, welches Modell dort angeblich präsentiert wird, und dies trotz der Tatsache, dass andere Computer im Museum sehr genau identifiziert werden. Unter den 4361-Systemen sind drei Modelle 3, 4 und 5 bekannt, und Modell 3 erschien später als die Modelle 4 und 5. Das System im Museum identifiziert sich jedoch selbst als Modell 1. Es ist möglich, dass dies ein Prototyp ist. Die Museumsmitarbeiter beantworteten jedoch keine direkte Frage zur Unterstützung bei der Identifizierung, obwohl sie andere und oft recht schwierige Fragen recht schnell beantworteten. Einige Merkmale des Zeitpunkts der Ausführung von Codes geben Anlass, obwohl nicht absolut solide, anzunehmen, dass der Emulator höchstwahrscheinlich mit dem Netzwerk verbunden ist. Sommer im Museum, im Zusammenhang mit covid,offensichtlich auf einen Emulator umgestellt ... Es besteht immer noch die Möglichkeit, über das Netzwerk zu den Eisen-Mainframes zu gelangenHNET , aber es ist mir noch nicht gelungen.



Aber was auch immer es ist, jeder kann sich verbinden und versuchen, auf die gleiche Weise zu arbeiten, wie hochbezahlte Spezialisten seit Mitte der 70er Jahre gearbeitet haben. Die Preise waren so, dass es heute kaum zu glauben ist. Zum Beispiel kostete eine Stunde Computerzeit Mitte der 80er Jahre mehr als 20 US-Dollar, und Sie mussten immer noch extra für den Speicherplatz bezahlen! Es stimmt, wir sprechen von der Betriebszeit des Mainframes, nicht von dem Terminal, durch das die Arbeit ging. Wenn Sie beispielsweise einen Text aus einer Stunde tatsächlicher Arbeit bearbeiten, dauerte die Bezahlung selten 5 Minuten. Die Preise für die Mainframes selbst waren ebenfalls fantastisch. Zum Beispiel erinnern sich Intel-Mitarbeiter daran, dass sie Anfang der 80er Jahre nur einen Mainframe zum Arbeiten erhalten haben. Die Leistung betrug 10 MIPS, und der Preis lag damals bei etwa 20 Millionen US-Dollar, was dreimal so hoch war wie heute! Interessant,dass Intel solche Computer den billigeren VAX-Systemen vorzog. Jetzt sogarEin Raspberry Pi hat die Größe einer Pille und kostet ein paar Dollar. Er kann problemlos über 1000 MIPS liefern. Übrigens können Sie auf einem Raspberry Pi oder fast jedem modernen Computer einen IBM / 370-Emulator ausführen, der erheblich schneller ausgeführt wird als jedes IBM-System aus den 80er oder sogar 90er Jahren. Der Emulator muss jedoch konfiguriert werden, und nicht alle nützlichen Programme für IBM / 370 sind frei verfügbar. Daher ist der freie Zugriff auf ein gut abgestimmtes System häufig der beste Weg, um den Mainframe zu umgehen. Überraschenderweise sind solche Zugangsprogramme, Terminalemulatoren 3270, sogar auf Mobiltelefonen verfügbar! Übrigens habe ich es geschafft, mein VM / CMS-System auf dem Hercules- Emulator einzurichten und die Dateiübertragung zu erledigen, aber es dauerte mindestens eine Woche.



Der Hercules-Emulator kann spätere IBM / 390- und IBM / Z-Systeme emulieren. Aufgrund von Softwarelizenzproblemen ist dies jedoch viel schwieriger. Zur Veranschaulichung solcher Probleme möchte ich den berühmten Fall anführen, in dem IBM darauf bestand, den Emulationsabschnitt aus einem bereits veröffentlichten Buch zu entfernen! In modernen elektronischen Versionen dieses Buches existiert dieser Abschnitt nicht, er kann nur in der gedruckten Ausgabe oder als separate Datei auf Websites gefunden werden, die sich mit freier Software befassen. Tatsache ist, dass die Emulation auf normalen PCs seit Anfang der 2000er Jahre spürbar schneller sein kann als die Ausführung auf viel teureren Mainframes. IBM musste daher seine Softwarelizenzen ändern, damit sie nur auf von IBM gekaufter Hardware legal verwendet werden können. Wir sprechen natürlich nicht davon, dass Emulatoren schneller sind als die besten Mainframes.Sie weisen nur ein deutlich besseres Leistungs-Kosten-Verhältnis auf.



Eine Möglichkeit, mit Z- oder 390-Systemen zu arbeiten, besteht darin, Linux auf einem Emulator dieser Systeme zu installieren. Für 390 und Z sind mindestens Ubuntu- und Debian-Distributionen verfügbar. Es ist erwähnenswert, dass die rasche Entwicklung von Linux hauptsächlich auf die erhebliche Unterstützung von IBM zurückzuführen ist. Insbesondere IBM investierte 2001 eine Milliarde Dollar in die Linux-Entwicklung.



Betrachten wir nun die Merkmale der Maschinensprache von Systemen, die mit 360 kompatibel sind. Der Basisassembler solcher Systeme heißt BAL - Basic Assembly Language. Wenn man den Gerüchten über IBM Glauben schenken will, ist Assembler überraschenderweise immer noch eine der wichtigsten funktionierenden Programmiersprachen.



Der Assembler der betrachteten Mainframes weist eine Reihe von archaischen Merkmalen auf, die in anderen bekannten Architekturen, die später erschienen, bereits fehlten. Zum Beispiel geht es um die Tatsache, dass BAL-Mnemonik die Art der Argumente bestimmt. Betrachten Sie die x86-Assembler-Anweisungen als Beispiel MOV EAX,EBXund MOV EAX,address- beide verwenden die MOV-Mnemonik. Für BAL, für solche Fälle, verschiedene Mnemonik LR und L werden in Befehle verwendet, die jeweils LR 0,1undL 0,address... Ähnliche unterschiedliche Mnemoniken ermöglichen jedoch die Verwendung von Zahlen zum Benennen von Registern, obwohl normalerweise die Makros R0, R1, ... anstelle der Zahlen 0, 1, ... das erste sind, was in Makropaketen zur Vereinfachung der Programmierung definiert wird. Ein weiterer Archaismus ist die Verwendung von Label-Jumps in bedingten Kompilierungskonstrukten, obwohl dies meiner bescheidenen Meinung nach manchmal bequemer ist als Blockstrukturen. Der bekannteste Archaismus ist jedoch die Verwendung der EBCDIC-Codierung, um mit symbolischen Informationen zu arbeiten. In dieser Codierung, die selbst für gestern seltsam ist, werden die Buchstaben des englischen Alphabets nicht in einer Reihe codiert, zum Beispiel hat der Buchstabe I einen Code 201 und das nächste J ist 209! Diese Codierung stammt aus Technologien für die Arbeit mit Lochkarten, die im Zeitalter vor dem Computer entstanden sind. System 360 unterstützt auch ASCII in Hardware, jedoch in seiner alten und längst vergessenen Version.Dabei hat das Zeichen für Ziffer 0 den Code 80, nicht wie jetzt 48. Soweit ich weiß, versuchte ASCII mit IBM-Mainframes am besten nicht einmal zu verwenden. Die ASCII-Unterstützung wurde bereits in 370 Systemen entfernt, aber in 390 Systemen auf einem neuen Niveau eingeführt. Einige BAL-Mnemoniken zeichnen sich durch ihre Superknappheit und sogar Nicht-Nemonik aus, z. B. N bedeutet AND, O - OR, X - XOR, A - ADD, S - SUBTRACT, M - MULTIPLIZIEREN, ...



Mit dem BAL-Assembler können Sie mit drei grundlegenden Datentypen arbeiten: Binär-, Dezimal- und Realzahlen. 390 Systeme verwenden einen anderen speziellen Typ für die Arbeit mit reellen Zahlen. Einige Z-Systeme können auch vollständig eindeutige Daten verwenden, z. B. dezimale reelle Zahlen. Die Anweisungen für die Arbeit mit jedem Typ bilden eine spezielle und eher isolierte Klasse von Anweisungen. Mit sehr wenigen Ausnahmen unterstützen im Allgemeinen alle 360-kompatiblen Systeme dezimale und reelle arithmetische Anweisungen. Wie Sie wissen, wurde bei x86- oder 68k-Architekturen die Unterstützung für das Arbeiten mit reellen Zahlen nicht sofort und lange Zeit als Option angeboten, und das Arbeiten mit Dezimalzahlen war nichts völlig anderes als die binäre Arithmetik - es war eher eine Erweiterung.



Für die Arbeit mit reellen und binären Zahlen werden unterschiedliche Registersätze verwendet, und für die Arbeit mit Dezimalzahlen werden Register überhaupt nicht verwendet. Das System 370 stellt 16 Allzweck-32-Bit-Register für binäre Ganzzahlen bereit, wobei der Programmzähler Teil des Prozessorstatusworts ist. Es gibt keinen separaten Stapel, er kann mit jedem Register organisiert werden - so wurde die Arbeit mit dem Stapel anschließend in ARM implementiert. Der Unterprogrammaufruf erfolgt ebenfalls wie in ARM über das Verbindungsregister. Alle Register sind fast immer austauschbar, Ausnahmen sind sehr selten. Wenn Sie das Binärregistersystem BAL mit der konkurrierenden VAX-Architektur vergleichen, werden Sie feststellen, dass der VAX ein Register weniger hat. Dies gilt auch für ARM.



Die Struktur der Operanden in Anweisungen wird denjenigen, die den x86-Assembler kennen, ziemlich vertraut erscheinen. Für Binärzahlen haben die Operanden eine Registerregister- oder Registerspeicherstruktur, und für den letzteren Fall können sowohl 32-Bit- als auch 16-Bit-Werte mit Vorzeichenerweiterung aus dem Speicher geladen werden. Zum Beispiel kann ein Analogon des x86 - Befehls ADD EAX,EBXwäre AR 0,1, ADD EAX,address- A 0,address, ADD EAX,address[EBX]- A 0,address(1), ADD EAX,address[EBX][EDX]- A 0,address(1,3). 360-Systeme und sogar ihre spätere Entwicklung wissen jedoch nicht, wie man mit Skalierung arbeitet. Sie ADD EAX,address[8*EBX]können beispielsweise nicht mit einem Befehl in BAL schreiben. Auf der anderen Seite weiß x86 nicht, wie man mit 16-Bit-Erweiterungen mit Vorzeichen arbeitet, beispielsweise mit dem Befehl BALAH 0,addressDies bedeutet, dass auf x86 zwei Anweisungen implementiert werden müssen, um eine 16-Bit-Nummer mit Vorzeichen aus dem Speicher zu nehmen und zum Inhalt von Register 0 hinzuzufügen.



Ein seltenes Merkmal von BAL ist, dass es separate Anweisungen zum Addieren und Subtrahieren von vorzeichenbehafteten und vorzeichenlosen Zahlen gibt und vorzeichenlose Operationen in BAL als Boolesche Werte bezeichnet werden. Diese Seltsamkeit wird durch das Fehlen von Flags in der 360-Architektur verursacht, die den meisten anderen Architekturen bekannt sind. Stattdessen werden nur zwei Bits verwendet, die durch unterschiedliche Anweisungen unterschiedlich gesetzt werden! Der einzige Unterschied zwischen vorzeichenbehafteten und vorzeichenlosen Operationen besteht darin, dass die beiden genannten Attributbits unterschiedlich gesetzt werden. Bei signierten Vorgängen können Sie herausfinden, ob das Ergebnis Null war, ob es positiv oder negativ war, ob ein Überlauf aufgetreten ist und bei nicht signierten Vorgängen, ob das Ergebnis Null war und ob eine Übertragung oder ein Darlehen stattgefunden hat. Bedingte Verzweigungsbefehle ermöglichen alle 16 Teilmengen von Fällen, die mit 2 Bits möglich sind.Aufgrund dieser ungewöhnlichen Arbeit mit Operationsschildern sind bedingte Sprunganweisungen heute schwer schnell zu verstehen. Obwohl BAL-Erweiterungen normalerweise recht einfach zu lesende Makros für bedingte Sprünge hinzufügen, müssen Sie nicht jedes der 4 Bits analysieren. Hier können Sie der Fairness halber sehen, dass es separate Befehle für vorzeichenbehaftete und vorzeichenlose Addition und Subtraktion gibt, beispielsweise in der MIPS-Architektur, in der es überhaupt keine Flags gibt!Zum Beispiel in der MIPS-Architektur, wo es überhaupt keine Flags gibt!Zum Beispiel in der MIPS-Architektur, wo es überhaupt keine Flags gibt!



Eine weitere seltene Funktion sind separate Befehle für vorzeichenbehaftete und vorzeichenlose Vergleiche. Ich habe ähnliche nicht nur bei MIPS, sondern auch bei MicroBlaze getroffen. In letzterem Fall ist die Übertragung übrigens das einzige unterstützte Flag der Operationsflags.



In Systemen, die mit IBM 360 kompatibel sind, gibt es keine arithmetischen Operationen mit dem Übertragsflag. Wenn wir also mit Binärzahlen arbeiten müssen, z. B. in 128-Bit-Zahlen, müssen wir das Übertragszeichen nach dem Ausführen der ersten 32-Bit-Operationen überprüfen, um deren Addition oder Subtraktion zu organisieren. und machen Sie gegebenenfalls den Übergang. Dies ist natürlich im Vergleich zu x86, ARM, 68k oder sogar 6502 sehr umständlich, aber bei viel späteren MIPS ist es noch umständlicher. Die normale Arbeit mit der Übertragung wurde nur im Z-System durchgeführt.



Es gibt keine zyklischen Verschiebungen in BAL, aber nicht zyklische Verschiebungen wie in x86 können entweder einfach oder doppelt sein. BAL verfügt jedoch über separate Verschiebungsanweisungen für vorzeichenlose und vorzeichenbehaftete Nummern, wobei nur letztere Flag-Flags setzen. Offensichtlich unterscheiden sich die Ergebnisse der Linksverschiebung in beiden Fällen nur in Flags. Spins wurden nur zu 390 Systemen hinzugefügt.



Unter den Befehlen zum Laden von Registern in BAL gibt es höchstwahrscheinlich eindeutige. Sie können das Modul einer Ganzzahl, eine Negation dieses Moduls oder eine Zahl mit einem geänderten Vorzeichen laden - etwas Ähnliches, das mir nur in der ARM-Architektur begegnet ist. Es sollte hier angemerkt werden, dass die gesamte Architektur von 360 dazu neigt, Arithmetik zu signieren, und Arithmetik ohne Vorzeichen in dieser Architektur eher zweitrangig ist. Anfangs hatte BAL keine vorzeichenlose Division und Multiplikation, sie wurden nur dem System 390 hinzugefügt. Wenn das Register geladen wird, ändern sich die Flags sowie in x86 nicht, aber es gibt einen speziellen Boot-Befehl, der die Flags setzt - dies erinnert ARM erneut daran, wo das Setzen der Flags möglich ist zu regieren.



Alle vorzeichenbehafteten arithmetischen Operationen, einschließlich Verschiebungen, können eine Überlaufausnahme auslösen. Ob eine Ausnahme ausgelöst wird oder nicht, wird durch ein spezielles Maskenflag im Statusregister bestimmt. Interessanterweise wirken sich binäre Division und Multiplikation in BAL überhaupt nicht auf Flags aus - hier können Sie sich an x86 erinnern, wo Division nur Flags verdirbt.



Bitweise logische Operationen in BAL werden durch den üblichen Satz von UND, ODER, exklusivem ODER dargestellt, dh es gibt keine separate Negationsoperation. Logische Operationen können nicht nur eine Registerregister- oder Registerspeicherstruktur aufweisen, sondern auch eine "Speicherkonstante" oder einen "Speicherspeicher" - die letztere Adressierungsmethode ähnelt der für Dezimalzahlen verwendeten. Die Adressierung vom Typ "Speicherkonstante" ist nur für die Arbeit mit Bytes möglich. Offensichtlich ist für logische Operationen im Gegensatz zur Arithmetik die Verwendung von 16-Bit-Zahlen unmöglich. Für die Speicher-zu-Speicher-Adressierung können Sie mit Daten bis zu 256 Byte arbeiten! Es stellt sich heraus, dass wir drei Datentypen für die Arbeit mit logischen Operationen haben: Bytes, 32-Bit-Wörter, Folgen von Bytes - und spezielle Anweisungen für jeden dieser Typen, was irgendwie nicht universell ist.



Logische Operationen in BAL grenzen an Operationen zum Übertragen von Bytes an. Neben der üblichen Übertragung von bis zu 256 Bytes mit einem Befehl gibt es auch eine eindeutige Anweisung zum Übertragen von Tetraden von Bytes. Sie können nur die obere oder untere Hälfte der Bytes senden, während die anderen Hälften beim Kopieren ihren Wert behalten! Solche seltsamen Operationen sind erforderlich, um die BAL-Funktionen beim Arbeiten mit Zeichen- und Dezimalinformationen zu unterstützen. Es gibt auch Weiterleitungs- und Vergleichsanweisungen für 370 Systeme für jeweils bis zu 16 Millionen Bytes, die unterbrochen werden können. Überraschenderweise können auch langsame Befehle zum Arbeiten mit Blöcken von bis zu 256 Bytes nicht unterbrochen werden, was zu einer unangenehmen Verzögerung bei der Beantwortung einer Interruptanforderung führen kann. Übertragungsbefehle können auch verwendet werden, um den Speicher mit einem bestimmten Byte zu füllen.Neben der Übertragung von Speicher zu Speicher können Sie auch einzelne Bytes auf einen bestimmten Wert setzen. Offensichtlich sind die Anweisungen zum Übertragen von Bytes, abgesehen von den neuen Anweisungen für 390 und Z, für x86 weiter fortgeschritten.



Im Register können Sie nicht nur den Wert an der angegebenen Adresse laden, sondern auch die Adresse selbst, wie in den LEA-Befehlen für x86 oder 68k. Mit dieser Funktion können Sie auch die erforderliche Konstante direkt in das Register laden, obwohl ihr Maximalwert nicht größer als 4095 sein kann. Außerdem können Sie das Register um nicht mehr als 4095 erhöhen. Die Registerdekrementierung kann jedoch nur um 1 erfolgen. Sowohl ein Inkrement als auch ein Dekrement - Dies sind Adressbefehle, daher ändern sie keine Flags. Sie können einzelne Bytes und sogar Gruppen von Bytes aus einem Wort im Speicher in das Register laden, z. B. nur das erste und dritte Byte - dies ist für alle anderen mir bekannten 32-Bit-Architekturen nur über eine Reihe von 4 Befehlen möglich. Ebenso erlaubt BAL, dass nur Teile eines Registers in den Speicher geschrieben werden.



Die BAL-Befehlsreihe ist sehr spezialisiert - in anderen Architekturen werden diese durch eine Reihe einfacherer Anweisungen implementiert. Mit der TR-Anweisung können Sie beispielsweise eine Zeichenfolge konvertieren. Ein Argument gibt die zu konvertierende Zeichenfolge und das andere die Adresse der Konvertierungstabelle an. Eine spezielle Variante dieser Anweisung, TRT, kann verwendet werden, um eine bestimmte Zeichenfolge zu scannen und leere Zeichen zu überspringen - dies ist die Funktionalität des Standardaufrufs von C strpos. Die ED- und EDMK-Anweisungen sind völlig einzigartig - sie haben die Funktionalität des primitiven Sprintf! Bei fast allen Zeichenfolgenoperationen ist die maximale Zeichenfolgenlänge jedoch auf maximal 255 Byte begrenzt, wodurch die Leistung erheblich verringert wird.



In BAL ist es schwierig, mit vorzeichenlosen 16-Bit-Werten zu arbeiten, da keine Rotation oder SWAP-Befehle vorhanden sind. Mit 390 Systemen hat sich dieses Problem verbessert. Einige BAL-Befehle sind veraltet, zum Beispiel wurde der MVO-Nibble-Shift-Befehl durch den bequemeren SRP ersetzt. Für Blockübertragungen und Vergleiche ist es besser, die neuen Anweisungen zu verwenden. Aufgrund der Tatsache, dass sie eine andere Art der Adressierung verwenden, ist dies in einigen seltenen Fällen möglicherweise nicht optimal.



Es gab bereits Beispiele für die vier grundlegenden BAL-Adressierungsmodi. Es gibt auch einen fünften für Befehle mit drei Adressen. Modi wie die automatischen Inkrementierungs- oder Dekrementierungsmodi VAX, 68k, PDP-11 oder sogar 6809 sind in BAL nicht verfügbar. Es gibt auch keine DID-Modi wie VAX, 68020 oder PDP-11. Und natürlich ist BAL im Gegensatz zu VAX- oder PDP-11-Assemblern völlig nicht orthogonal. BAL ist den x86- und ARM-Assemblern, den erfolgreichsten modernen Architekturen, am nächsten. Die Reihenfolge der Operanden in BAL von rechts nach links ist dieselbe wie in Intel Assembler für x86 oder in ARM Assembler und dementsprechend nicht wie bei VAX, PDP-11 oder 68k. Obwohl die Reihenfolge der Bytes in Daten in BAL von Major bis Minor (MSB) reicht, was sich von x86, ARM oder VAX unterscheidet, entspricht sie der für 68k oder MIPS akzeptierten Reihenfolge.



Operationen mit Dezimalzahlen werden in BAL nur durch Speicher-zu-Speicher-Adressierung implementiert. Dezimalzahlen können in Speicherblöcken mit bis zu 16 Byte angegeben werden, sodass Zahlen mit bis zu 31 Dezimalstellen verwendet werden können. Dies entspricht der Genauigkeit einer 107-Bit-Binärzahl. Daher können nur die modernsten Programmiersysteme mit binären Ganzzahlen größere Werte verarbeiten als 360-Systeme vor fast 60 Jahren! Natürlich ist es möglich, beliebig große Zahlen durch binäre Arithmetik zu implementieren, aber aus irgendeinem Grund gab es bis vor kurzem keine populären Programmiersprachen, die Zahlen unterstützen, die größer als das alte System 360 sind. Selbst jetzt ist die Unterstützung für 128-Bit-Ganzzahlen für x86 normalerweise nur eine inoffizielle Erweiterung, z. B. für GCC.



Dezimalzahlen auf BAL werden eindeutig dargestellt, sie müssen ein Vorzeichen speichern - dies ist bei VAX, x86, 68k, ... nicht der Fall. Außerdem wird das Vorzeichen im letzten Byte der Zahlendarstellung gespeichert! Bei Dezimalzahlen unterstützt BAL alle grundlegenden Operationen direkt: Addition, Subtraktion, Multiplikation und sogar Division - dies ist auch in keiner anderen mir bekannten Architektur zu finden. Darüber hinaus bietet BAL Anweisungen zum Kopieren, Vergleichen und Verschieben von Dezimalzahlen. Die oben genannten MVO- und SRP-Anweisungen sind für genau solche Schichten ausgelegt. Operationen können nur mit gepackten Dezimalzahlen ausgeführt werden, aber um sie zu drucken, müssen sie entpackt werden. Um entpackte Ziffern in BAL darzustellen, ist auch ein Zeichen erforderlich, das in diesem Fall keinen Platz beansprucht, da es in der oberen Tetrade platziert ist, was besondere Arbeit erfordert Notizbuch vor dem Drucken.Es ist seltsam, dass die Operationen zum Ein- und Auspacken nur mit nicht mehr als 16 Bytes der dekomprimierten Dezimalzahl funktionieren können, wodurch nur 15-Bit-Zahlen mit ihnen verwendet werden können. Dieses unangenehme Problem kann durch Verwendung von ED oder EDMK zum Auspacken von Anweisungen gelöst werden. Das Packen einer großen entpackten Anzahl muss jedoch durch eine nicht sehr einfache Folge von Anweisungen erfolgen. 390 Systemen wurden neue Anweisungen hinzugefügt, um dieses Problem zu beheben. Seltsamerweise funktionieren die Anweisungen zum Ein- und Auspacken mit allen Binärdaten, nicht nur mit Dezimalzahlen.Dieses unangenehme Problem kann gelöst werden, indem ED oder EDMK zum Auspacken von Anweisungen verwendet werden. Das Packen einer großen entpackten Anzahl muss jedoch durch eine nicht sehr einfache Folge von Anweisungen erfolgen. 390 Systemen wurden neue Anweisungen hinzugefügt, um dieses Problem zu beheben. Seltsamerweise funktionieren die Anweisungen zum Ein- und Auspacken mit allen Binärdaten, nicht nur mit Dezimalzahlen.Dieses unangenehme Problem kann gelöst werden, indem ED oder EDMK zum Auspacken von Anweisungen verwendet werden. Das Packen einer großen entpackten Anzahl muss jedoch durch eine nicht sehr einfache Folge von Anweisungen erfolgen. 390 Systemen wurden neue Anweisungen hinzugefügt, um dieses Problem zu beheben. Seltsamerweise funktionieren die Anweisungen zum Ein- und Auspacken mit allen Binärdaten, nicht nur mit Dezimaldaten.



BAL verfügt über spezielle eindeutige Anweisungen, mit denen Sie eine Binärzahl auf einmal in eine gepackte Dezimalzahl und umgekehrt konvertieren können. Für eine Dezimalzahl in diesen Anweisungen werden immer 8 Bytes zugewiesen, dh 15 Ziffern und ein Vorzeichen. Das 32-Bit-Register reicht jedoch nur aus, um eine vorzeichenbehaftete Zahl darzustellen, die einer 9-stelligen Dezimalzahl entspricht, sodass nicht jede Dezimalzahl im richtigen BAL-Format in einem Befehl in eine Binärzahl konvertiert werden kann. Für Z-Systeme gibt es erweiterte Anweisungen für solche Konvertierungen.



Sprungbefehle in BAL unterscheiden sich darin, dass sie in der Regel gepaart sind - die Sprungadresse kann sowohl explizit als auch durch den Inhalt des Registers festgelegt werden - in vielen anderen Architekturen sind Sprünge entlang des Inhalts des Registers nur für bedingungslose Sprünge. Übrigens gibt es in BAL keine bedingungslosen Sprünge, sie werden implementiert, indem eine immer wahre Bedingung festgelegt wird, die der ARM-Architektur ähnlich ist. Die bedingte Verzweigung in BAL hat, wie bereits erwähnt, eine eindeutige Syntax. Betrachten Sie zum Beispiel die AnweisungBT 9,addressDies bedeutet, einen Sprung zu machen, wenn die Bedingungen 0 und 3 erfüllt sind, aber Bedingungen nach unterschiedlichen Befehlen unterschiedliche Bedeutungen haben. Nach einer vorzeichenbehafteten Addition bedeuten diese Bedingungen beispielsweise, dass "das Ergebnis 0 ist oder ein Überlauf aufgetreten ist", und nach einer vorzeichenlosen Addition "das Ergebnis ist 0 und es gab keinen Übertrag oder das Ergebnis ist nicht 0 und es gab einen Übertrag". Trotz der Umständlichkeit und einiger Redundanz muss zugegeben werden, dass ein solches System zum Arbeiten mit Bedingungen für Übergänge wahrscheinlich das flexibelste von allen bekannten ist. Die Neun im Befehl aus dem Beispiel wird in der Binärdarstellung 1001 verwendet, dh sie setzt die Bitnummern - das System selbst codiert alle Kombinationen von Bedingungen mit 4 Bits und wird auch in ARM verwendet. Zusätzlich zu den bedingten Sprüngen in BAL gibt es Gegensprünge mit einem Dekrement, ungefähr das gleiche wie in den Assemblern Z80, x86, 68k, PDP-11, ... Aber BAL hat auch zwei völlig eindeutige Anweisungen für Sprünge,Dies kann je nach Nummer eines der Registeroperanden eine Adresse mit drei oder vier Adressen sein! In diesen eindeutigen Befehlen werden zwei Register addiert und die resultierende Summe mit dem Inhalt eines anderen Registers verglichen. Das Ergebnis dieses Vergleichs besteht darin, zu bestimmen, ob gesprungen werden soll oder nicht. Es wird angenommen, dass solche ungewöhnlichen Anweisungen für die Arbeit mit Sprungtabellen nützlich sind.



Wie bereits erwähnt, wird der Aufruf von Unterprogrammen in BAL ohne Verwendung des Stapels implementiert, indem einfach die Rücksprungadresse in einem Register gespeichert wird. Die BAL-Befehle für solche Aufrufe, von denen einer auch als BAL bezeichnet wird, bewahren jedoch nicht nur die Rücksprungadresse, sondern auch einen Teil des Statusregisters, insbesondere Bedingungsflags, die Länge des aktuellen Befehls und sogar eine Maske für optionale Ausnahmen, beispielsweise für Ganzzahl oder Dezimalzahl Überläufe - dies wurde bereits oben erwähnt. Eine solche ungewöhnlich erweiterte Speicherung von Informationen beruht auf der Tatsache, dass der Befehlszähler in der Mainframe-Architektur der obere Teil des Maschinenstatusworts ist und die Anweisungen zum Aufrufen von Unterprogrammen seinen oberen Teil mechanisch beibehalten. Es gibt keine speziellen Befehle für die Rückkehr von Unterprogrammen. Sie müssen den üblichen Sprung zur Adresse im Register verwenden.In 390 Systemen sind im Zusammenhang mit dem Übergang zur 31-Bit-Architektur neue Anweisungen zum Aufrufen und sogar Zurückkehren von Unterprogrammen erschienen. Neue Anweisungen ermöglichen die flexible Verwendung von Codes, die in verschiedenen Modi in einem Programm ausgeführt werden.



Um schnell Unterbefehle mit einem Befehl aufzurufen, verfügt BAL über einen eindeutigen EX-Befehl, der den Befehl an einer bestimmten Adresse ausführt und mit dem nächsten Befehl fortfährt. Der EX-Befehl kann den aufgerufenen Befehl ändern, wodurch Sie jedes gewünschte Register im aufgerufenen Befehl verwenden oder Parameter für die Massenübertragung von Bytes festlegen können. Eine ähnliche, aber einfachere Anweisung ist auch im Befehlssystem TMS9900 enthalten.



Anfangs hatte BAL keine relativen, verschiebbaren Übergänge wie Z80 oder x86. Sie wurden nur 390 Systemen hinzugefügt.



Die Befehle SPM, TM, TS, STCK und STPT sind ebenfalls etwas ungewöhnlich. Mit dem ersten Befehl kann ein Befehl alle Operationsflags und die optionale Ausnahmemaske setzen. Mit dem TM-Befehl können Sie eine Gruppe von Bits überprüfen und drei Fälle identifizieren: alle Nullen, alle Einsen, eine Mischung aus Nullen und Einsen. Diese Überprüfung kann nicht von einem Befehl in anderen Architekturen durchgeführt werden. TM funktioniert jedoch nur mit einzelnen Bytes im Speicher. TS wird verwendet, wenn mit mehreren Prozessoren gearbeitet wird - es gibt einen ähnlichen Befehl für 68k. Der STCK-Befehl liest den Wert des externen (!) Timers und der STPT-Befehl liest den Wert des internen Timers, der in die Prozessorschaltung eingebaut ist. Seltsam, aber STPT ist privilegiert, STCK jedoch nicht.



Erwähnenswert sind auch die CS- und CDS-Anweisungen, die Multiprocessing-Arbeiten unterstützen sollen. Sie wurden für 370 Systeme implementiert, dh sie sind seit Anfang der 70er Jahre verfügbar. In x86 wurde das Analogon von CS, der Befehl CMPXCHG, nicht früher als 1987 implementiert, und das Analogon von CDS, der Befehl CMPXCHG8B, wurde erst 1994 implementiert!



Von 370 Systemen wird der STIDP-System-Selbstidentifizierungsbefehl eingeführt, der privilegiert und nicht sehr informativ ist. Für x86 wurde dieser Befehl wesentlich leistungsfähiger. Sie können hier auch feststellen, dass mit IBM 4361 in LCM jeder Benutzer STIDP ausführen kann. Dies ist offensichtlich eine durch Ausnahmen ausgelöste Emulation.



Die vier adressierbaren BAL-Modi geben zwei Operanden für den Befehl an, der fünfte Modus gibt Befehle mit drei Adressen an. Wenn Sie jedoch einige der Informationen ignorieren, können Sie Unicast-Befehle verwenden, und wenn Sie implizite Informationen verwenden, können Sie Befehle mit vier Adressen verwenden. Bei der Adressierung spielt das Register 0 eine besondere Rolle: Es wird dort einfach ignoriert. Auf diese Weise können Sie die Basis und den Index bei der Berechnung der Adresse ignorieren. Alle BAL-Anweisungen bestehen ausschließlich aus 2, 4 oder 6 Bytes. Es sieht aus wie ein 68000 oder PDP-11, aber nicht wie x86, VAX oder ARM.



Dem 390-System wurden mehrere weitere Adressierungsmodi hinzugefügt, wodurch sich die Anzahl auf 18 erhöhte. Die Anzahl der Anweisungen hat sich ebenfalls erheblich erhöht. Unter den neuen Anweisungen gibt es sogar solche, die die Arbeit mit Unicode unterstützen - dies ist für x86 immer noch nicht verfügbar! Unter den neuen Anweisungen für 390 Systeme gibt es weitere einzigartige. Dem Z-System wurden mehrere weitere Adressierungsmodi hinzugefügt, und die Gesamtzahl der Befehle für das moderne Z ist sehr groß und wahrscheinlich sogar höher als die Anzahl der Befehle für das moderne x86-64!



In den Systemen 360, 370 und 390 betragen die Offsets beim Zugriff auf Daten im Speicher wie in ARM 12 Bit, dh nicht mehr als 4095, was nicht sehr praktisch ist. Bei großen Codes kann es zu einem Mangel an Registern für die Basis kommen. In x86 beträgt dieser Offset 16 Bit, was natürlich viel praktischer ist. Das Z-System bietet jedoch Unterstützung für die 20-Bit-Offset-Adressierung, was natürlich noch besser ist. Es ist jedoch erwähnenswert, dass in x86-64 oder sogar 68020 der Offset 32 ​​Bit betragen kann. Wie bereits erwähnt, konnten Systeme vor 390 wie ARM bei der Arbeit mit Registern keine großen Konstanten verwenden. Die x86-Architektur ist hier viel flexibler. Daher war es bei Verwendung eines Assemblers mit einem 360- oder 370-System häufig erforderlich, Literale, Pseudokonstanten, zu verwenden, was etwas langsamer ist.



In Bezug auf die Leistung hatten Systeme, die mit IBM / 360 kompatibel sind, immer gute Indikatoren. Meine Experimente mit 4361-1, insbesondere im ProjektBerechnungen der Zahl π mit dem Shutter-Algorithmus zeigten sehr gute Timings. Die 4361-1-Anweisungen werden praktisch ohne Latenz ausgeführt, wie ARM oder andere moderne Prozessoren. Aufgrund eines etwas umständlichen Befehlssystems aus den 60er Jahren, insbesondere aufgrund der fehlenden Division durch einen 16-Bit-Teiler, lag das Ergebnis in Bezug auf die Effizienz der Prozessorelektronik auf dem Niveau von 80186. Dies ist etwa 80% schlechter als das Ergebnis. Der damals beste VAX-Computer, Modell 785. Der Mainframe in LCM ist jedoch eindeutig nicht der beste unter den damals verfügbaren IBM-Mainframes. Es ist auch wichtig anzumerken, dass Mainframes Kanäle verwendeten, spezialisierte Prozessoren, die E / A sehr schnell machten, viel schneller als die meisten modernen Computer.



Als Student arbeitete ich 1987 im Batch-Modus und 1989 im Dialog mit einem inländischen Klon von IBM / 370, EC-1045. Für den Batch-Modus mussten Lochkarten vorbereitet werden. Zu dieser Zeit benutzte ich bereits einen Heimcomputer und daher hinterließ die Verwendung archaischer Lochkarten nicht den besten Eindruck. Aber der interaktive Modus war nicht schlecht, nur er brach oft mit einer großen Anzahl von Benutzern. Deshalb kamen einige Schüler um 4 Uhr morgens zur Arbeit! Seitdem konnte ich mich nicht mehr mit Mainframes befassen. Erst kürzlich habe ich mich entschlossen, mich mit dieser Meilensteintechnologie für die Geschichte der Computer durch Emulation zu befassen.



Das Klonen der IBM 360 war sehr beliebt. Klone wurden in England, Deutschland, Japan und anderen Unternehmen in den USA hergestellt. In der UdSSR nahm dieses Klonen eine sehr dramatische Konnotation an. Für dieses Klonen wurden fast alle inländischen Entwicklungen im Bereich der IT gefaltet, von denen einige sehr vielversprechend waren. Insbesondere das Thema Uralcomputer wurde geschlossen , worüber der berühmte Informatiker Charles Simonyi später mit Herzlichkeit sprach . Das BESM-10-Projekt wurde ebenfalls abgeschlossen, obwohl die Maschinen der vorherigen BESM-6- Klasse hinsichtlich der Geschwindigkeit mit der IBM 360 vergleichbar waren. Für dieses Klonen wurde auch ein fast abgeschlossener Vertrag mit ICL vereitelt. Vielleicht hätte die britische IT-Branche mit diesem Vertrag eine neue Dynamik erhalten und wäre nicht zurückgegangen. Nur SupercomputerElbrus überlebte möglicherweise aufgrund ihrer Verbindungen zur Verteidigungsindustrie die "Clone Invasion", die Dijkstra als den größten US-Sieg im Kalten Krieg bezeichnete.



Wie sich Menschen erinnern, die in der UdSSR mit Großrechnern gearbeitet haben, waren inländische Klone äußerst zuverlässig und erforderten ständige Aufmerksamkeit des Servicepersonals. Während die ursprünglichen amerikanischen IBM-Mainframes zu den zuverlässigsten Computern ihrer Zeit gehörten. In sowjetischen Klonen wurden manchmal mehr als ein Dutzend (typischerweise mehr als 5) Kilogramm Edelmetalle, Gold, Platin, Palladium und Silber verlegt, was jedoch nicht dazu beitrug, die Situation zuverlässig zu korrigieren. Aufgrund der großen Anzahl hochliquider Werte ist es schwer vorstellbar, dass ein funktionierender inländischer Klon irgendwo überleben könnte.



Interessanterweise verließ der Hauptentwickler des IBM 360 IBM und gründete Amdahl, das sich seit mehr als zwei Jahrzehnten auf die Herstellung von Systemen spezialisiert hat, die mit IBM-Mainframes kompatibel sind und gleichzeitig in Bezug auf Geschwindigkeit und Zuverlässigkeit zu niedrigeren Preisen etwas überlegen sind. Infolgedessen wurde Amdahl aufgrund der großen Veränderungen auf dem Mainframe-Markt wie ICL Teil des japanischen Unternehmens Fujitsu.



Neben den IBM / 360-Architekturcomputern gab es noch andere Mainframes. In den 60er Jahren erhielten amerikanische Mainframe-Hersteller inoffiziell den klangvollen Namen Schneewittchen und die sieben Zwerge. Es ist wahrscheinlich leicht zu erraten, dass Schneewittchen IBM war. Mainframes von Originalarchitekturen wurden auch in anderen Ländern hergestellt. Die britische Architektur ICL 1900 verdient besondere Erwähnung.



Wie ich bereits geschrieben habe, konnte ich eine funktionierende Konfiguration für VM / CMS 6 einrichten. Es stellte sich jedoch heraus, dass der XEDIT-Editor nicht frei verfügbar ist und eine einfache Bearbeitung zu eigenartig und unpraktisch ist, sodass Sie die Texte auf dem Host bearbeiten müssen. Es wurde auch festgestellt, dass ein Standardprogramm zum Übertragen von Dateien vom Terminalemulator zum Mainframe und umgekehrt nicht verfügbar war, was die Verwendung virtueller Lochkarten für eine solche Übertragung erforderte. Eine weitere unangenehme Überraschung kam im Zusammenhang mit dem Debuggen auf. Der Befehl DEBUG unterstützt das Steppen nicht! Eine solche Möglichkeit gab es sogar für den DDT-Debugger für den 8080-Prozessor. Es ist auch überraschend, obwohl weniger kritisch, dass DEBUG nicht weiß, wie man eine Demontage durchführt, die oft selbst in die einfachsten Monitore von 70er-Prozessoren eingebaut wurde.Long Line Wrapping und End-of-Line-Steuerzeichen werden auf niedriger Ebene unter CMS nicht unterstützt! Daher müssen Sie beim Drucken aus Assembler-Programmen die Zeilen manuell formatieren, damit sie nicht über den rechten Bildschirmrand hinaus verschwinden, und die letzte Zeile mit Abschlussfeldern füllen. Ungewöhnlich ist auch das Fehlen eines automatischen vertikalen Bildlaufs.



Wer zum ersten Mal mit Mainframes arbeiten möchte, sollte bedenken, dass Mainframes ein riesiges Ökosystem sind, in dem viele bekannte Konzepte unterschiedlich interpretiert werden können. Zum Beispiel ist das einfache Konzept einer Datei nicht vorhanden. Eines der Hauptattribute der Datei ist die Datensatzgröße. Für Linux- oder Microsoft Windows-Dateien gibt es nichts Vergleichbares. Die Dateien selbst unterscheiden sich in den Zugriffsmethoden, und es wurden schriftliche und möglicherweise nicht dünne Bücher darüber geschrieben. Es ist auch ungewöhnlich, dass in CMS der Datenträgername am Ende des vollständigen Dateinamens geschrieben wird und Name, Erweiterung und Datenträger durch Leerzeichen getrennt sind und der Datenträgername selbst aus irgendeinem Grund als Dateimodus bezeichnet wird. Ich würde auch gerne das Multitasking- MVS aussortieren , soweit ich in der UdSSR weiß, dass sie es nie geschafft haben.



Im Allgemeinen ist es etwas unerwartet, dass einige bekannte Betriebssysteme, die auf sehr teuren Computern verwendet wurden, die Arbeit mit Dateiverzeichnissen nicht unterstützten, was sie mit den allerersten und primitivsten Betriebssystemen für Mikrocomputer wie CP / M oder Commodore DOS gleichsetzte. Es ist kein Zufall, dass CMS manchmal als CP / M für Mainframes bezeichnet wurde. Überraschenderweise wurde meines Wissens die Unterstützung für Kataloge im CMS nie eingeführt, obwohl die letzte Version des Systems aus dem Jahr 2018 stammt. Aus irgendeinem Grund wurde die Arbeit mit Katalogen für teure Computer vor den 80er Jahren häufig nur unzureichend unterstützt. Zum Beispiel gab es in DEC RT-11 keine solche Unterstützung und sogar eines der besten Betriebssysteme für PDP-11, RSX-11, unterstützt nur zweistufige Verzeichnisse. Das bis in die 2000er Jahre beliebteste IBM-Betriebssystem war MVS (1974), und selbst hier wurden die Kataloge nur teilweise erstellt, wie in Apple MFS (1984). Obwohl in Unix (1973), MS-DOS (seit 1983) oder sogar 8-Bit-Apple ProDOS (1983), war dies von Anfang an in Ordnung. Die fortschrittlichste Dateiverwaltung wurde in VAX / VMS (1977) angeboten, wo neben Verzeichnissen auch die Dateiversionierung integriert ist.



Interessanterweise ist die Skriptsprache für CMS, MVS und einige andere IBM Betriebssysteme, REXX , eine abgekürzte Version der Batch-Dateisprache für den Commodore Amiga geworden.



Mainframe-Software ist normalerweise zweifarbig. Farbterminals wurden relativ selten verwendet und daher gibt es nur wenige Farbprogramme. Es gibt auch wenige Programme mit dynamischer Grafik. Häufige Bildschirmaktualisierungen führen zu einem unangenehmen Flackern.



Dynamische Demo, ausgeführt auf dem Emulator IBM 4381 in LCM, Terminal 3270-3



Abschließend kann ich meine Bewunderung für die IBM Technologien zum Ausdruck bringen. Sie zeichnen sich seit jeher durch ihre einzigartige Originalität und ihr hohes Niveau aus. Besonders hervorzuheben ist die sehr gute Qualität der Dokumentation, die auch für moderne Systeme gemeinfrei ist. IBM zeigt eine enorme Dynamik in der Technologieentwicklung, obwohl es eines der größten Unternehmen der Welt ist. In Bezug auf die Anzahl der Mitarbeiter entspricht es fast Microsoft, Google und Intel zusammen!



Das Mainframe-Thema ist riesig. Natürlich konnte ich nur einen kleinen Teil dessen schreiben, was es enthalten kann. Für Klarstellungen und zusätzliche Informationen wäre ich sehr dankbar.



Dieses Material ist auch in englischer Sprache erhältlich .



All Articles