 Hallo, ich bin Harbrock und ich erzähle euch heute auch wieder Geschichten aus der Kurbel-Gruft. In diesem Fall, was der Anwender sieht, spricht die Umgebung, die die Benutzer bzw. Sachbearbeiter im Unternehmen dann sehen. Ein bisschen was zu mir. Ich arbeite seit mehr als 15 Jahren bei einer Versicherung in der Anwendungsentwicklung. Davon habe ich mehr als zehn Jahre nur für den IBM-Großrechner unter Kobol programmiert. Noch ein Hinweis. Falls ich beim Sprechen hin und wieder etwas stocken sollte, das liegt daran, dass ich in Bildern denke. Dann dauert die Übersetzung von Bildern in Text ein bisschen länger. Zwar krete ich heute im Deutschen ausgesprochen, ZIX, das Customer Information Control System. Im Englisch nenne ich KIX oder CICS, üblich, aber ich bleibe bei der deutschen Aussprache. Das System wurde Anfang der 70er Jahre entwickelt und ist unter anderem dafür da, die Oberfläche, die dann die Anwendung des Großrechners sehen zu erzeugen. Etwas triviawissen. In der DDR gab es eine Kopie unter dem Namen Datenkommunikationssystem DAKS. Für die im Ostblocker gebräuchlichen Nachbauten von IBM Großrechnern. Wovon rede ich überhaupt, wenn ich von dem Großrechner rede? Ich beziehe mich da jetzt auf die IBM-Maschinen, die ab den 70er Jahren gebräuchlich waren. Unter OSA 370, beziehungsweise die Nachfolgergenerationen, was dann der Z-Series ist, die es immer noch gibt. Die sind von der Konstruktion her auf Zuverlässigkeit und Datendurchsatz optimiert. Es sind Redundant ausgelegt und das mittlerweile in einer durchaus beindruckenden Art und Weise. Ich kenne wenige Rechner, wo im laufenden Betrieb flüssigkeitsgekühlte Prozessoren ausgetauscht werden können, ohne dass ein Rechner groß stört. Solange noch Prozessoren da sind. Die Konstruktion sah so aus, dass der Rechner eigentlich nur außer Prozessoren und Hauptspeicher besteht. Die Datenspeicherung erfolgte extern und da die Rechner so teuer waren in den 70er Jahren war es nicht so ein gewöhnliches, dass für die gesamte Firma nur ein Computer zur Verfügung stand. Außer in extrem großen Firmen oder Unternehmen oder an Universitäten oder so. Das Bild im Hintergrund, wer erratste, eine Anlage, wie man sie in den 70er Jahren im Rechenzentrum finden konnte. Die großen Kästen auf der rechten Seite sind der eigentliche Rechner, also mit Prozessoren und Hauptspeicher. Davor etwas schlecht zu erkennen, gewissermaßen ein Fernschreiber als eine Ausgabegerät. Auf der linken Seite vorne ein Lochkartenleser und hinten mehrere Festplatten. Wobei ganz hinten im Eck, was so aussieht wie Tortencontainer, waren die damals üblichen, auszusparen Plätter der Festplatten. Ein und Ausgabe beim Großrechner erfolgte ganz früher über Lochkarten bzw. Lochstreifen und als Eingabe ein Gerät. Und Ausgabe dann zum Beispiel über Kettendrucker auf Endlospapier oder auch dann in Lochkarten oder Lochstreifenstanze. Irgendwann kam man auf die Idee, Schreibmaschinenterminalisanten Großrechner anzuschließen, also gewissermaßen ein Drucker und eine Tastatur. Damit man nicht immer Lochkarten lochen musste und dann sozusagen länger auf eine Ausgabe warten musste. Irgendwann kamen Datensichtgeräte in Gebrauch. Also im IBM-Fall 3270er Terminals, so auch ab Anfang der 70er Jahre. Sieht zwar aus wie ein PC, besteht aber nur aus einem Monitor, eine Tastatur und ein bisschen Elektronik, die im Grunde nur die Daten, die auf dem Monitor dargestellt werden, puffert und nutzeeingaben. Auch zwischen Speichert und puffert und bei Betätigung bestimmter Tasten dann wieder an Gerächen erschickt, zur Weiterverarbeitung. Also zuerst gab es nur einen Monochrom, also Grünaufschwarz oder Bernsteinaufschwarz. Später waren es dann Achtfarben und auch so Sonderfunktionen wie blinkende Nutterstrichen. Aber allgemein nur Text oder halt etwas, was im Grunde ASCII-Grafik entspricht, auch wenn der Zeichensatz beim IBM Großrechner nicht ASCII ist, sondern Aptik. Oder für Spezialanwendungen gab es dann auch irgendwelche Vectagrafik Terminals, aber im Banken- und Versicherungsumfeld mit Sicherheit nicht. Also kann ich dazu dann nichts sagen. Ja, irgendwann sind die Terminals langsam ausgestorben bzw. die PCs in den Büros haben sich durchgesetzt und um die gleiche Oberfläche weiter nutzen zu können, wurden dann auch Terminal-Emulationen für den PC entwickelt. Also ein Programm, das z.B. unter Windows läuft und die gleiche Kommunikation mit dem Großrechner erledigt wie das Terminal. Und irgendwann kam man dann dazu, dass diese Terminal-Oberflächen doch hässlich bzw. veraltet aussehen und hat dann PC oder Online-Anwendungen geschrieben, die halt im Grunde die gleichen Daten nehmen, aber hübscher darstellen. Ja, beim Großrechner muss man zwei Hauptbetriebsarten unterscheiden. Das wäre einmal der Batchbetrieb. Das Programm läuft ohne Interaktionsmöglichkeit durch üblicherweise Vermassendatenverarbeitung. Ja, wenn es heute noch genutzt wird, dann üblicherweise nachts. Und Ausgabe erfolgte früher auf dem Kettendrucker oder halt doch auch irgendwo auf der Datenspeichern. Und da, wie schon gesagt, Großrechner bei Banken und Versicherungen irgendwo im Hintergrund noch weit verbreitet sind, ist das wohl auch häufig der Grund, wenn ihr zu nerd-kompatiblen Zeiten, sprich nachts, irgendwas im Online-Banking machen wollt und das nicht so ganz funktioniert. Das wäre dann halt die Batch-Lücke. Ja, der zweite Betrieb, Modus ist der Online-Betrieb über ein, also Unternutzung eines Transaktionsmonitors und Beispiele werden im STC oder das ZIX, um das es hier in den Vorträgen hauptsächlich geht. Transaktionsorientiert, die ganzen Nutzeraktionen der Sachbearbeiter werden dann auch sinnvoll gescheduled. Dass sie schön hintereinander ablaufen und sich trotzdem wie ein Dialogbetrieb anfühlt und das System verwaltet dann auch Rechnerressourcen, sodass sich Transaktionen dann bei den Datenbeständen nicht ins Gehege kommen. Es sind auch Hintergrundtransaktionen mögliche, was dann im Grunde auch wieder wie ein Batch-Programm abläuft, ohne Interaktionen mit einem Benutzer. Überblick über die Aufgaben und Eigenschaften des Transaktionsmonitors. Die Idee ist, dass die Ressourcen großrechnen, dass sie gemeinsam genutzt werden können von durchaus vielen Personen, dann auch im Dialogbetrieb und auch dass ein und dasselbe Programm gleichzeitig mehr vorausgeführt werden kann, ohne dass es sich dann irgendwie mit einer Datenbeständen verhakt oder so. Die Kommunikation mit den Terminals ist auf eine geringe Datenrate und die von der Hardware nicht sehr komplexen Terminals ausgelegt. Im Fall von ZIX sieht das dann so aus. Es gibt Sprachunterstützungen für Assembler, COBOL, C, C++, PL1 und mittlerweile auch Java. Das ZIX hat noch einen Adressraum für alle Benutzer, was man bei der Programmentwicklung dann durchaus berücksichtigen muss, damit sich mehrere Instanzen, dasselben Programms, nicht irgendwie die Daten kaputt schreiben, bzw. dass die Übertragen von Daten dann nur erfolgt, wenn es auch tatsächlich beabsichtig ist. Das erledigt die Programmverwaltung, Zugriffe auf verschiedenste Datenressourcen und Verwaltung des Hauptspeichers. Das bedeutet aber auch, dass Zugriffe auf externe Ressourcen nur über ZIX erfolgen dürfen. Also eine Displayausgabe ist damit nicht zulässig. Das läuft nämlich dann, na, alles sind so gleiche Lock im Rechenzentrum und die Kollegen sind dann irgendwann genervende Meldungen auflaufen, mit denen sie nichts anfangen können und die dort auch nicht sein dürften. Mit den ganzen Funktionen stellt das ZIX im Grunde schon ein eigenes Betriebssystem aus Sicht der ZIX-Programme dar. Ja, dann das relevanteste für aus Sicht der Anwender, also in Unternehmen der Sachbearbeiter, Aufbau der Masken. Ja, das übliche ist eine Textmaske mit 24 Zeilen und 80 Spalten. Das wären also 1920 Beid. Man kann dann für verschiedene Bereiche einen festen Text, Eingabe und Ausgabefelder definieren bzw. Felder, die sich als Ein- und Ausgabefeld nutzen lassen. Unten sind zwei Beispiele, wie solche Masken dann aussehen können. Ja, und pro Datenfelder gibt es dann ein Beid zusätzlicher für die Eigenschaften und dieses Beid ist dann auch belegt ein Zeichen auf der Maske. Da wird aber dann nichts dargestellt. Und aus der Struktur, die man für die Maske definiert, wird einmal die Maskendarstellung für das ZIX generiert und dann auch die Datenstruktur für das Programm. Also ist dann natürlich programmiersprachend abhängig. In meinem Fall ist es dann, da habe ich die Koboldarstellung im Talk. Und natürlich gibt es verschiedene Editoren, um das Maskendesign zu vereinfachen und früher gab es dann aber tatsächlich entsprechende Karo-Formulare mit 24 x 80 Kästchen und außenrum halt noch ein paar Stellen, wo man weitere Informationen zur Maske eintragen konnte. Ja, so sieht dann die Struktur-Beschreibung in diesem Fall in einer sehr einfachen Maske aus. Und ja, ich habe hinten die Sternchen für Befehlgedien in der nächsten Zeile weiter weggelassen. Das wäre etwas schwierig gewesen, sinnvoll zu positionieren. Also in diesem Fall wird ein Mapset, also eine Beschreibung, die mehrere Masken enthalten kann, definiert mit dem Namen ZIX Abends 1. Ja, und diese ganzen DFH Anweisungen, das sind in der Praxis Assemblermark groß auf dem Großrechner. Und dieses DFH MSD definiert eben das Mapset, also mit Mode, dass es eine Ein- und Ausgabe-Maske ist. Und das Freak KB heißt, dass nach Absenten der Maske vom Terminal die Tastatur des Terminals freigegeben wird, sodass der Anwender direkt weitere Daten eingeben kann. Und das FRZ, das bezieht sich auf die Markierung, dass sich auf der Maske was gehindert hat. Da komme ich dann noch dazu. Und lang Kobol, ja, dass die Datenstrukturen eben dann für Kobol erzeugt werden sollen. Als nächstes wird dann eine Map, Map1 definiert mit der Größe 24 mal 80 Zeichen. Und der nächste Anweisung erzeugt dann ein reines Textfeld, was dann auch nicht beschreibt, deswegen bekommt es auch keinen Namen. In der Zeile 1 ab Position 20, das Attribut beides auf vorne dran, deswegen die Position 119, der Länge 21 Zeichen, belegt mit dem Text Beispiel und der Attribute ASCIP und Bright. Auf die Attribute gehe ich dann gleich nochmal ein. Dann mit dem Namen FU1, ein Feld der Länge 3, der Attribute unprotected, FZ und Initial Cursor und initiale Belegung 3 Striche. Und dann das Stopbyte, auch wieder ein Feld der Länge 1 ohne Namen. Das dazu dient, dass man nicht über das Eingabefeld hinausschreiben kann. Und dann noch mit dem Namen das Feld Bemerk, Zeile 24, mit der Länge 74 Zeichen, ein Autoscape und danach wird das Mapset abgeschlossen. Die Frage ist, was ist der Unterschied bei den Attributen mit oder ohne Klammern? Ich bin mir nicht ganz sicher, ich meine aber, dass wenn es nur ein Attribut ist, dann kann man so ohne Klammern schreiben. Ja, zu dem Attribut, also wie schon gesagt, das Attribut beides im Feld vorangestellt und belegt dementsprechend auch einen Platz auf der Maske. Das ist einmal die Möglichkeit Autoscape und das heißt, das Feld kann mit Tabulator, womit man die einzelnen Felder durchgehen kann, kann es nicht angesprungen werden. Wenn man aber mit einem Pfeiltasten da positioniert, kann man durchaus was reinschreiben. ProD wäre protected, also das Feld ist nicht beschreibbar und wird dementsprechend auch nicht angesprungen. Num, damit wird das Feld als numeric, also reines Zahlenfeld definiert. Man muss aber selber die Eingabe prüfen, das wird nämlich nicht herkontrolliert, was da dann eingegeben wird. Also kann man sich auch sparen und unprot ist unprotected, also es ist beschreibbar und wird vom Cursor dann auch angesprungen. Für die Helligkeit gibt es Norm, für Normal, Bright, also highlighted, doppelte Helligkeit und da wird halt einfach nicht dargestellt. Dann gibt es noch IC, Initial Cursor, also dass der Cursor an dieser Stelle der Maske startet, dieses Feld ist. Wenn es mehrfach gesetzt ist, ist das auch kein Problem, dann wird die letzte Positionierung einfach genommen und es gibt noch das Attribut F, damit wird ein Feld als geändert markiert. Modified Data Tag oder MDT abgekürzt, wird auf ein gesetzt. Das wird dann nachher noch relevant, was das Modified Data Tag, wie man das nutzt. Wie ich sagte aus dieser Maskenbeschreibung, wird einmal eine Maske für die Verarbeitung vom ZIX generiert und andererseits wird eine Copy generiert, also die Datenstruktur, in diesem Fall für Cobrol. Aus der Map1 wird dann einmal die Struktur Map1i, wo sich dann zu den ganzen Feldern mit Namen, also FU1 und Merk, in diesem Fall mehrere Variablen finden, einmal FU1L als Zahlenfeld für die Länge und FU1F, beziehungsweise dann auch umbenannt als FU1A, für die Attribute und FU1I, dann für den eigentlichen Inhalt des Feldes bei der Eingabe und für das Feld-Bemerk, das ganze Analog. Und der wird dann auch nochmal umgeführt, also die gleichen Speicherstellen umbenannt als Map1O und da gibt es dann jeweils für den Inhalt den Namen des Feldes mit einem Angehängten O, also einmal der Länge alphanumerisch 3 Zeichen und einmal alphanumerisch 74 Zeichen. Um diese Map dann im Programm ansprechen zu können oder um die Maske nutzen zu können, holt man sich diese Copy rein, das wäre hier in der Werkung of Storage, kannst du oben den Copy CICAMS1 für die Maske und dann hat man noch weitere Copy CICAMS1, die man sich reinholen sollte oder reinholen muss, also das wäre einmal die DFH-AID für bestimmte Definitionen, also auf die Copy CICAMS1 gehe ich dann gleich nochmal genauer ein. Dann die Copy DFH-BMSCA für die Bildschirmattribute und in dem Bereich, der dann beim Programmaufrufe mitgegeben wird, holt man sich den DFH-EIB-LK, also den EXIC Interface Block rein, auf den gehe ich auch noch näher ein und die DFH-COM-Area, das ist dann eine Übergabestruktur, die man sozusagen frei definieren kann oder im üblichen Ablauf, wo dann verschiedene Masken sozusagen hintereinander geschaltet sind, zum Beispiel das zu einem Vertrag, dann auch noch irgendwelche Vertragssiteils auf einer weiteren Maske sind, da ist dann ein erheblicher Teil, das ist ein common area, gleich definiert und wird dann von einem Programm zum nächsten weiter gereicht. Zusätzlich gibt es als Speichermöglichkeit noch die TSQ, die habe ich da nicht drauf, die wird dann auch nicht als eine normale Datenstruktur angesprochen, sondern das ist dann im ZIX selbst hinterlegt und das ist das, was ich vorhin meinte, mit einem Speicherbereich für alle Programme, das heißt man muss sich bei der Namensgebung dann Gedanken machen, also wenn man den Namen im Programm fest vergeben würde, dann würden alle gleichzeitig laufenden Programme auf die gleiche Datenstruktur zugreifen. Deswegen sitzt man in üblicher Weise aus der ID des Terminals, mit dem das Programm interagiert und aus der ZIX-ID des Programms zusammen, damit es eindeutig ist und wenn man die Daten an ein anderes Programm weitergeben, möchte beim Aufruf, muss man diesen Namen halt auch in die common area schreiben. Der EXIC Interface Block, der übergeben wird, da stehen verschiedenste Verwaltungsdaten, das ist eine ZIX drin, die nach jedem ZIX-Befehl, also Start oder Enderungsprogramms, aktualisiert werden, so was wie der Zeit- und Datum des Startzeitpunkts der Task, der Name des Terminals, mit dem das Programm interagiert, dann möchte ich für ein Programm ablauf die letzte benutzte Taste, der zuletzt ausgeführte ZIX-Befehl und noch einiges anderes, die letzte benutzte Taste, auch für die gibt es eine Copy, denn auf dem Terminal bzw. auch in der Terminal-Immulation sind mehrere Tasten definiert, die sozusagen Sonderaktion haben, dass sie dann den aktuellen Maskeninhalt vom Terminal wieder an Großrechten schicken für die Weiterverarbeitung. Das sind vor allem die Tasten PF1 bis PF24, im Jahr auf den Tastaturen für Terminals waren die dann tatsächlich alle als einzelne Taste vorhanden. Bei der Emulation werden die auf die F1 bis F12 gelegt, bzw. dann mit Shift noch für die höheren Nahtzahlen, und dann zum Beispiel noch die Datenfreigabetaste als DFH-Enter. Das ist üblicherweise ein anderes Haster als Return. Und da der Programmablauf sehr von der Taste abhängt, ist etwas sehr übliches, dass das Feld IPEID mit den Definitionen der einzelnen Tasten verglichen wird, welche tatsächlich gedrückt wurde und abhängig davon die Aktion durchgeführt wird. Der Aufbau des Programms ist dann auch etwas gewöhnungsbedürftig, da man gewissermaßen den Programmablauf jedes Mal unterbricht, wenn man was auf dem Bildschirm heraus schreibt, und zwar durchaus längerfristig. Also die Grundfunktionen sind Unmapp, also sende die Maske, Receive-Map für das Einlesende der Maske, und Return um die Kontrolle an das ZIX oder an ein aufrufendes Programm wieder zurückzugeben. Es wäre möglich, dass das Programm die Maske sendet und wartet, bis es eine Antwort erhält. Das würde aber unnötig Speicher kosten, weil das Programm dann die ganze Zeit im Hauptspeicher läge und warten würde, sodass das übliche Design dann so aussieht. Das Programm schaut, ob das erste Mal aufgerufen wird von diesem Terminal. Dann gibt es die Maske aus und gibt die Kontrolle an das ZIX zurück, mit der Folgetransaktion, dann üblicherweise sich selbst. Wenn von diesem Terminal eine Antwort kommt, dann rufe dieses Programm auf, beziehungsweise mich dann wieder auf. Wenn es ein Folgeaufruf war, dann wird die Maske eingelesen, geschaut, was sie eingegeben wurde und die Eingabe verarbeitet. Das Ergebnis ist dann wieder die Maske abgeschickt und die Kontrolle auch wieder ans ZIX zurückgegeben. Das führt dann dazu, dass die Maske am Anfang des Programms hervorbereitet werden muss. Der Ausgabebereich wird initialisiert, um irgendwelche Reste, die im Speicher stehen, wegzubekommen. Man kann der Ausgabefelder füllen, muss man nicht, wenn die Vorbelegung passt. Man kann die Attributfelder der einzelnen Datenfelder belegen bzw. abändern, um zum Beispiel irgendwelche Datenfelder auf dunkel zu schalten oder eingebbar oder nicht eingebbar zu machen. Man kann den Startposition des Cursors definieren, indem man das entsprechende Längenfelder auf minus 1 setzt und dann kann man die Maske ans Terminal senden. Das wäre dann diese WXXX-Befühle unten. Send-Map, dann wieder Maske. Und dann hat man da auch noch die Möglichkeit anzugeben. Map-Only oder Data-Only. Map-Only hieß, dass nur die Standardbelegung der Maske, die in der Masken-Definition steht, ans Terminal geschickt wird. Data-Only, dann sind es nur die Daten, die das Programm in irgendwelchen Felder geschrieben hat. Oder wenn man nichts angibt, dann werden diese beiden Quellen gemischt. Also die Vorbelegung genutzt, außer es wird irgendwas anderes angegeben. Wenn es nötig ist, kann man auch das Map-Set, das die entsprechende Map enthält, angeben. Mit der Angabe Cursor wird dann tatsächlich auch der Cursor auf dem Feld positioniert, nicht ganz oben in der Ecke. Errace zwingt das Terminal dazu, alles, was auf dem Terminal im Speicher steht, erstmal zu löschen. Ja, dann Receive-Map zum Abholen der Daten, wenn das Terminal dann welche geschickt hat, eine Sachbearbeiteränderung vorgenommen hat und irgendeine besonders ausgezeichneten Tasten zum Abschicken der Daten betätigt hat. Also Receive-Map, Name der Maske. Auch hier kann man das Map-Set angeben, muss man aber nicht, wenn der Name eindeutig ist eine gute Intodatenstruktur, also in welche Variable soll das Ganze geschrieben werden. Üblicherweise wird nur der Inhalt der Felder, der einen Modified-Data-Take-off einsteht, übertragen. Also Daten, die sozusagen auf beiden Seiten bekannt sind, muss man ja nicht nochmal übertragen. Und im Programm kann man das Ganze dann daran erkennen, dass das Längenfeld für die entsprechenden Variablen größer als 0 ist. Wenn es gleich 0 ist, wurden dafür keine Daten, also in dem Fall keine Daten übertragen. Und man muss schauen, ob man sich irgendwo zwischengespeichert hat oder ob man auch sehr auskommen kann. Für einen Programmwechsel gibt es auch wieder mehrere Möglichkeiten. Also mit XCTL übergibt man die Kontrolle an ein anderes Programm. Und zwar wird dann tatsächlich eine Kopie der Common Area übergeben. Mit Link wird einfach nur ein Verweis auf die Common Area übergeben. Das heißt, wenn das aufgerufene Programm etwas ändert und dann die Kontrolle zurückgibt, kann das aufgerufene Programm auf die geänderten Werte zugreifen. Das wäre dann eine Struktur. Links für Link und XCTL sieht die gleiche aus, also Programm, welches Programm soll aufgerufen werden. Common Area, an welcher Stelle steht die Common Area und lenkt, wie lange es die Common Area übertragen werden soll. Return gibt die Kontrolle dann zurück zum aufrufenden Programm bzw. zunächst zu euren Ebenen. Und zwar kann man sich das sozusagen so vorstellen. Ganz oben steht das 6, ruft ein Programm auf. Wenn dieses Programm dann ein anderes mit Link aufruft und dieses Programm dann einen Return schickt, geht die Kontrolle wieder hoch. Also Link geht sozusagen eine Ebene tiefer. Und XCTL bleibt auf der gleichen Ebene. Und Return geht dann immer auf das aufrufende Programm der nächsten Ebenen zurück. Das übliche ist, dass unter, also Return, also Übergabe der Transaktions-ID das Programm soll aufgerufen werden und auch wieder mit der Angabe der Common Area und der Länge der Common Area. Also hier auf der Veranstaltung um Spiele geht, die vielleicht relevant ist die Frage, but does it run do? Also dazu habe ich nichts gefunden, da die Frame Rate nicht wirklich garantiert werden kann. Das sehe ich dahin ein gewisses Problem. Da das 6 ja die Programme gewissermaßen nacheinander abarbeitet und aus meiner Erfahrung die Wartezeiten dann auch mal im Sekundenbereich sein können, wenn der recht netwas stärker ausgelastet ist. Ich vermute, wenn man die Anzahl der möglichen Monsterposition einschränkt und für jedes mögliche Bild ein Map anlegt, dann sollte es doch denkbar sein. Zumindest mit ASCII-Grafik. Gut, man hat ja ASCII-Grafik, aber das Programm selbst kann ja nicht wirklich kontrollieren, wann das nächste Mal eine Maske dargestellt wird. Das kontrolliert ja das 6, das System. Außer vielleicht, man schreibt, dass so ein unfreundliches Programm hat, das einfach wartet, bis es die nächste Maske darstellt. Weiteres Problem, man hat nur eine Textausgabe und mit 8 Farben ist die Farbdarstellung sehr eingeschränkt. Aber da ich gesehen habe, es gibt eine Java-Implementierung von Doom und es hat auch jemand schon eine grafige Ausgabe für Text-Displays geschrieben. Wenn man das Ganze zusammenstöpselt und dann ans 6 anpasst, könnte es vielleicht gehen. Also, wer es probieren will, viel vergnügen. Ja, auch zu anderen Spielen habe ich unter 6 nicht allzu viel gefunden. In einem Forum hat jemand geschrieben, er habe ein 3D Tic Tac Toe und ein Simulator für 6 geschrieben. Ja, bei der Suche nach Spielen unter 6 bin ich aber auch noch auf das Thema gestoßen. Es gibt die gebräuchliche Abkürzung ICS für ein Internet-Chess-Server und da gibt es auch mehrere, die mit C beginnen, so dass man mit 6 und einem Game oder Chess eine Menge Treffer bekommt, die mit diesem 6 überhaupt nichts zu tun haben. Da die Struktur für rundenbasierte Spiele aber gut geeignet wäre, bin ich mir ziemlich sicher, dass es in versteckteren Ecken von 6 Installationen durchaus Spiele geben wird, vor allem bei Installationen irgendwo im akademischen Umfeld oder so. Ich werde mich das überhaupt nicht wundern. Ja, und bei der Gelegenheit dann auch gesehen habe, also die frühe Spieleentwicklung erfolgt eben auf einmal Großrechte, also bevor Arcade Maschinen und Heimcomputer überhaupt verfügbar waren, haben die Leute halt vor allem im akademischen Umfeld für die Großrechte, mit denen sie halt täglich gearbeitet haben, durchhörte auch einfach ihre Spiele geschrieben. Ja, gibt es noch mal Fragen, also noch eine kleine Anmerkung. Das war jetzt natürlich bisher in der Oberfläche gekratzt. Also das hier ist das deutsche Standardwerk zum Thema 6, also 6 Theorie und Praxis von Norbert Denne. Das springe ich in 50 Minuten natürlich nicht unter und ehrlich gesagt kenne ich auch nur einen kleinen Teil davon. Also das, was ich dann halt für Anwendungsprogramme wirklich gebraucht habe. Ja, gibt es noch Fragen? Ja. Wie viele Systeme gibt es noch oder beziehungsweise wofür braucht man die noch in den Massen? Auch von der Geschwindigkeit her sage ich mal. Gut, die Rechner selbst sind nicht wirklich langsam und man wird sie vor allem im Banken und Versicherungsumfeld noch sehr häufig finden, weil da halt über Jahrzehnte die Fachlogik in Programme geflossen ist und das wirft man nicht einfach weg bei Systemen, die halt funktionieren und man versucht höchstens die Oberfläche für die Anwender etwas schöner zu gestalten als mehr die Optik, die ich auch bei den Folien hatte. Aber ja, Versicherungen aus Umfeld, Bankenumfeld ist es noch recht weit verbreitet und wie ich gesehen habe oder gibt es Gerüchte, das auch bei Multiplayer Online spielen. Die Datenverarbeitung eventuell auf dem Großrecht im Hintergrund passierte oder noch passiert, weil da halt für einen extrem hohen Datendurchsatz konstruiert ist. Irgendwie müssen die Daten von den Terminals oder von den Terminal Emulationen ja an den Rechner übertragen werden und auch wieder zurückkommen. Wissen das, ist das sowas X-Mode im Artigis irgendwie, gibt es da irgendwie eine sinnvolle Sicherung bei der Übertragung, könnte man die theoretisch einfach während der Übertragung austauschen Das Protokoll ist eine TN3270, was dort gesprochen wird oder zumindest früher gesprochen wurde. Also eine Pellnet-Variante gewissermaßen, da aber früher halt der Großrechner stand im Haus, die Terminals standen im Haus und ja irgendwie Anschlüsse nach draußen, da gab es nicht wirklich, es wäre möglich gewesen da die Daten zu manipulieren, aber war halt jetzt nicht das offensichtliche Angriffsszenario oder das Relevante. Heutzutage läuft es glaube ich auch über neuere Protokolle beziehungsweise dann auch in irgendwelchen Tunnel oder so. Ich hoffe, das hat die Frage jetzt halbwegs beantwortet. Hat noch jemand eine Frage sonst? Würde ich sagen, sind wir fertig. Vielen Dank.