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

[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

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

[dschroeder]

Hallo Andreas,
du hast Recht: Wir sind etwas off topic gelandet durch die Diskussion über Serviceprogramme. Deshalb hier meine Antwort zu deinem letzten Post.
Du ziehst ja gerne den Ford Mustang heran. Bitte nimm es mir nicht übel, wenn ich sage: Ist das wirklich ein fahrbereiter Ford Mustang oder ist ein fast fertiges Auto, an dem man erst noch herumschrauben muss, bis man losfahren kann? :-)

Stichwort "Markdown File": Das kenn ich nicht, die Syntax müsste ich mir erst angucken. Oder "kleines Script", um die Sourceliste mit Änderungsdatum zu aktualisieren. In welcher Scriptsprache geht das?

Bitte versteh mich nicht falsch. Wahrscheinlich würden wir hier im Haus (zumindest mit Hilfe meiner Kollegen) diese Scripte bauen können. Aber es gibt doch sicherlich zahlreiche RPG-Programmierer, die eine fertige Lösung suchen, oder? (RDi ist immerhin sofort "fahrbereit").

[dschroeder]

Auch nochmal eine Frage an alle anderen Forumsteilnehmer:

Hat schon jemand einen Wechsel von Teildatei zu IFS-File durchgeführt?
Falls ja, wie hoch war der Aufwand und hat es sich gelohnt?

[Fuerchau]

Die Service-Programmdiskussion halte ich in diesem Rahmen für nicht unwichtig, da man sich viele Abhängigkeitsregeln und Recompiles durch vernünftiges Planen komplett sparen kann.

Wenn ich eine SQL-Tabelle ändere, ggf. nur Recompile für die Programme, die es brauchen, da die anderen, wenn sie denn mit SQL arbeiten, davon gar nichts merken. Voraussetzungen sind natürlich vernünfitge Defaults bei neuen Spalten.
Ansonsten eben leider alle Programm/Module/Services, die diese Datei/Tabelle referieren. Allerdings nicht die in Folge abhängigen Services.

Wenn ich Services ändere gilt dies ebenso.

Wenn ich wie oben diskutiert, für jedes Modul einen Service erstelle, kann es im Zweifel dann passieren, dass der Recomile eines Service hunderte Recompiles der Abhängigen Services auslöst, was vollkommen unnötig ist.
Verwende ich eine SRVPGM-Source, wandle ich das Modul und erstelle das Serviceprogrmm (mit Moduliste) nur neu.

Damit ruduziert sich eben auch der Aufwand von Make-Files und Abhängigkeitsregeln.

[dschroeder]

Meiner Ansicht nach hat man 2 Probleme bei Änderungen:

1. Wenn man eine Tabellenstruktur ändert, ist man zum Durchkompilieren gezwungen, sobald man den Datensatz als (extern) definierte Struktur anspricht. Dagegen kann man ja selbst bei ausschließlichen SQL-Zugriffen kaum etwas machen, denke ich. Es sein denn, man spricht nur einzelne Felder an und niemals eine Datenstruktur. Aber dann hat man es ja mit vielen Parametern zu tun, anstatt sonst nur einen Parameter (die Datenstruktur) zwischen den Programmen durchzureichen.
2. Wenn man die Aufrufparameter eines Programmes ändert. Wir beschränken uns darauf, nur Parameter mit options(*nopass) am Ende der Parameterliste hinzuzufügen. Dann klappt das auch im laufenden Betrieb.
   Wenn es aber eigentlich ein Pflichtparameter ist, ändern wir danach in aller Ruhe alle Aufrufe und geben den neuen Parameter mit. Wenn am nächsten Morgen dann alle Jobs neue gestartet sind, nehmen wir das options(*nopass) raus.

[BenderD]

... ist ja eine Palette von Themen, ich versuche mal ein paar Dinge anzureißen:

@Sourcen im IFS: attraktiv ist die einfache GIT (subversion) Anbindung, die einem eine saubere Versionierung liefert. Das geht aber auch mit verfügbaren Erweiterungen für RDI.

