Grafische Oberflächen statt 5250 Emulation

[dschroeder]

Sorry, aber mit euren Fachausdrücken kann ich nichts anfangen.
Und Pikachu, an der Farbe liegts sicher nicht :-)...

Nee mal ehrlich, bietet ihr euren Usern diese 5250 Emu. echt noch an?
Also bitte jetzt nicht böse verstehen!

Ich als "Windows-Fan" kann mir nicht vorstellen, dass die damit schneller arbeiten.

Dann will ich als Vertreter einer Anwenderfirma auch noch meinen Beitrag leisten: Wir haben vor ein paar Jahren den Umstieg von reinem Greenscreen auf eine grafische Oberfläche auf der iSeries gewagt. Wir setzen eine browserbasierte Oberfläche ein. Als Entwicklungsumgebung nutzen wir ProfoundUI. Das heißt, mit einem Screendesigner werden die grafischen Masken entworfen, die von RPGLE Programmen verarbeitet werden. Die meisten User finden die grafischen Programme richtig gut. Es gibt aber in der Tat User, die einigen alten Masken hinterherweinen. Das werden allerdings immer weniger User, weil man sich eben doch an die neuen Masken mehr und mehr gewöhnt.

Wir bekamen zunächst auch Warnungen wie "Massendatenerfassung geht nur mit Green Screen schnell" oder "komplette Tastaturbedienung ist ein Muss". Anfangs haben wir versucht, dem Rechnung zu tragen und eine komplette Tastaturbedienung zu realisieren. Das ist aber im Browser kaum möglich und wurde letztlich nicht genutzt. Jetzt bauen wir die Masken so, dass der Standard-Eingabefall schnell funktioniert (ggf. auch komplett tastaturgesteuert). Für alle Sonderfälle bei der Eingabe muss man dann eben zur Maus greifen.

Die meisten unserer Programme sind natürlich nicht umgebaut worden. Sie laufen jetzt aber "etwas schicker" im Browser.

Bei uns können wir bisher das Fazit ziehen: Den meisten Users ist es eigentlich egal, ob die Oberfläche vollgrafisch oder 5250-like ist. Hauptsache, die Anwendung lässt sich gut bedienen und man kann seine Daten einfach und schnell erfassen. Aber das geht oft durch eine grafische Oberfläche besser, da man einfach viel mehr Platz auf dem Bildschirm hat.

Für uns Programmierer ist die Entwicklung von Dialogprogrammen durch die grafische Oberfläche einfacher geworden, da man Dinge nutzen kann, die es im Green Screen nicht gibt. Z.B. wird die Beschränkung auf 10 stellige Feldnamen durch den Profound Designer aufgehoben. Außerdem kann man einige Dinge direkt im Bildschirm regeln und benötigt im RPG dann weniger Plausis. Und natürlich hat man im Vergleich zu 5250 quasi "endlos" Platz auf dem Bildschirm und muss sich kaum Gedanken machen, ob ein zusätzliches Feld noch auf die Maske passt.

Dieter

[dschroeder]

Noch ein Nachtrag: Es kommt vielleicht die Frage auf, weshalb wir denn nicht Java oder .net machen, wenn wir auf grafische Umgebungen gehen: Zum einen wird bei uns bereits ein nicht unerheblicher Teil der Anwendungen in Java programmiert. Dabei liegt die Datenbank weiterhin auf der iSeries, die Programme aber nicht mehr.
Zum anderen haben wir im RPGLE-Umfeld eben tausende Programme, die perfekt zu unseren Businessproblemen passen. Die nutzen wir über unsere Profound-Lösung komplett weiter.

Aber klar: Step by step gehen wir immer mehr in die Richtung native grafische Programmiersprache (bei uns ist das Java).

Dieter

[holgerscherer]

Wenn wir schon beim Thema sind - ich hätte da noch einen Windows-5250-Emulator mit GUI-Skriptfunktion im Angebot. Wird derzeit nur bei einigen Kunden und intern verwendet, ist aber ausbaufähig.

Wer die kostenlose Software testen will: http://ptf.rzkh.de/XTendGUI.zip

[Fuerchau]

