Grafische Oberflächen statt 5250 Emulation

[watchdogg]

Hallo,


wir haben eine iSeries am Laufen die unser PPS und unsere Finanzbuchhaltung beherbergt.
Dass das Teil äußerst stabil und ausfallsicher läuft steht außer Frage, aber in Sachen Benutzerfreundlichkeit hinkt es mit Bordmitteln eindeutig hinter Web- oder Windows- Oberflächen hinterher.
Unsere User melden sich per 5250 Emulation aus einer Windows Terminal Session an der iSeries an und arbeiten dann dort dann mit schwarz/grüner Oberfläche.

Im Normalfall kennen neue Mitarbeiter diese UI nicht und müssen erst lernen damit umzugehen, weil privat und schulisch/ausbildungsmäßig normalerweise keiner damit in Berührung kommt. Fast jeder kann aber mit Windows-Desktop sowie Web-Oberflächen werkeln.

Ich programmiere für unsere User Anwendungen für das .NET Framework unter Windows oder auch Web und merke immer wie begeistert die plötzlich sind, weil sie eine völlig andere Sicht auf die Datenbank der iSeries haben und sich nicht mehr durch seltsam, mittelalterlich erscheinende Displays durchhangeln müssen. Irgendwie arbeiten die dann auch motivierter - so würde ich jedenfalls die Reaktionen deuten. Außerdem sind die
Druckausgaben ja unter Windows auch viel besser konfigurierbar. Für fast alle Programmiersprachen gibt es freie Bibliotheken für PDFs oder Barcodeerzeugung.

Mich würde mal interessieren, wie viele Unternehmen hier im Forum noch mit der 5250 Emu. als Benutzeroberfläche für User arbeiten und warum. Jetzt mal Operator und Sicherheitsbeauftragter rausgenommen.
Ich meine z.B. Lieschen Müller aus dem Vertrieb oder aus dem Einkauf.
Falls nicht, mit was programmiert/gestaltet ihr eure Benutzeroberflächen?

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

Was ist denn das WebSphere, ist das nicht auch eine Entwicklungsumgebung von IBM für Web-Oberflächen.
Mit welcher Sprache programmiert man in WebSphere?

Fragen über Fragen...aber würde mich echt interessieren.


MfG watchdogg

[Fuerchau]

Bei vielen Firmen wird deshalb noch 5250 eingesetzt weil die Datenerfassung und somit Transaktionskosten immer noch niedriger sind als die schönen Mausclick-Oberflächen.
Sicherlich kann man mit neuen Methoden schönerer Oberflächen bauen allerdings wird da dann gerne die Tastaturbedienbarkeit vergessen.
Es gibt (leider) genügend Beispiele wie nach der Umstellung auf grafische Oberflächen die Transaktionsrate (Belegerfassung) drastisch sinkt.
Selbst bei 5250-Bedienung kann man die Leute beobachten wie sie bei Tippfehlern versuchen die Stelle mit der Maus zu treffen an Stelle simpel die Pfeiltasten, auch Cursor-Tasten genannt, zu verwenden.

Grafische Oberflächen machen nur Sinn, wenn sie genauso schnell bedienbar sind wie die 5250-Oberfläche.
Moderne Entwicklungswerkzeuge können dies berücksichtigen. Wer kennt denn noch die "ALT"-Taste für das Erreichen der dann hervorgehobenen Tastenkürzel?
Manche fragen sich ja warum denn einzelne Buchstaben der Maske unterstrichen sind.

WebSphere ist eher ein alter Hut und ist durch modernere Lösungen ersetzt worden. Die IBM-Entwicklungsumgebung heißt nun RDi (Rational Developer for i) und ist Eclipsebasiert.

Ob nun auf der AS/400 1000de Userjobs oder ODBC-Jobs laufen ist letztlich egal.
Wichtig ist eher die SQL-Zugriffe perfomant zu gestalten denn die User warten selten gerne länger.
Und bei modernen Frameworks (wie in einem anderen Thread beschrieben) kappen die nicht selten die Verbindung wenn sich am Client länger nichts tut.

