... auch da habe ich noch ein wenig Wechselgeld...
- jede Version braucht eine eigene Signatur (sonst merkt ein Programm nicht ob die installierte Version neu genug ist).
-- es muss mit jeder Erweiterung eine neue Signatur erzeugt werden
-- alte Komoponenten und Signaturen dürfen nicht entfernt werden.
-- alle Signaturen müssen unique sein

Die meisten können sich diesen Aufwand (und diese Fehlerquelle) ersparen. Wer sowohl das SRVPGM als auch die Verwender kontrolliert, kann sich das schenken und abhängige Komponenten neu binden, das ist einfacher und schneller erledigt.

D*B
Zitat Zitat von mihael Beitrag anzeigen
Ich weiss ich bin etwas spät dran, aber ich dachte ich gebe auch noch was zum Besten, da ich in diesem Thema über ein paar Jahre mit meinen Open Source Serviceprogrammen (http://www.rpgnextgen.com) Erfahrung gesammelt habe.

Die Erweiterung von Serviceprogrammen ist grundsätzlich überhaupt kein Problem, wenn man die Signatur selbst setzt. Hier ein Beispiel für das Erweitern eines Serviceprogrammes mit Verwendung einer Binder Source: http://sourceforge.net/u/fist/src/HE.../json/json.bnd

Das Serviceprogramm enthält nicht nur eine Signatur, sondern mehrere. Somit müssen bestehende Programme nicht neu kompiliert werden, solange das Serviceprogramm kompatibel ist. Die erweiterten Prozeduren einfach immer hinten anhängen.

Ist ein Serviceprogramm aufgrund von Änderungen an der API (Prototypen) nicht mehr abwärtskompatibel, vergibt man einfach eine neue Signatur und löscht die alten Signaturen aus der Binder Source.

Letztendlich steht und fällt das Ganze mit der Sauberkeit der Programmierung bzw. der API.

Meine 2 Cent.

Mihael