Ein komplettes Paket, wie Andreas das hier skizziert, macht Sinn, wenn die verfügbare Truppe auf mehreren Hochzeiten tanzt. Dann ist Vereinheitlichung von Werkzeugen sicherlich sinnvoll. Was es dann wird, hängt von den skills der Truppe ab und ist auch Geshcmacksache (sagte der Affe und biss in die Seife).
Ein Umstieg für eine reine RPG Truppe macht m.E. keinne Sinn, solange es keine richtige Entwicklungsumgebung gibt (RDI ist das auch nicht, da fehlen die wichtigsten Features : all das, was bei Eclipse für Java unter Source und Refactor kommt). Solange da nichts ist, nehme ich (Geschmacksache!) immer noch SEU, wenn ich mir das aussuchen darf.

@SRVPGMs: Serviceprogramme auf eine exportierte Procedure zu beschränken, ist ein ernsthafter Kunstfehler, dann sollte man stattdessen PGMs nehmen, das spart einem (fast) alle diskutierten Probleme.
Der wesentlliche Unterschied zwischen PGM und SRVPGM ist, dass SRVPGMs mehrere Entrypoints haben, die auf denselben Daten operieren. Das vereinfacht die Schnittstellen (jeder kriegt nur die, die er braucht) und es werden keine Steuerungsparameter übergeben.
Die Größe von SRVPGMs (sprich: wieviel Module binde ich zu einem SRVPGM ist in erster Linie eine Frage des Deployments. Für eine Software mit einer einzigen produktiven Installation favorisiere ich: ein Modul ein SRVPGM, für eine Vielzahl von Installationen sind größere Einheiten oft einfacher.

@Parameter Schnittstellen: Selbige ändert man nicht, sobald man eine Funktionalität in Production hat. Dann gibt es eine neue Funktion (die ja die alte durchaus benutzen kann), mit der geänderten Schnittstelle. Die kann man dann da einbauen, wo die Erweiterung benötigt wird.

@Dateien: hier ist es besonders einfach bei SQL: Alle Programme greifen immen auf Views zu (niemals auf die Table). Standard ist hier select * from XyzView und XyzView as select (Feldliste von Datei). Kommt ein Feld in der Date hinzu, gibt es dann eine weitere View. Jetzt kann man auch die EDS (die immer auf Views verweisen) überall verwenden - ohne dass sich da irgendwas ändert. Mit dieser elementaren Vorgehensweise kann man sogar Felder in eine andere Datei verschieben, ohne dass vorhandene Programme das merken. (Komplizierter wird es bei Erweiterungen von Keys, aber das hat man nicht so oft).

D*B

[dschroeder]

Hallo D*B,
vielen Dank für deine Ausführungen. Auch wenn ich nicht immer bei allem deiner Meinung bin: Dein Schreibstil ist jedesmal unterhaltsam ("Geschmackssache ... Affe ... Seife") :-)

Nochmal für mich zur Klarstellung bei Serviceprogrammen / Modulen, damit ich das auch richtig verstehe:

Du / ihr seht das so:
Ein Sourcemember beinhaltet immer den Code für ein Modul. In einem Modul können mehrere exportierte Procedures sein. Mehrere Module können zu einem Serviceprogramm zusammengebunden werden.
Habe ich das richtig verstanden? (Da bei uns ein Sourcemember (fast) immer zu nur einem Serviceprogramm führt, haben wir mit Modulen zur Zeit nichts am Hut.)

Bei Parameteränderungen gebe ich dir Recht. Wenn man breaking changes macht, sollte man eine neue Version erzeugen. Solange wir mit zusätzlichen optionalen Parametern hinkommen, ist das aber nicht unbedingt nötig, finde ich.

Dein Konzept mit den Datenstrukturen, die immer auf Views basieren, habe ich schon vor Jahren bei dir gelesen und finde es immer noch interessant. Allerdings haben wir es nie umgesetzt. Es gab Bedenken bei uns, dass wir dann mit einer Vielzahl von unterschiedlichen Datensätzen (Datenstrukturen) hantieren müssen. Es würde in deinem Konzept doch so sein, dass die Datenstrukturen versioniert werden, oder? Also zunächst heißt die Struktur "KUNDE_Datensatz", nach einer Felderweiterung dann "KUNDE_DatensatzV2" usw. Richtig?
Falls ja, hat man dann nicht immer noch die gleichen Probleme wie bisher? Ich kann an ein Programm ja nicht die erste Struktur übergeben, wenn Sie die V2-Version erwartet.

Aber wahrscheinlich habe ich nur noch nicht lange genug darüber nachgedacht.