Und auch wenn das 5250-Layout altbacken erscheint, gibt es durchaus moderne Anwendungen auf dieser Basis.

[RobertMack]

Und auch wenn das 5250-Layout altbacken erscheint, gibt es durchaus moderne Anwendungen auf dieser Basis.

Yepp, fehlt nur noch ein DSPSIZ(54 264 *DS9)

;-))

[Fuerchau]

Nö, aber 16*20 wird auch gerne genommen (Scanner).

[watchdogg]

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.

[Logic IT-Services]

Es gibt durchaus Alternativen. Erfahrene Power Legacy User schätzen die GreenScreens. Neue Anwender rümpfen schon eher die Nase. Mit einem guten Oberflächen-Design lassen sich Maus-User und Schnelltipper durchaus gemeinsam zufrieden stellen.

Und tatsächlich, es gibt welche, die gar keine grafischen Oberflächen wollen und noch mit 5250 Emulationen arbeiten wollen. Auch das muss man akzeptieren.

[RobertMack]

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

Ich kenne einige Kunden-Mitarbeiter/innen die blind und in atemberaubenden Tempo green Screens befüllen, manchmal zwei bis drei Funktionstasten und Formate im Voraus. Die würden sich niemals irgendein Win-Klick-Gefummel andrehen lassen.

Aber wenn's bei Euch unbedingt sein muss, Brigittas aktuellstes Baby klingt äußerst interressant: http://www.wopixx.com/de/produkt

[Fuerchau]

Bei dem wopixx frage ich mich wo denn da der Oberflächendesigner und Codegenerator ist.
Nur mit Try und Error Bildschirme zu entwickeln finde ich schon aufwändig.
Da gibt es sicherlich elegantere Methoden.

Und was die Geschwindigkeit einer 5250-Erfassung angeht so ist die wirklich unschlagbar.
Unter Windows ist die Tastatur gesperrt wenn man nicht im Eingabefeld ist oder führt sogar zu unerwünschten Effekten.

[B.Hauser]

Bei dem wopixx frage ich mich wo denn da der Oberflächendesigner und Codegenerator ist.
Nur mit Try und Error Bildschirme zu entwickeln finde ich schon aufwändig.
Da gibt es sicherlich elegantere Methoden.

Baldur,
ich gehe mal stark davon aus, dass Du WOPiXX weder heruntergeladen noch ausprobiert hast!
Desweiteren wird beim Herunterladen eine 380-Seiten starke Dokumentation mitgeliefert. Daneben werden zwei Quellen-Templates (je eines für List/Subfile- und eines für Detail-Programme) bereitgestellt und mit ausgeliefert.
Sich einfach nur hinstellen und behaupten irgendetwas (das auch noch kostenlos! ist) und das man noch nichteinmal gesehen hat, nichts taugen kann, gilt nicht.

Es gibt außerdem noch die Möglichkeit sich in WOPiXX schulen zu lassen (im Gegensatz zum Tool und der Runtime ist dieser Service jedoch nicht kostenlos).

WOPiXX ist in erste Linie für klassische IBM i (RPG) Programmierer gedacht, die mit den vorhandenen Skills (ohne HTML, JavaScript etc. KnowHow) anstatt schwarz/grün Web-Programme erstellen wollen.
Wer natürlich anderes Know-How - PHP, Dot-Net, Java etc. der kann natürlich dieses nutzen und Web-Anwendungen anderweitig erstellen.

WOPiXX besteht aus 3 Blöcken, Administration, Engine und einer Funktions-Bibliothek (Service-Programme mit WOPiXX-Prozeduren).

