Hallo Dieter,

Ich mach mal den Anfang hier.
Ich habe immer wieder über dieses Thema nachgedacht.
Mich würde interessieren, wie viele bei der Entwicklung in der Praxis tatsächlich auf den Text-Teil der Teildatei gehen um die richtige Source zu identifizieren.

Bei meinem Open Source Build-Tool (https://github.com/andreas-prouza/ibm-i-build) ist die Voraussetzung das alle Sourcen im IFS sind.
Ich habe mich mit Absicht dafür entschieden, den Source-Files den Rücken zu kehren. Ein paar Gründe:


  • Einfacher Codeaustausch
    Die meisten IBM i Projekte/Code-Beispiele usw. sind im Internet als IFS Sourcen zu haben.
  • Einfacher Build
    Um die Sourcen korrekt erstellen lassen zu können, stellen die Entwickler ein Makefile zur Verfügung das den Build komplett erledigt.
    Also: Copy/Paste Ordner ins IFS --> In der Shell "gmake" ausführen und fertig.
  • GIT
    Ohne der Zeilennummerierung (links) und dem Änderungsdatum (rechts) in der Source, ist die Änderungshistorie um Welten besser, da sie nicht verfälscht sind.
    GIT hat mir wegen der Zeilennummerierung und/oder dem Änderungsdatum sehr viele Codezeilen als Änderung markiert, die es jedoch gar nicht waren. (Z.B.: nur weil ich drüber eine Zeile hinzugefügt hatte oder wenn man die Änderung wieder rückgängig macht, bleibt das Änderungsdatum rechts.)
  • Unabhängikeit der IDE
    Bei Source-Files brauch ich eine IDE (oder zumindest ein Plugin) welche die komplette IBM i Welt unterstützt.
    Gibt es zum Teil auch jedoch auf Kosten von diversen Einschränkungen und Performance.
    Bei Sourcen im IFS, brauch ich lediglich die Unterstützung für die Programmiersprache und diese ist viel einfacher zu bekommen.
  • Performance
    Ein langzeit SEU Nutzer kann teilweise viel schneller in eine Source einsteigen als der RDi oder VSCode.
    (Der RDi ist von Natur aus schon mal langsam.)
    Wenn die Sourcen im IFS und (wie bei meinem Build-Tool) auch in GIT liegen, habe ich die Sourcen auch bei mir am PC Lokal.
    Dadurch gibt es niemandem der im SEU schneller in eine Source einsteigen kann als ich mit VSCode.
    Das ist eine ganz andere Art von Arbeiten.
    Das ist so als ob ich von einem Fiat Punto zu einem Ford Mustang wechsel.
  • Zukunftssicher(er)
    Ist das Ziel auch zukünftig Entwickler für seine Applikation gewinnen zu können, dann kann dies auf diese Art einfacher erreicht werden.
    Wenn ich neue junge Entwickler auf IBM i Einschule, geht der Trend sehr stark dahin, dass die Entwickler schon ihre eigenen lieblings IDEs haben (meist vscode) und sich nicht sehr gerne einschränken lassen wollen.
    Bei vielen Code Management Tools ist man z.B. mit dem RDi verheiratet aber auch sonst sehr stark eingeschränkt.
    Bei meinem Build-Tool kann jeder seine lieblings-IDE verwenden ohne Einschränkungen.


Dem ganzen gegenübergestellt stehen die Source-Texte und jene, die sich vom SEU nicht trennen wollen.

Da mein Build-Tool sehr offen und flexibel ist, habe ich auch schon überlegt die Source-Texte einfach in den Source-Namen zu integrieren:
Z.B.: "WHI001R__Das ist ein langer Text.rpgle"
Beim Compile könnte der Text dann einfach abgeschnitten werden dadurch wäre auch dieses Problem gelöst.

Ich bin auch gespannt auf den Input vieler zu diesem Thema.

lg Andreas