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