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

[dschroeder]

Hallo zusammen,

ich habe mich in letzter Zeit etwas über Merlin, DevOps , VSCode usw. informiert.

Es scheint, als sei es für viele Anbieter und Entwickler normal, dass man seine RPGLE-Sourcen demnächst komplett im IFS hält.

Das würde doch bedeuten, dass man nur noch die 10-stelligen Programmnamen ohne den 50-stelligen Teildateitext zur Verfügung hat, oder? Das kann ich mir bei uns im Moment gar nicht vorstellen. Es gibt aber Stimmen von Leuten, die ich durchaus als kompetent einschätze, die sagen, dass man sich damit abfinden muss und man sich daran gewöhnen kann.

Ist das tatsächlich so? Hat schon jemand seine Entwicklung auf IFS umgestellt?

Wir haben bei uns natürlich auch Namenskonventionen. Aber damit allein könnte ich unsere Sourcen (mehr als 20.000 RPGLE-Members) nicht mehr wirklich beherrschen, denke ich.

Oder verstehe ich die Lösungsideen von IBM (und anderen Entwicklern) nicht richtig?

LG, Dieter

[Andreas_Prouza]

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

[dschroeder]

Hallo Andreas,
vielen Dank für deinen Beitrag. Ist sehr gut und strukturiert geschrieben!

Ich kann sehr viele deiner Pro IFS Punkte nachvollziehen. Genau das ist ja auch der Grund, weshalb ich mich verstärkt mit dem Thema befasse.

Allerdings klingt es bei dir so, als wäre der Verzicht auf die Source-Beschreibungstexte nur eine kleine Unschönheit. Das ist bei uns im Team definitiv nicht so. Möglicherweise liegt das an unserer Entwicklungsstrategie, die wird seit 30 Jahren betreiben.

Unsere wichtigsten Strategiepunkte sind:

• Lieber viele kleine Programme als ein großes Programm
• Pro Serviceprogramm (möglichst) nur eine einzige exportierte Procedure
• Code (möglichst) nie kopieren, sondern stattdessen Programme so auslegen, dass sie an vielen Stellen wiederverwendet werden können.

Diese Punkte führen dazu, dass Programme von vielen Stellen aufgerufen werden und dass wir sehr viele, relativ kleine, Sourcemember bekommen. Ein Sourcemember hat bei uns im Durchschnitt weniger als 250 Zeilen Code. (incl. Kommentare).

Mir ist bewusst, dass es viele Unternehmen gibt, die das mit den Serviceprogrammen anders machen und die stattdessen nur sehr wenige Serviceprogramme mit vielen exportieren Procedures haben. Aber hat man da nicht das Problem, dass eine Änderung der Parameterschnittstelle einer Procedure sofort die Signatur des gesamtes Serviceprogrammes ändert und man dann sehr viele Programme neu kompilieren muss?

Die Tatsache, dass wir versuchen, Code nicht zu kopieren, sondern stattdessen Programme zu schreiben, die wir von überall nutzen können, führt natürlich zu einem etwas "monolithischen" Gesamtsystem. Das wiederum führt dazu, dass ein Entwickler sich oft mit Programmen aus unterschiedlichen Projekten befassen muss. Das heißt, man kann sich in der täglichen Arbeit nicht ausschließlich auf einige wenige Sourcen konzentrieren, sondern man muss sich oft mit Sourcen beschäftigen, die in ganz unterschiedlichen Projekten abgelegt sind. Und dabei benötige ich die Beschreibungstexte.

[Robi]

Moin,
bei uns ist der fehlende Text auch einer der Gründe nicht zu wechseln!
Wir haben, vor über 20 Jahren ein System geschaffen das heute noch mit 'modernen' Tools mithält.
Die Projektverwaltung basiert zwar nur zum kleinen Teil auf TEXT Informatonen, trotzdem sind diese nötig.

Und Kunden, die unsere Verwaltung nicht haben, haben häufig Ihr System ganz auf dem Text (und der ART) aufgebaut. Grosse Anwendungen verschiebt man nicht 'mal eben' ins IFS.