Und noch ein Produkt...
Der obige Anwenderbericht spiegelt doch genau das Szenario wieder um das es im Endeffekt geht.
Für das Reengineering hat man meist weder Zeit geschweige noch Geld mit dem Zusatzrisiko ob das denn danach genauso funktioniert wie vorher.
Eine sukzessive Umstellung ist da eben häfig ebenso wenig möglich.
Also mit geringem Aufwand ein "Web-Facing" (dies soll keine Produktwerbung sein) durchführen um danach die Anwendung mit neueren Verfahren zu ergänzen.
Manchmal stellt man ggf. auch alte Programme dann auf neue Methoden um, häufiger aber eher nicht.

Die Datenbank ist immer auch ein großes Problem, da hier ohne Eingriffe auf die Programme kaum eine Normalisierung/Verbesserung stattfinden kann.
Aber wenn man sich Zeit lässt und auch hier wieder step by step die eine oder andere Tabelle mittels sog. Filehandler umstellen. Dieser bietet eine Zwischenschicht, greift also auf die neue(n) Tabelle(n) per SQL zu und stellt die alte Schnittstelle nach oben zur Verfügung.
Hier sollte man sich dann eben Gedanken machen und nciht gleich an eine View denken die dann nur mit Triggern änderbar wird. Problematisch sind dann nur noch die Satzsperren, aber auch da gibt es Regelwerke und das zu lösen.
Dann kann die Java/NET-Fraktion auch mit optimierten Verfahren zugreifen.

[dschroeder]

Spricht etwas dagegen, wenn man zuviel Anwendungen über eine iAccess ODBC Schnittstelle mit der iSeries kommunizieren lässt?

Um deine konkrete Frage vom Anfang konkret zu beantworten:

Gegen "zuviel" spricht natürlich immer etwas :-).

Aber im ernst: Wir nutzen zwar nicht (mehr) ODBC, sondern JDBC. Und da sind schon einige tausend Verbindungen gleichzeitig offen. Ein Performance-Analytiker hat bei uns vor 2 Jahren festgestellt, das im Tagesbetrieb ca. 2000 SQL Statements pro Sekunde ausgeführt werden. Natürlich sind das nicht alles komplexe SQLs. Aber immerhin eine ganze Menge. Das macht die Maschine anstandslos mit.

Dieter

[B.Hauser]

Somit habe ich ja wohl keinen Einfluss auf das Aussehen der Oberfläche

Das Aussehen der Oberfläche ist aktuell von DHTMLX bestimmt.

Die Reihenfolge in der Ein-Ausgabe-Felder oder Spalten in List-Anzeigen generiert werden bestimmt der Programmierer. Ob diese Felder z.B. nebeneinander oder in Tabellen angeordnet werden bestimmt der Programmierer lediglich ebenso wie weitere Aufbereitungs-Optionen (z.B. Muss-Feld, Combobox, Auswahllisten, Aufbereitung/DatePicker von numerischen Datum) durch entsprechende Schlüssel-Worte, die beim Prozedur-Aufruf übergeben werden können.

Wopixx scheint ja wohl eher die "Screens" on-the-fly zu generieren, was jeden externen Einfluss ausschließt.

Das ist korrekt aber auch gewollt!
Einheitliches Design für alle Bildschirme (List- und Detail-Programme - kennt man ähnlich z.B. auch von UIM).
Deshalb ist ein Screen Designer an dieser Stelle auch sinnlos.
Natürlich kann man auch zusätzlich das Default-Template das verwendet wird in einem gewissen Maß individuell erweitern.

Die typische und auch von modernen Anwendungen geforderte Trennung in "Frontend" und "Business Logic" sehe ich da eher nicht. Hier gilt die alte RPG-Regel: alles aus einer Hand.

Woher weißt Du, dass wir nicht im Untergrund genau das machen?
Im RPG-Programm wird lediglich definiert! Die Informationen werden gesammelt und zum Zeitpunkt x (Programm-Ende/Prozedur-Aufruf) aufbereitet und ausgegeben. Und zum Zeit-Punkt y (nach einer Aktion) in die RPG-Variablen zurückgegeben bzw. das nächste Programm aufgerufen.

Die alte RPG-Regel "alles aus einer Hand", simulieren wir deshalb, um den Umstieg zuerleichtern bzw. um einen großen Teil des ursprünglichen Programms beibehalten zu können.

Meine persönliche Meinung ist und bleibt, man sollte sich jedoch die Sachen anschauen, bevor man drüber diskutieren will.

Birgitta

[Fuerchau]

@Birgitta
Vielen Dank für deine vollinhaltliche Bestätigung meiner ganz persönlichen Meinung (da ich es mir nun mal gründlich angeschaut habe).