Merlin und Co. Sourcen im IFS. Wie klappt das in der Praxis?

[Andreas_Prouza]

Schein mal in mein Build-Tool rein (https://github.com/andreas-prouza/ibm-i-build) dort habe ich ein paar Beispiel Sourcen wo ich das genauso mache.
(Z.B. in: prouzalib/qrpglesrc/logger.sqlrpgle)

* ich verwende sowohl /Include als auch /Copy
* Hostvariablen die mit like auf eine E-DS in der /Copy oder /include verweisen
* Ich verwende auch den *LVL2

Ich meine, dass es hier keinen Unterschied gibt ob IFS oder SRC-PF.
Die von dir beschriebenen Probleme kommen mir bekannt vor, aber noch aus der SRC-PF Welt.
Habe jedoch vergessen was dann die eigentliche Ursache war.
Manchmal ist es auch ein Folgefehler gewesen.

Vielleicht noch eine Notiz am Rande:
Da ja nicht alle Sourcen direkt aus dem IFS kompeliert werden können (DSPF, PF, LF, ...), müssen diese vorher in eine temp. SRC-PF kopiert werden.
Im Build-Tool hab ich einfach vorgelagert ein CPYFRMSTMF drinnen.
Wenn (aus mir aktuell unbekannten Gründen) auch RPG Sourcen besser nicht direkt über's IFS kompeliert werden sollen, dann kann man auch für diese den CPYFRMSTMF dazu fügen.
Die Sourcen sind zwar dann im IFS Kompeliert werden sie schlussendlich aus der SRC-PF.
Bis jetzt hats auch so bei mir geklappt. Aber ja, SQL Precompiler ist manchmal grundsätzlich etwas mühsam.

[Fuerchau]

So ähnlich geht ja der Compiler auch vor und expandiert die Quelle in die QTEMP.
Aber wie gesagt, wenn man die Breite einer SRCPF von 200 (Text 188) ausnutzt, klappt das mit *LVLx nicht mehr.
Es muss also eine unterschiedliche Leseroutine bei *LVL-Verwendung geben.
Beim IFS erklärt sich das von selber, aber schiebe mal im IFS einen SQL auf eine Position ab 150.
Beim Compile aus einer SRCPF wird in QTEMP die Breite der 1. Quell-SRCPF gewählt.
Aber beim IFS gibts je keine festgelegt Breite.

[AG1965_2]

Wenn man mit 32.754 Zeilenlänge durchkommt, hilft dieses PTF aus dem Jänner 2023 und das Setzen der Environmentvariable QIBM_RPG_PPSRCFILE_LENGTH.
https://www.ibm.com/support/pages/rp...-avoid-rnf0733

[dschroeder]

Guten Morgen,

ich möchte mich nochmal für alle Beiträge bedanken. Es war einiges Neues dabei. Obwohl ich mir immer noch unsicher bin, was ich davon benötige, bzw. was sich konkret bei uns verbessern würde.

Hier mal meine bisherigen Erkenntnisse:

Wenn ich unsere Sourcen von Teildatei auf IFS umstellen würde:

• Müsste ich auf die direkte Anzeige/Filterung der Sourcetexte verzichten und könnte sie nur mit anderen Tools anzeigen.
• Könnte ich Git als Versionskontrollsystem einsetzen. Ich habe das bisher aber nicht vermisst (unsere eigenes Versionskontrollsystem reicht uns, denke ich).
• Könnte ich VSCode einsetzen. Ist das echt besser als RDi? (Dass es kostenlos ist, ist für mich ziemlich unwichtig).
• müsste ich weiterhin mit bestimmten Sourcearten leben, die nicht im IFS abgelegt werden können (z.B. DSPF). Wird IBM das mal durchgängig lösen?

Habe ich irgendwelche Vorteile/Nachteile vergessen?

[Fuerchau]

IFS-Quellen zusätzlich im Backup mitnehmen. Bei Lib's hat man das meist mit *ALLUSR ja im Griff.
IFS-Berechtigungen laufen anderes als bei Lib's (Vererbung!) und *ALLOBJ im Userprofil wirkt nicht.

VSCode ist wahrscheinlich erheblich schneller in der Codeanalyse für Autovervollständigung (Intellisense).
Der RDI braucht da immer ewig, da häufig die ganze Quelle neu gescant wird, incl. aller Copy/Include und externer Dateien. Und bei SQL gibts da auch keine Unterstützung mit Hostvariablen.

[Andreas_Prouza]

• Müsste ich auf die direkte Anzeige/Filterung der Sourcetexte verzichten und könnte sie nur mit anderen Tools anzeigen.

Genau, was im RDi aktuell auch nicht viel anders ist. Um die Texte sehen zu können muss man auch ein separate Ansicht öffnen.

• Könnte ich Git als Versionskontrollsystem einsetzen. Ich habe das bisher aber nicht vermisst (unsere eigenes Versionskontrollsystem reicht uns, denke ich).

Git bietet so viel mehr als eine simple Versionskontrolle.
Dadurch dass Git überall unterstütz wird, können auch Unterschiede zu verschiedenen Versionen sehr schön dargestellt werden.

• Könnte ich VSCode einsetzen. Ist das echt besser als RDi? (Dass es kostenlos ist, ist für mich ziemlich unwichtig).

Der große Vorteil vom RDi ist der Screen-Designer. Hierfür gibt es (noch!) keine Unterstützung bis auf die Vorschau.
Und die Autovervollständigung. Hier geht vscode nach dem Ansatz ob es irgendetwas anbieten könnte was von irgendwo hier irgendwie passen könnte.
Finde ich persönlich sehr angenehm, da ich dadurch sehr schnell zum gewünschten Ergebnis komme.
Ich frage bei allen Kunden und Kollegen die eine IDE verwenden immer wie es ihnen damit geht.
Das Resümee:
Beim RDi gibt es so gut wie immer etwas zu kritisieren. Meist sind Entwickler wegen Verbindungsprobleme (egal ob im Office oder zu Hause) und schlechter Performance nicht wirklich begeistert.
Beim VSCode gibt es lediglich die oben genannten Punkte, jeder ist jedoch super Happy.

• müsste ich weiterhin mit bestimmten Sourcearten leben, die nicht im IFS abgelegt werden können (z.B. DSPF). Wird IBM das mal durchgängig lösen?

Wie gesagt, mich als Entwickler kümmert es nicht, ob die Source für's Kompelieren in eine SRC-PF kopiert werden oder nicht.
Bei mir sind alle Sourcen (auch DSPF, PRTF, PF, LF, ...) im IFS.
Man hätte auch schon mit IBM i 5.2 alle Sourcen im IFS haben können, das macht hier keinen Unterschied.

Wenn ihr happy mit dem seid wie es aktuell ist und ihr keine Probleme im Alltag habt, dann spricht nichts dagegen diesen Weg fortzusetzen.
Hier im Forum kann man nur die Oberfläche ankratzen was möglich wäre.
Auf die Themen Branches und Deploymentsicherheit sind wir hier gar nicht eingegangen obwohl das ein wesentlicher Aspekt ist.
Oder auch Integration in ein Ticket-System für Deployments uvm.
Möchte man hier näheren Einblick haben muss man sich mit dem Thema (z.B. Git) entweder selbst näher beschäftigen oder einen Tagesworkshop aufsetzen lassen.

[dschroeder]

Genau, was im RDi aktuell auch nicht viel anders ist. Um die Texte sehen zu können muss man auch ein separate Ansicht öffnen.

Genau das ist im RDi nicht der Fall! Die wichtigste Ansicht im RDi ist die Objekttabelle. Da sehe ich die Programmnamen, Sourcetexte, usw.
Mir ist völlig schleierhaft, warum nicht jeder RDi User mit dieser Sicht arbeitet und weshalb IBM das nicht zur Standardsicht bei Installation des RDi macht.

Hier ein Beispiel der Objekttabelle im RDi:



Der Name "Objekttabelle" ist etwas irreführend. Man kann damit Objekte darstellen, aber genauso gut auch Teildateien.

Git bietet so viel mehr als eine simple Versionskontrolle.
Dadurch dass Git überall unterstütz wird, können auch Unterschiede zu verschiedenen Versionen sehr schön dargestellt werden.

Das kann ich im RDi auch mit dem iSphere Plugin. Allerdings muss ich die alte Version erst (aus unserem Versionskontrollsystem) laden.

Der große Vorteil vom RDi ist der Screen-Designer. Hierfür gibt es (noch!) keine Unterstützung bis auf die Vorschau.

Den Vorteil nutzen wir im RDi nicht, da wir alle Masken (grafisch) mit ProfoundUI entwerfen.

Ich frage bei allen Kunden und Kollegen die eine IDE verwenden immer wie es ihnen damit geht.
Das Resümee:
Beim RDi gibt es so gut wie immer etwas zu kritisieren. Meist sind Entwickler wegen Verbindungsprobleme (egal ob im Office oder zu Hause) und schlechter Performance nicht wirklich begeistert.

Da gebe ich dir recht. Auch uns fällt immer wieder etwas auf, was im RDi nicht so gut läuft. Was gut läuft, beachtet man nach einiger Zeit gar nicht mehr, sondern nimmt es als selbstverständlich hin.

Mein Fazit ist für mich, dass es im Moment kein "Killerfeature" gibt, das uns zur Umstellung auf IFS veranlassen würde. Ich werde mir das aber auf jeden Fall immer weiter ansehen. Wer weiß, was noch kommt (z.B. Codeunterstützung durch KI oder ähnliches).

LG, Dieter

[Fuerchau]

Letzteres eher bei Microsoft-Produkten oder VS-Code;-).
Profound kann aber, glaube ich, auch kein IFS.