Der Programmierer definiert durch den Aufruf von RPG/WOPiXX-Prozeduren welche Felder aus welcher Datei/Tabelle/View mit welcher Aufbereitungsoption (dafür stellen wir jede Menge Schlüssel-Worte bereit) angezeigt werden sollen.

Nachdem alle gewünschten Spalten, Filter, Kontext-Menü-Punkte und Buttons für eine List-Anzeige definiert sind, wird eine RPG-Funktion aufgerufen die das Ende der Erfassung kennzeichnet und die WOPiXX-Engine aktiviert. Die WOPiXX-Engine übernimmt und generiert aus den angegebenen Informationen mit Hilfe des DHTMLX-Framwork die entsprechende Web-Anzeige.

Nach einer Aktion in der generierten Web-Site (z.B. Klick auf einen in RPG-Programm definierten Button) übernimmt die Engine erneut, ruft das z.B. bei der Definition des Buttons oder Kontext-Menü-Punktes angegebene (RPG) Programm auf, über das dann die nächste Web-Site afubereitet udn gesteuert wird.
List-Anzeigen können auf diese Art- und Weise (abhängig von der Anzahl der Filter, Spalten, Kontext-Menü-Punkte und Buttons) mit 20-50 RPG-Statements generiert werden.

Für Detail-Anzeigen werden die aktuellen Abläufe der green/screen Dialog-Programme beibehalten:

• Einlesen-Datensatz (wie bisher)
• Definieren Ein-/Ausgabe-Felder (anstatt Umladen in die Display-File-Felder)
• Aufruf der Funktion Wx_GetChgInput (statt EXCFMT)
• Eingabe-Prüfung (im Fehlerfall erneute Anzeige - wie bisher - Im Fehlerfall wird allerdings eine Funktion aufgerufen bei der angegeben wird, welches Feld fehlerhaft ist und wie dei Fehlermeldung lautet.)
• Fortschreiben des Datensatzes (wie bisher)

Dass beim Wx_GetChgInput() das Programm beim ersten Durchlauf beendet wird und die Steuerung von der Engine übernommen wird, braucht den Programmierer nicht zu interessieren. Insbesondere da die Engine nach einer Aktion (z.B. Klick auf Sicherungs-Button) wieder übernimmt und die erfassten Werte in die definierten Variablen im RPG-Programm zurückbringt, so dass der Programmierer direkt nach Wx_GetChgInput() mit der Ein-/Ausgabe-Prüfung weitermachen kann.

Damit kann ein großer Teil der des vorhandenen Codes in Green-Screen-Bildschirm-Programmen weiterverwendet werden.

Die WOPiXX-Anwendungen, zugewiesene Bibliothekslisten, Message-Files und fertigen WOPiXX-Programme werden über die WOPiXX-Andministration registriert und können danach direkt aus dem WOPiXX-Menü aufgerufen werden.

Eine Anmerkung allerdings noch am Rande:
Es ist nichts so schnell wie eine Green-/Screen-Anwendung, insbesondere wenn mit Mehrsprachigkeit, bei der die Texte aus Message-Files ermittelt werden müssen.
Display-Files sind das einzige Tool, das Message-Texte automatisch aus Message-Files ermittelt, und dafür optimiert wurde.
Beim guten alten Green-/Screen wurden außerdem fast schon immer nur die relevanten Daten ausgetauscht. In den Web-Anwendungen kamen solche Techniken (JSF oder AJAX-Technologien) erst viel später dazu.

Birgitta

[RobertMack]

...Mehrsprachigkeit, bei der die Texte aus Message-Files ermittelt werden müssen.
Birgitta

Vor diesem Hintergrund habe ich vor etwa 20 Jahren ein Tool entwickelt welches DSPF Konstanten als MSGF-Einträge extrahiert, die DSPF Source in MSGCON oder MSGID mit Referenz auf die zuvor extrahierten Konstanten umcodiert und gleich wieder compiliert. Wer dieses Tool vor oder mit WOPiXX nutzen möchte, einfach melden...

[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