Die Idee, den Text in den Namen zu integrieren ist gut, erfordert aber auch eine grössere Umstellung.

Für uns, eins der grössten Hindernisse!

[dschroeder]

Danke Robi.
Ich hatte schon befürchtet, ich bin der einzige, der den Text benötigt.

[Fuerchau]

Bzgl. der Signaturen von Serviceprogrammen gilt folgendes:

Die Prozedurnamen werden alphabetisch sortiert und darüber dann eine Signatur berechnet.
Die Aufrufparameter gehören nachweislich nicht dazu!
D.h., wenn man Aufrufsignaturen ändert, hat das erst mal keinerlei Auswirkungen, da es diesbezüglich keine Laufzeit- sondern nur Compilezeitprüfungen gibt.
Bei Aufrufsignaturen gilt eigentlich generell die Regel, dass neue Parameter immer am Ende angefügt werden sollten und um Compilerprobleme auszuschließen mit *OMIT zu ergänzen.
Schließlich kann man die Anzahl der Parameter und die Adresse abfragen.

Auch wenn es anscheinend verpönt ist und z.T. vehement bestritten wird, aber eine manuelle Definition einer SRVPGM-Source enthebt euch aller Probleme:
- Die Signatur kann ganz einfach als Text selber definiert werden, dadurch gibt es keine Aufrufabbrüche
- Die Rehenfolge der Exporte darf sich nicht ändern, neue Funktionen gehören immer ans Ende
Vorteile:
- Es gibt keinen Rekompilierungsbedarf bestehender Programme!
- Schnelleres Ausrollen neuer Funktionen und Services, da nicht alles ausgeliefert werden muss (Patches).
Nachteile:
- nicht einen Einzigen!
Begründung:
Der Compiler importiert die Signatur der Funktionsnamen eines Services in das Programm/Modul.
Der generierte Aufruf (callp) verwendet den relativen Index aus der Liste der Funktionsnamne um die Funktionsadresse aus dem Service zu ermitteln und ruft diese dann auf.
Beweis:
Schreibt einfach einen Service mit 2 Funktionen und verwendet eine SRVPGM-Source mit der Reihenfolge Funktion1, Funktion2.
Ein Hauptprogramm ruft dann korrekt Funktion1 und Funktion2 auf.
Tauscht die Reihenfolge in der SRVPGM-Source und erstellt den Service neu.
Das Hauptprogramm ruft nun die falsche Funktion auf.
Es gib allenfalls Laufzeitfehler wenn die Funktion auf Parameter zugreifen will, einen Call-Fehler gibts nicht.
Man kann auch Funktionspointer verwenden, wenn man D*B's Methoden zum dynamischen Aufruf verwendet. Weist man einem Funktionspointer eine konstante Adresse zu, ist das dann leider nicht dynamisch.

Möchte man generell Parameter ändern und ergänzen, so empfielt sich hier, eine neue Funktion zu schreiben und die Alte ruft die Neue mit ggf. Default-Werten auf.
Werden Return-Strukturen zurückgegeben, so empfielt sich hier bei Ergänzungen neue Felder ans Ende zu legen. Denn eine Compile- oder Laufzeitprüfung bzgl. der Zuweisung von Strukturen gibt es nicht.
Empfehlenswert sind dann halt Versionsnummern in der Struktur.
Dasselbe gilt auch für Strukturen als Parameter. Bei CONST gibts gar keine Prüfung, bei Referenz gibts nur eine einfache Typrüfung und da wird eine Struktur als CHAR(n) behandelt. Es gibt also einen Compile-Fehler wenn die Länge nicht stimmt. Haben sich Felder vertauscht, merkt das nur das Programm und nicht der Compiler.
Seht euch dies bzgl. die IBM-API's an. Nicht umsonst gibt es das variable Listen oder Strukturen mit Format-Namen.

