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

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

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

Hallo Baldur,
vielen Dank für das Snippet. Um ehrlich zu sein: Mir ist nicht klar, wofür man das benötigt und wo man das hinschreibt und welchen Vorteil das hat.
Im Serviceprogramm selber schreibt man doch schon "export" an die zu exportierenden Procedures. Damit ist doch schon klar, welche Proc exportiert wird.

Und wo schreibt man die oben genannte Bindersprache hin? Ist das eine eigene Teildatei?
Wir haben das noch nie benutzt. Wir haben ein Binderverzeichnis, in das wir alle Serviceprogramme reinhängen.

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