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

[Andreas_Prouza]

Losfahren kannst du damit schon seit langem.
Wir reden hier ja um die "Getränkehalter" ;-)


Ich verstehe die Bedenken, hatte ich lange auch, nur wenn ich mir die "fertigen" Lösungen (kostenpflichtig) anschaue, sind diese weit hinten, bezogen auf den heutigen Stand der Technik. Diese sind alles andere als "fertig". Das hat mich zum Umdenken gebracht.


Das Beispiel der Source-Texte hat es deutlich gemacht, wie schnell und einfach es geht wünsche umzusetzen.
Wenn du neben den Source-Texten auch noch weitere Informationen haben willst (Kategorien, Labels, ...), wie lange würden die "fertigen" Lösungen benötigen, um solch ein Feature zu implementieren? ... falls überhaupt.
Ich habe hier eine Lösung zur Verfügung gestellt und das innerhalb von ein paar Minuten.
Und mit dieser Lösung hast du mehr Möglichkeiten als es die anderen bieten.


Markdown war nur ein Beispiel. Markdown ist halt passend, weil dies immer stärker in den Vordergrund kommt. (Z.B.: jede Doku in Github wird mit Markdown geschrieben)
Könnte aber auch mit JSON gemacht werden und es mit ein wenig HTML & Javascript darstellen lassen. Das ganze wird im IDE wie im Browser dargestellt.
Bei Bedarf kann ich da auch gerne unterstützen, kann aber auch jeder anderer der ein wenig sich mit HTML auskennt. Es gibt auch genug Beispielcode im Internet das man sofort via Copy/Paste verwenden könnte.


Du kannst dir gerne mein Projekt auf GitHub anschauen. Die Scripts habe ich alle mit Bash geschrieben.
Kann man aber auch mit Python, Node.js oder was auch immer machen wenn etwas zusätzlich benötigt wird.


Wenn du ein "fertiges" Produkt nimmst, und du brauchst eine Erweiterung, dann machst du das ja auch nicht selbst sondern du beauftragst den Hersteller (falls er das machen kann/will).
Genauso machst du es auch bei Open Source Projekten.
Der Unterschied ist nur, du bist nicht an den Hersteller gebunden. Jeder der sich in diesem Gebiet etwas auskennt kann das machen, schneller, einfacher, unkomplizierter, transparenter, kostengünstiger.


Die stärken der "fertigen" Produkten liegt wo anders.
Wenn du z.B. signierte Deployments benötigst, oder eine Zertifizierte Software brauchst, dann würde ich dir die kostenpflichtigen Lösungen empfehlen.


Was den RDi Betrifft:
Ich habe die RDi Phase hinter mich gelassen.
Jahrelang habe ich nur mit diesem gearbeitet (und würde es auch noch tun, wenn der SEU die einzige alternative wäre).
Ich habe auch einige Jahre im mit GIT im RDi und Sourcen in Source-Files gearbeitet.
Ist funktioniert alles grundsätzlich und ist besser als nichts.
Nur im täglichen leben hat mich einiges gestört, war nicht praktisch und teilweise eingeschränkt.
Der RDi selbst ist sowieso immer mehrere Generationen hinter dem "richtigen" Eclipse.
Deshalb bevorzuge ich den VSCode. Mein Build-Tool kannst du aber genauso auch mit RDi benützen.


Zu SRVPGM:
Mein Weg ist: 1 Modul = 1 SRVPGM
Ändere ich etwas im Modul werden automatisch alle abhängigen Sourcen mit kompiliert.
D.h. ändere füge ich eine Spalte hinzu, werden alle Module & PGMs neu erstellt, die darauf referenzieren. Und dann noch alle Module & PGMs die auf die zuvor neu erstellten Module zugreifen usw. usw.
Gerade bei DB Erweiterungen kann das einen Rattenschwanz an neu zu erstellenden Objekten mit sich führen.
Der Vorteil hier ist jedoch, dass der Entwickler weniger Fehlerquellen verursachen kann und ich durch die erneuten Kompiles diverse Prüfungen habe auf die ich nicht verzichten will.
So machen das übrigens auch die "fertige" Lösungen.

[Fuerchau]

Wie gesagt, jedem das Seine, weniger ist manchmal mehr.

Bzgl. IFS-Quellen hätte ich noch gerne folgendes gewusst, ggf. kannst du das mal ausprobieren:

Definiere ich eine SQL-Hostvariable mit like, funktioniert dies derzeit nur, wenn ich die Basis in einer /Copy oder direkt in der Quelle habe.
Definiere ich das in /Include, wie es für IFS ja benötigt wird, funktioniert dies nicht, da Include vom Precompiler nicht aufgelöst wird.
Nested Copy wiederum, was für ILERPG erlaubt ist (bis 32), ist für den Precompiler jedoch nicht erlaubt.
Like-Definitionen sind aber, was die Erweiterbarkeit angeht, ein wesentlicher Bestandteil von ordentlichen Quellen.

Nun gibts ja noch die Pre-Compileroption für die Auflösung der Quellen mit *LVL1/*LVL2.
Dies scheint aber wiederum von einem anderen Reader aufgelöst zu werden als vom ILERPG-Compiler.
Schreibt man nämlich Code über die max. Standard-ILE-SRC-Breite hinaus, wird dieser Code einfach abgeschnitten. Der ILERPG-Compiler bricht die Zeilen automatisch um.
Aufgefallen ist das halt in einem größeren Projekt, in dem der Default einfach mal auf *LVL2 gestellt wurde. Viele Quellen waren dann nicht mehr kompilierbar.

Wie sieht das nun im IFS-Fall aus?
Wird Include vom SQL-Precompiler da aufgelöst?
Wird geschachtelter Include unterstütz?
Das würde die Quellverwaltung eben erheblich vereinfachen, da man Mehrfachincludes ja mit If-Direktiven verhindern kann.

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