Da ein Serviccprogramm viele Module enthalten kann, solle man also durchaus themenspezifische Module erstellen, die aber trotzdem zu einem Serviceprogramm gebunden werden können.

Ladezeiten:
Jedes Serviceprogramm, dass in einem Hauptprogramm definiert wird, wird beim Starten geladen.
Zusätzlich wird jedes verwendete Serviceprogramm, dass von einem anderen Serviceprogramm verwendet wird, ebenso geladen.
Somit sind viele kleine Serviceprogramme eben kontraproduktiv.
Allerdings kann man das entschärfen, wenn man im BNDDIR die Services mit Aktivierung *DEFER einträgt. Dann werden die Services erst zur Laufzeit geladen. Bei automatischen Signaturen werden allerdings erst beim Laden geprüft, was dann halt erst später zur LAufzeit auftreten wird.

Mit SQL-Quellen habe ich halt so meine Probleme (V7R3):
Ich verwende gerne like-Definitionen für SQL-Parameter, da sich da vieles durch Copy/Includes und externe Referenzen festlegen lässt.
Jedoch:
Verwende ich Include, werden Like vom SQL-Precompiler nicht erkannt, da anscheinend Includes nicht gelesen werden.
Verwende ich Copy klappt das mit den Likes, allerdings kann ich nested Copys nur bei ILERPG, nicht aber im SQLRPGLE verwenden.
Wie siehts diesbezüglich aber mit IFS aus? Hier funktioniert ja nur Include.
Bei der RPG-Compileroption RPGPPOPT gibt es aber Schwierigkeiten mit den Zeilenumbrüchen bei langen SRCPF'S, was sich im IFS verschärfen dürfte.

Und zu guter letzt:
In den Erstellbefehlen gibt es immer ein TEXT-Parameter, der i.d.R. den Quelltext-Text (*SRCMBR) ausliest. Da nun in den indivduellen Makes die Befehle angegeben werden, kann man sich ebenso die Texte via Direktiven in die Quellen legen um sie dem Make-Prozessor zu übergeben, z.B.:
//#TEXTies ist mein bestes Programm

[Andreas_Prouza]

Auf das Thema Service Programme gehe ich jetzt mit Absicht nicht ein um hier nicht zu sehr Offtopic zu sein. Kann gerne auch in einem separaten Thread diskutiert werden.

Wie siehts diesbezüglich aber mit IFS aus? Hier funktioniert ja nur Include.
Bei der RPG-Compileroption RPGPPOPT gibt es aber Schwierigkeiten mit den Zeilenumbrüchen bei langen SRCPF'S, was sich im IFS verschärfen dürfte.

Ich habe beides im IFS im Einsatz, /Include und /Copy beides geht wudnerbar.
Probleme mit Zeilenumbrüche hab ich noch keine gehabt. Da versteh ich aber das Problem gerade nicht wirklich.

In den Erstellbefehlen gibt es immer ein TEXT-Parameter, der i.d.R. den Quelltext-Text (*SRCMBR) ausliest. Da nun in den indivduellen Makes die Befehle angegeben werden, kann man sich ebenso die Texte via Direktiven in die Quellen legen um sie dem Make-Prozessor zu übergeben, z.B.:
//#TEXTies ist mein bestes Programm

So hab ich es bei einem Kunden auch gemacht, alle Texte als Kommentar in die Sourcen rein und beim Compile diese dann herausnehmen. Funktioniert auch wunderbar.
Das Thema ist aber hier, dass die Texte nicht beim Objekt fehlen sondern bei der Source im IFS.

Und Kunden, die unsere Verwaltung nicht haben, haben häufig Ihr System ganz auf dem Text (und der ART) aufgebaut. Grosse Anwendungen verschiebt man nicht 'mal eben' ins IFS.

Die Idee, den Text in den Namen zu integrieren ist gut, erfordert aber auch eine grössere Umstellung.

