View Full Version : Grafische Oberflächen statt 5250 Emulation
Dem kann ich auch nur zustimmen.
Ich weiß auch nicht, warum man so intensiv an RPG festhält. Auch RPGLE ist bis auf ein paar funktionale Erweiterungen immer noch sequentiell orientiert und somit lockt man da niemanden in die Anwendungsentwicklung.
Betrachtet man sich das heutige Umfeld so geht die Richtung eigentlich sehr eindeutig Richtung Java.
Schließlich darf man nicht vergessen, dass Android ein Java-OS ist und ja inzwischen 80% des mobilen Marktes beherrscht (demnächst ja auch noch das Automobil).
.NET ist dann noch der 2. Zweig dem man entsprechende Aufmerksamkeit schenken sollte.
Somit kann man ja eigentlich vieles, was RPG-spezifisch entwickelt wurde, als festen Stand einfrieren um das Heer der "älteren" RPGler nicht zu überfordern und einen gewissen Bestandsschutz (Arterhaltung) zu betreiben.
Wenn ich so den jungen Programmierern die ich so treffe sage: das kann die AS/400 auch, trifft mich da schon Erstaunen. Wenn man das dann auch noch beweisen kann kommt das aah und oooh.
Erst letztlich konnten wir bzgl. des Antwortverhaltens zwischen AS/400 und SQL-Server massive Vorteile der AS/400 eruieren.
Warum also nicht für die Zukunft das Java-Potenzial der AS/400 nutzen.
Durch die (wie ich hörte) Freigabe der .NET-Compilerquellen schafft es ggf. die IBM auch noch, die .NET-Runtime (ebenso wie Java) für die AS/400 zu portieren. Das dürfte doch eigentlich überhaupt kein Problem darstellen und eher ein Ziel sein.
ML-Software
02-05-16, 09:50
Hallo,
da die Diskussion von einem User eröffnet wurde der bereits .NET Softwareentwickelt möchte ich dann auch meinen Hut in den Ring werfen.
Die iNEXT Suite von ML eröffnet die Möglichkeit sowohl traditionelles Handlingmit reiner Tastaturbedienung als auch modernes Windowshandling miteinander zukombinieren. Sogar neuentwickelte Programme auf Basis direkterDatenbankzugriffe über das iNEXT ORM können Daten mit klassisches RPG Programmenaustauschen.
Zum Thema Transaktionsgeschwindigkeit merke ich folgendes an:
Die hohe Geschwindigkeit eines Maskenaufbaus ist in der täglichen Arbeitnatürlich sehr angenehm, allerdings ist es natürlich auch nötig zur Beschaffungaller Informationen zwischen vielen Screens zu wechseln. Mit unsererModernisierungstechnologie erschaffen wir komplett neue Bildschirme auf denenALLE Informationen auf einem Blick zu finden OHNE zwischen den Screens ständigzu wechseln. Somit wird ein schnellerer Aufbau eines Screens mit relativ wenigInformationen locker kompensiert. Zumal die neuen Screens ja auch Ihre Inhaltedynamisch verändern ohne sich komplett neu aufzubauen.
Betrachtet man sich das heutige Umfeld so geht die Richtung eigentlich sehr eindeutig Richtung Java.
[...]
NET ist dann noch der 2. Zweig dem man entsprechende Aufmerksamkeit schenken sollte.
[...]
... willkommen im Club.
Zwei Dinge würde ich auseinanderhalten wollen, insbesondere, wenn ich als Anwenderfirma eine umfangreiche Eigenentwicklung Individualsoftware habe:
- Neuentwicklung und Modernisierung des Kernbereichs der Anwendung einerseits (20%)
- die Masse der Programme, die sich mit Stammdaten etc. beschäftigen andererseits (80%)
für die ersten würde ich immer raten Richtung Mainstream zu gehen (Java oder .NET).
Für den zweiten Teil reicht meistens (für diesen Anwenderkreis) ein Aufhübscher. Hier würde ich Aoutomatisierbarkeit und gemeinsames Look and Feel zum ersten Teil als Anforderung sehen. Pflegen oder verbessern würde ich hier nichts wollen, wenn sich da Bedarf äußert ist neu schreiben in neuer Technologie besser.
D*B
PS: Das Festhalten an RPG und die große Bereitschaft von einer Nische in eine andere zu taumeln, lässt sich m. E. am Besten mit Starrsinn oder Trotz erklären (ich denke da an den Fuchs und die Trauben...).
In diesem Club spiele ich schon seit 2005 mit der Gründung der FTSolutions.
Es ist schon erstaunlich, mit welchen Vorstellungen manche versuchen mit aller Gewalt alte RPG-Programme nebst auch gleich der Datenbank möglichst automatisiert zu migrieren, wobei in den meisten Fällen eine Migration jenseits aller Kostenmodelle liegt.
dschroeder
02-05-16, 13:49
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
02-05-16, 13:58
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
02-05-16, 14:15
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
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
02-05-16, 16:17
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
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