Grafische Oberflächen statt 5250 Emulation

[Fuerchau]

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]

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.

[BenderD]

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

[Fuerchau]

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.

[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