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)

;-))

[Pikachu]

... und arbeiten dann dort dann mit schwarz/grüner Oberfläche.

Hier wäre ein Ansatzpunkt: Ändert doch mal die Farben ...

[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...

[Rainer Ross]

Hallo Watchdog,

meine Idee war es, die Geschwindigkeit des Greenscreens mit dem Charme von grafischen Anwendungen zu verbinden. Mein erstes großes Projekt war www.myhofi.com, das mit HTML5, CSS3 und Javascript gebaut ist. Die Maschine ist eine IBM i 720 mit V7R2.

Bei meiner weiteren Arbeit habe ich www.webix.com ausprobiert und war von der Schnelligkeit der Entwicklung und der guten Performance begeistert. Hier braucht man gute Javascript Kenntnisse, wie auch bei allen anderen Javascript-Frameworks. Der Vorteil ist, dass die Anwendungen auf allen Endgeräten laufen, die einen Browser haben, wie PC, Tablet und Smartphone und die Programme auf den Geräten nicht installiert werden müssen.

Beispiele: www.myhofi.com/devhtm/sidebar.htm Google Map ist eingebunden
www.myhofi.com/devhtm/charts.htm Anbindung von http://www.highcharts.com/demo

Die serverseite Programmierung kann mit allen Sprachen erfolgen, die auf IBM i laufen: RPG, C, COBOL, PHP, NodeJS, Ruby, Python und Java. Auch fremde Datenbanken, wie z.B. die Cloud-Datenbank www.cloudant.com lassen sich einfach einbinden, wie das Beispiel www.myhofi.com/devhtm/cloudant.htm zeigt.

.Net und Webentwicklungstools nutzen AJAX und JSON. Somit kann ich meine Frontendentwicklung von der Serverentwicklung abkoppeln.

Für das Design der Anwendung gibt es den Visual Designer http://designer.webix.com/quickstart - für das Design der Oberfläche den Skin Builder http://webix.com/skin-builder/

Die Entwicklung mit Webix ist ein Beispiel dafür, dass die IBM i ein hervorragender Webserver ist. Selbstverständlich kann man die Oberfläche auch mit Angular, Bootstrap, Telerik, Sencha oder was es noch so gibt entwickeln.

Was die Performance der IBM i in der Webumgebung betrifft: einfach mit www.pagespeed.de die Zeiten von myhofi.com mit anderen Websites vergleichen. Die Anwendung ist jetzt seit Juli 2014 online und hatte noch nie Probleme mit der Performance und der Skalierbarkeit.

Für die Programmentwicklung nutze ich den RDI mit den Webdeveloper-Tools.

Um die IBM i als Webserver zu betreiben, reicht der HTTP-Server. WebSphere ist für meine Arbeit nicht notwendig.

Herzliche Grüße

Rainer