View Full Version : Eure Meinung zum RDi
camouflage
09-10-25, 14:20
Kommt hinzu, dass der letzte RDi 9.8er update die ganze Installation zerschossen hat, so dass ich alles wieder neu aufsetzen musste. Danke dafür.
Andreas_Prouza
09-10-25, 14:22
Frage, plant ihr einen Umstieg, wenn noch nicht vorgenommen, auf VSCode oder was haltet ihr davon (Andreas ausgenommen)? Angesichts der Lic-Kosten ist RDi noch das Geld wert?
Ich hoffe du wolltest mich nicht ausschließen ;-)
Ich unterrichte gerade in Wien in einer IBM i Academy beide Themen: RDi & vscode.
Die Teilnehmer sind jedes mal super happy, dass sie nach 2 Tagen RDi wieder mit den VSCode arbeiten dürfen. (Die meisten kannten davor keines der beiden Tools).
Grund dafür war: Mit RDi gab es ständig jemanden der Probleme hatte (Verbindungsabstürtze, Exceptions wie Dateisystemfehler usw.).
Ein Neustart half meistens.
Die Teilnehmer sind mit der Zeit aber sehr genervt davon.
Wundert mich, dass ich dies nie auf der Liste der Probleme sehen kann.
Dachte schon ich wäre der einzige damit. Habe aber festgestellt, dass andere Kollegen einfach gelernt haben damit zu leben.
Für mich persönlich ist ein stabieler und vor allem schneller Editor am wichtigsten.
Weder RDi noch VSCode mit der Extension vom Liam erfüllen diese Kriterien für mich.
Deshalb habe ich die Sourcen im GIT und arbeite lokal am PC (bevorzugt mit vscode).
Für den Build Prozess hab ich das Tool OBI geschrieben (Kompile Befehle generieren & absetzen, Logs anzeigen, usw.).
Der Editor ist dafür egal, kann man auch mit RDi benützen.
Im vscode hab ich eine Extension geschrieben, die mir die kommunikation mit OBI "vereinfacht".
Ich hätte ich auch noch eine Erweiterung für den RDi machen können, oder PDM. Bzw. kann jeder der möchte.
Mein Ziel ist es eine Entwicklungsumgebung zu haben, die nicht auf eine Technologie (und schon gar nicht Editor) angewiesen ist.
dschroeder
09-10-25, 15:37
und...
... ob da Klaus Peter mit liest? Jedenfalls passt das gleich zum Thema:
https://events.midrange.de/Online-WorkshopVonRDizuVS-CodeIstdasmglich#/?affl=Academy
Allerdings, der Workshop ist nicht umsonst.
Den Workshop haben wir gebucht. Ich freue mich schon darauf.
dschroeder
09-10-25, 15:46
Könnte es sein, dass euer Design da nur das zweitbeste ist?
D*B
Das könnte natürlich sein.
Aber glücklicherweise sind diese Programme Ausnahmen. Unsere Programme haben im Schnitt weniger als 250 Zeilen.
Wir haben bei uns z.B. für die Entität Kunde ein Serviceprogramm, das alle möglichen Aktionen mit dem Kunden veranlasst. Z.B. kundeAktion(key : 'neuanlage') oder kundeAktion(key : 'showZusatzdaten').
Da mit einem Kunden schnell mal 100 oder mehr Aktionen möglich sind, haben wir im Serviceprogramm kundeAktion eben mindestens 100 Procedures. Eben für jede Aktion eine eigene Routine. Die eigentliche Arbeit wird natürlich nicht in dem Serviceprogramm gemacht. Es steuert nur die Aufrufe der wirklichen Verarbeitungsprogramme.
Langer Rede kurzer Sinn: So ein Programm ist lang, beinhaltet aber strukturell keine große Logik. Es ist nur eine lange "Aufzählung" der Möglichkeiten.
dschroeder
09-10-25, 15:49
Kommt hinzu, dass der letzte RDi 9.8er update die ganze Installation zerschossen hat, so dass ich alles wieder neu aufsetzen musste. Danke dafür.
Da ich eigentlich immer einer der ersten bin, die neue RDi Versionen einsetzen, finde ich auch oft Unzulänglichkeiten und melde die als Case bei IBM. Ein Developer von IBM hat mir gesagt, dass er bei jeder neuen Version (also bei jeder neuen Fix-Nummer) eigentlich einen neuen leeren workspace empfiehlt. Man hat wohl nicht so viel Vertrauen in die meistens angebotene Konvertierung der workspaces.
dschroeder
09-10-25, 16:04
Mit RDi gab es ständig jemanden der Probleme hatte (Verbindungsabstürtze, Exceptions wie Dateisystemfehler usw.).
Ein Neustart half meistens.
Die Teilnehmer sind mit der Zeit aber sehr genervt davon.
Wundert mich, dass ich dies nie auf der Liste der Probleme sehen kann.
Dachte schon ich wäre der einzige damit. Habe aber festgestellt, dass andere Kollegen einfach gelernt haben damit zu leben.
Ja, das habe ich auf meiner Liste vergessen. Es kommt schon mal vor, dass wir den RDi neu starten müssen. Mal 4 mal am Tag und mal nur alle 2 Wochen.
Nervig ist die Empfindlichkeit der Connection. Wenn eine kurze Netzwerkstörung auftritt, fangen sich die meisten Nicht-IBMi Anwendungen schnell wieder. Die IBMi Anwendungen, egal ob RDi oder ACS lassen sich nach einem kurzen Connection Verlust nicht mehr retten. Unsere Anwender nutzen für die Sitzungen (im Browser) Genie (von ProfoundUI). Die sind relativ fehlertolerant.
Das Blöde ist, dass ich mein Notebook in der Firma in der Regel mit einer Dockingstation mit festem Netzwerkkabel betreibe. Wenn ich das Notebook dann mal schnell für eine Besprechung in ein anderes Büro mitnehme und die Verbindung über die Docking-Station abreißt, sind alle IBM i Anwendungen einschließelich RDi gestört. Ich muss also erstmal alles beenden und dann im neuen Büro alles neu starten. Hinweis: Wir haben flächendeckendes WLAN. Aber das Umschalten kriegen die IBM i Tools nicht hin. Outlook, Teams usw. haben damit gar kein Problem. Vielleicht muss ich es, wie einige Kollegen machen: Nur noch per WLAN arbeiten. Ich bilde mir ein, dass das langsamer ist. Aber vielleicht macht das gar nichts aus.
Seit 9.8.1 habe ich fast keine Probleme mit der Syntaxanalyse, da diese nicht mehr die gesamte Source durchsucht, sondern nur noch innerhalb des umgebenden Blocks der aktuellen Zeile, also if-endif, dcl-proc-endproc, for-endfor, usw.
Abstürze bekomme ich nur, wenn das Netz mal wieder zusammenbricht. Ich arbeite vom Homeoffice via VPN mit der IBM. Da kann es dann schon mal zu Unterbrechungen kommen.
WLAN-Probleme kann man minimieren, wenn man das automatische Weiterleiten (Mesh) des WLAN korrekt konfiguriert hat. Da merkt man den Wechsel zwischen den Stationen gar nicht.
Wenn dann eine Exception hochpopt, dann kann man wirklich nichts mehr machen und muss RDi auch killen. Aber das ist höchst selten. Beim Neustart wird man dann aber gefragt, ob die zuletzt geänderten und noch nicht gesicherten Quellen wieder geöffnet werden sollen.
Auch die Anzahl Zeilen ist mittlerweile kaum noch ein Problem. Alte Quellen, die erst nach und nach auf Free umgestellt werden, haben historisch durchaus mehrere 1000 Zeilen, auch schon mal 10.000!
Auch damit hat RDi keine Probleme.
Es funktioniert ja sogar die Autovervollständigung im SQL für Hostvariablen. Das war vorher halt immer lästig. Da musste man aus "exec sql" einen "xexec sql" machen, konnte seine Hostvariablen setzen und das "x" wieder entfernen.
Der Upgrade auf die 9.8.1 funktionierte sogar ohne Probleme.
Super ist das Arbeiten mit der Gliederungsansicht und dem Filter derselben. Über die Referenzen kann man schnell alle Verwendungen prüfen, incl. der Datei-E/A's, und dahin navigieren, vor allem wann eine Variable geändert wird. Das war früher immer sehr mühsam, da dies erst der Compiler auswarf.
Über eine 2. Ansicht bekommt man dieselbe Qielle noch mal nebeneinander, so dass man in unterschiedlichen Stellen des Codes navigieren kann. Ins besonders im Daten- und Codeteil separat.
Wenn der Bildschirm breit genug ist, hat man immer noch eine gute Arbeitsfläche.
Aber es ist halt jedem selbst überlassen, wie man mit einem Tool umgehen kann.
Ach ja, auch den Debugger benutze ich noch lieber im Greescreen, da der Remote-Debugger via VPN einfach viel zu langsam ist.
camouflage
10-10-25, 07:28
Also Baldur,
Du bist mein Held, schon auf 9.8.1. Da bin ich doch gleich noch ein Pfahlbauer. :-D
OK, leicht vertan: 9.8.0.2 (20240514_1451)
Läuft aber problemlos und für meine Internetausfälle kann ja RDi nichts.
Das könnte natürlich sein.
Aber glücklicherweise sind diese Programme Ausnahmen. Unsere Programme haben im Schnitt weniger als 250 Zeilen.
Wir haben bei uns z.B. für die Entität Kunde ein Serviceprogramm, das alle möglichen Aktionen mit dem Kunden veranlasst. Z.B. kundeAktion(key : 'neuanlage') oder kundeAktion(key : 'showZusatzdaten').
Da mit einem Kunden schnell mal 100 oder mehr Aktionen möglich sind, haben wir im Serviceprogramm kundeAktion eben mindestens 100 Procedures. Eben für jede Aktion eine eigene Routine. Die eigentliche Arbeit wird natürlich nicht in dem Serviceprogramm gemacht. Es steuert nur die Aufrufe der wirklichen Verarbeitungsprogramme.
Langer Rede kurzer Sinn: So ein Programm ist lang, beinhaltet aber strukturell keine große Logik. Es ist nur eine lange "Aufzählung" der Möglichkeiten.
... 250 für den Durchschnitt ist nicht gerade wenig, aber handelbar. 2500 ist der Faktor 10, das ist schon heftig. Die Tatsache, dass dabei die Macken der Entwicklungsumgebung auffallen,sagt auch aus, dass es da durchaus Änderungen an diesen Boliden gibt und da stellt sich schon die Frage Wartbarkeit. Ich würde da schon mal einen Blick drauf werfen, ob man das nicht teilen kann, sprich: ob alle Procedures da rein gehören, bzw. innere Bindung (shared data) haben.
Kritisch sehe ich auch, die Übergabe von Steuerungsinformation, das verdeckt Aufrufhierarchien und macht sie instabiler. Aufrufnamen kann der Compiler prüfen, Inhalte von Parametern nicht.
D*B