Eure Meinung zum RDi

[camouflage]

Ich habe beide RDi's bei mir im Einsatz 9.6 und 9.8. VSCode erschien mir bis jetzt immer ein wenig zu stark nach Open Source und nicht so elegant zu starten/handeln wie RDi. Nun ist der neue TR 7/1 angekündigt und markante Erweiterungen im VSCode seitens IBM! angekündigt.

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?

[Fuerchau]

RDi ist ja das Tool der RPG, SQL, CLP und CMD-Bearbetung.
Sogar ein DDS-Designer für Greenscreens ist noch enthalten.
Es erlaubt zusätzlich Objektanzeigen (Listen, Sichten) und ich glaube auch, SQL-Abfragen direkt.
Zusätzlich ist auch noch eine 5250 vorhanden (nicht die von ACS).

Sicherlich lässt der Syntax-Prüfer etwas zu wünschen übrig. Aber bei CMD's im CLP gibts auch einen F4-Prompt.

Ich kenne nun VS-Code nicht genug, um zu wissen ob all das in VS-Code auch vorhanden ist.

[dschroeder]

Wir sind mit RDi zufrieden und planen zurzeit keinen Umstieg. Wir beobachten allerdings VSCode und werden in ein paar Wochen einen Kurs dazu machen. Wir machen das, um nichts Wichtiges zu verpassen. Falls es irgendwann ein Killerfeature im VSCode gibt, wollen wird genügend Infos haben, um eine Entscheidung wegen eines Umzuges treffen zu können.

Falls z.B. eine sehr gute KI Unterstützung im VSCode enthalten wäre, könnte ich mir vorstellen, das mal auszuprobieren. Wir haben uns hier allerdings schon ein eigenes Ökosystem geschaffen, das im Moment perfekt zum RDi passt. Mal sehen, ob wir das dann umstellen könnten. (Wir haben z.B. ein eigenes einfaches Plugin im RDi realisiert. Es ist uns zur Zeit nicht klar, ob wir das auch im VSCode realisieren könnten).

Um ehrlich zu sein: (Bitte haltet mich/uns nicht für großkotzig): Aber der Preis spielt bei uns keine Rolle für den Umstieg. Das entscheidende Kriterium ist für uns die Effizienz der Entwickler. Notfalls würden wir vielleicht auch mehrgleisig arbeiten: Wenn ich irgendetwas mache, was im VSCode besser geht als im RDi, würde ich VSCode starten. Andere Sachen würde ich vielleicht weiter im RDI machen. Das ist natürlich kein Ziel-Szenario. Aber ich würde es nicht ausschließen.

[dschroeder]

Aus den Äußerungen von IBM entnehme ich, dass IBM mittelfristig eher zu VSCode neigt als zu RDi. Deshalb nehmen wir VSCode erstmal sehr ernst.

[camouflage]

Ich frag ja nur, da im Announcement (am Ende) diesem Aspekt doch einiges angekündigt wurde. Nicht zu vergessen, dass Liam Allan, der Schöpfer von Code for i, mittlerweile ein IBM Mitarbeiter ist. Ich bin nur neugierig.
Guckst Du hier: https://www.ibm.com/support/pages/ib...1-enhancements

[Fuerchau]

Das ist ja das fatale, dass man immer mehrere Wege gehen muss.
Warum sich nicht auf ein, durchaus gutes, Produkt konzentrieren, statt mehrere Produkte parallel zu entwickeln?
RDi ist Eclipse-basiert, was aus der Java-Ecke kommt und genauso erweiterungsfähig und eigentlich auch OpenSource ist, wie VS-Code.
So wie man VS-Code-Erweiterungen bauen kann, kann man eben auch Eclipse-Erweiterungen entwickeln. Nur wird es dann irgendwann einen Wildwuchs geben, da die eine oder andere tolle Funktion nur entweder in RDi oder in VS-Code vorhanden ist und man nachher noch beides benötigt.
Und das sehe ich persönlich eher als ein Problem als als Vorteil.

[dschroeder]

Wenn wir schon beim Thema sind:
Wir haben ein paar Probleme mit RDi. Sind euch diese Probleme auch bekannt oder ist das nur bei uns nicht so gut?

1. Wir haben viele Copy-Strecken mit Prototypes, die wiederum jeweils eine sehr große weitere Copy-Strecke mit Datenstrukturen beinhalten.
   In der Regel schafft RDi es nicht, eine vollständige "LiveSyntaxanalyse" durchzuführen. Die Prüfung unten in der Leiste bleibt meist so bei 66% stehen. Das führt dann dazu, dass Strg+Space nicht immer funktioniert.
2. Wenn ein Programm groß wird und viele Procedures hat (2500 Zeilen mit vielleicht 150 Procedure oder so), schafft RDi es nicht mehr im LPEX Editor mit F3 auf einem Procedurenamen auf die Deklaration der Procedure zu springen.
3. Der Debugger versagt ziemlich oft. "...Verbindung zur Debug Engine verloren"
   IBM hat uns mal gesagt, das läge am workspace. Aber nach dem aufwändigen Aufsetzen eines neuen workspaces tritt das Problem bei manchen Programmen wieder auf.
4. Im Debug kann man keinen Inhalt von UCS2 Feldern anzeigen. Ich habe da gerade einen Case bei IBM laufen. IBM hatte vor 3 Jahren oder so mal verkündet, dass man Unicode im Debugger anzeigen könnte. Aber das klappt nur bei UTF-8. Und die verwenden wir kaum. Ist im RPG meist zu umständlich.

Kennt ihr so etwas auch?

[camouflage]

Hallo Dieter,
zum Teil ja, Punkt 1 ganz sicher und Punkt 2 auch. Debugger kann ich nix sagen, da ich den Debug immer in einer ordentlichen CA Sitzung aufrufe.

und...
... ob da Klaus Peter mit liest? Jedenfalls passt das gleich zum Thema:
https://events.midrange.de/Online-Wo.../?affl=Academy
Allerdings, der Workshop ist nicht umsonst.

[dschroeder]

und...
... ob da Klaus Peter mit liest? Jedenfalls passt das gleich zum Thema:
https://events.midrange.de/Online-Wo.../?affl=Academy
Allerdings, der Workshop ist nicht umsonst.

Den Workshop haben wir gebucht. Ich freue mich schon darauf.

[BenderD]

Wenn wir schon beim Thema sind:
Wir haben ein paar Probleme mit RDi. Sind euch diese Probleme auch bekannt oder ist das nur bei uns nicht so gut?

1. Wenn ein Programm groß wird und viele Procedures hat (2500 Zeilen mit vielleicht 150 Procedure oder so), schafft RDi es nicht mehr im LPEX Editor mit F3 auf einem Procedurenamen auf die Deklaration der Procedure zu springen.

Kennt ihr so etwas auch?

... wenn ich Editor wäre, würde ich bereits vorher die Sitzung beenden und die Quelle löschen.
Könnte es sein, dass euer Design da nur das zweitbeste ist?

D*B

[dschroeder]

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.

[BenderD]

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