Die Umstellung auf's IFS hab ich auch schon paar mal gemacht.
Die Erfahrung hat gezeigt, dass nicht die Umstellung ins IFS oder auch die Texte in den Filenamen zu packen die großen Aufwände sind. Dies wird automatisiert via ein paar Skripte gemacht.
Das größte Thema ist das Entwicklungs-Team auf die Umstellung vorzubereiten und diese dann auch durch zuziehen.
Meist liegt es daran, dass im Ford Mustang der Getränkehalter nun nicht mehr dort ist wo er im Fiat Punto immer war.

Bei beiden Varianten, ob der Text im Filenamen oder als Kommentar in der Source verwendet wird, kann man entsprechend Filtern & Suchen.

[dschroeder]

Hallo Baldur,
herzlichen Dank für deine ausführlichen Infos!

Ich muss das alles erstmal für mich sortieren.

Wenn ich dich richtig verstehe, gilt Folgendes bei mehreren Exporten in einem Serviceprogramm:

1. Wenn ich 10 Procedures in einem SRVPGM habe und bei der 4. Procedure einen Parameter hinzufüge und dann das SRVPGM kompiliere, habe ich keine Laufzeitprobleme bei den Programmen, die die anderen 9 Procedures benutzen?
2. Wenn ich den neuen Parameter in der 4. Procedure mit options(*nopass) deklariere, habe ich in gar keinem Programm, das irgendeine Procedure des Serviceprogramms nutzt, Laufzeitprobleme?
3. Wenn ich die Reihenfolge der Procedures im Serviceprogramm ändere, bekomme ich aber Probleme? (Damit könnte ich sicherlich leben)

Ist das so?

[Fuerchau]

1: Ja, auch nicht bei der geänderten Prozedur, wenn sie auf fehlende Parameter prüft.
2: Ja, da ich per %ADDR(pX) = *null die Übergabe prüfen kann.
3: Nein, wenn du die Reihenfolge in der RPG-Source änderst, hat das keine Auswirkungen. Die Reihenfolge in der SRVPGM-Source zu ändern ist grundlos, da sie unnötig ist.
Möchtest du die Reihenfolge aus unerfindlichen Gründen anpassen, solltest du den Signaturtext anpassen.
Ich verwende da immer "V1.0", somit kannst du dann "V1.1" ff verwenden und musst allerdings Alle neu kompilieren.

[dschroeder]

Was meinst du mit Signaturtext? Der Name der exportierten Procedure?

[Fuerchau]

SRVPGM-Quelle:

STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('V1.00')
EXPORT SYMBOL('D002DBT_getDatasetfromD002')
EXPORT SYMBOL('D002DBT_getNewKeyNumber')
EXPORT SYMBOL('D002DBT_updateDataD002')
EXPORT SYMBOL('D002DBT_insertDataD002')
ENDPGMEXP

[Andreas_Prouza]

Hier noch eine weiter Möglichkeit bzgl. der Source-Texte.
Diese könnten bei der Übernahme ins IFS einmal automatisiert in ein Markdown-File geschrieben werden.
Darin auch gleich der Link um die Source zu öffnen.



Ab hier gibt es wieder endlos Möglichkeiten für Erweiterungen:

• Zusätzlich zur Source können auch weitere Infos angegeben werden
  das Änderungsdatum, Änderungsuser, Key/Such-Begriffe, Kategorien usw.
  Bei Änderungsdatum & User müsste man ein kleines Script schreiben, welches die Source-Liste automatisch von selbst aktualisiert sobald man speichert. Im VSCode kein Problem. Im RDi aber auch möglich.
• Separate Listen können erstellt werden, ähnlich wie die Filter im RDi
• Bei separate Listen können noch zusätzliche Infos wie Ticket-Nr., wenn auf Grund eines Tickets/Projekts diese Liste erstellt wurde.
• uvm.

Im VSCode ist das sehr einfach.
Beim RDi müsst ich noch schauen wie das dort am schönsten geht.

Das ganze geht dann natürlich auch wieder super schnell.
Und schon fängt wieder der Ford Mustang an einem anzulächeln.