[Andreas_Prouza]

Genau das ist im RDi nicht der Fall! Die wichtigste Ansicht im RDi ist die Objekttabelle. Da sehe ich die Programmnamen, Sourcetexte, usw.

Ich kenne die Objekttabelle. Ich meinte, man muss die entsprechende Ansicht öffnen, eben die Objekttabelle.
Für mich stellt sich da nur die Frage ob ich von link komme oder von rechts. Als Entwickler ist mir das im Normalfall egal.

Das kann ich im RDi auch mit dem iSphere Plugin. Allerdings muss ich die alte Version erst (aus unserem Versionskontrollsystem) laden.

Ich sagte "schön" ;-)
Ich kenne die ganzen Teile und ich hab das alles schon (zum Glück) hinter mir.

Für mich als Entwickler geht es darum:
* wie kann ich am schnellsten und einfachsten zu den jeweiligen Sourcen kommen
* wie kann ich den Kompile automatisieren, sodass ich mir keine Gedanken wegen Abhängigkeiten machen muss
* wie sehe ich am schnellsten und einfachsten wer, wann, was geändert hat (am besten sogar direkt im Code wo ich entwickle)
* ich möchte auch im Zuge eines Changes alle betroffenen Sourcen mit deren Änderungen sehen
* Stabilität & Performance (keine Verbindungsunterbrechungen oder langes laden)
* uvm.

Bei all dem spielt das IFS nur eine kleine Rolle.