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]

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.

[Fuerchau]

Wenn du mal ein DSPSRVPGM machst, wirst du erstaunt sein, dass da mindestens ein Modul erstellt wurde, was eben intern passiert (CRTxxxMOD, CRTPGM).
Ein Modul sollte themenspezifisch mehrere Prozeduren aufweisen.

Das mit Dieters Views ist ein wenig überdimensioniert oder eben Ansichtssache.
Solange ich mit select * arbeite und DS'n verwende ist alles gut, da beim nächsten Recompile der Precompiler entsprechend erweitert.
Wenn man auf der sicheren Seite sein will, sollte man sowieso mit Feldlisten bewusst arbeiten, was man ja wegen Faulheit eben meist sein lässt.
Dadurch fällt auch z.b. der optimierte ReadOnlyIndex-Zugriff weg.

Spätestens beim Update/Insert bist du ja eh wieder auf die Table angewiesen.

[BenderD]

Spätestens beim Update/Insert bist du ja eh wieder auf die Table angewiesen.

... warum?

D * B

[BenderD]

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

Procedure := aufrufbare Einheit, hat lokale Variablen und kann auf globale Variablen des Moduls zugreifen.

exportierte Procedure := kann aus anderen Modulen benutzt werden.

exportierte Variable := Pfui, Bäh!

Module := Compileeinheit, wird aus Quelle erstellt. Kann in PGM oder SRVPGM per copy eingefügt werden.

SRVPGM := macht Module verfügbar (bind by reference).

Binder Source := legt fest, was von ausserhalb des SRVPGMs sichtbar ist (Parameter beim CRTSRVPGM: *all oder Binder Source) und gibt die Möglichkeit die Reihenfolge der Exporte selber festzulegen und selber eine Signatur festzulegen.

Es würde ... doch so sein, dass die Datenstrukturen versioniert werden, oder? Also zunächst heißt die Struktur "KUNDE_Datensatz", nach einer Felderweiterung dann "KUNDE_DatensatzV2"

Kann man so machen, wenn einem nix besseres einfällt (man könnte ja auch seine Dateien nach Erstellungsdatum durchnummerieren), in vielen Fällen des täglichen Lebens, könnten einem auch sprechendere Namen einfallen. Entscheidend ist, dass die vorherigen "Varianten" ihre Namen behalten. Dann ändert sich an allem bisherigen nix. Meist ist es so, dass bisherige Programme ein zusätzliches Feld auch nicht brauchen, dann packt man die auch nicht an (warum soll man diese Programme verkomplizieren). Da wo das gebraucht wird, wird eine View benötigt, die das "neue" Feld benötigt (aber vielleicht andere nicht), dafür gibt es dann eine zusätzliche View.
=> mehr Views und die Programme werden einfacher, die Zugriffe schneller! (Wird so ein Feld überall gebraucht,kann man nicht benötigte Views löschen - es ist aber keineswegs Ziel in Programme Felder reinzunehmen, nur weil sie "da" sind!).

Am Rande sei erwähnt: Es gibt nur 2 Varianten bei SQL Zugriffen, die gegen Seiteneffekte stabil sind.
select * und e DS oder select Feldliste in Feldliste, alles andere ist no risc, no fun!

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.

Wenn sich alle dranhalten, kann man das so machen. Wenn nicht: no risc, no fun! (Ich bin für fun ohne risc!)

mfG
D*B

[Andreas_Prouza]

Losfahren kannst du damit schon seit langem.
Wir reden hier ja um die "Getränkehalter" ;-)


Ich verstehe die Bedenken, hatte ich lange auch, nur wenn ich mir die "fertigen" Lösungen (kostenpflichtig) anschaue, sind diese weit hinten, bezogen auf den heutigen Stand der Technik. Diese sind alles andere als "fertig". Das hat mich zum Umdenken gebracht.


Das Beispiel der Source-Texte hat es deutlich gemacht, wie schnell und einfach es geht wünsche umzusetzen.
Wenn du neben den Source-Texten auch noch weitere Informationen haben willst (Kategorien, Labels, ...), wie lange würden die "fertigen" Lösungen benötigen, um solch ein Feature zu implementieren? ... falls überhaupt.
Ich habe hier eine Lösung zur Verfügung gestellt und das innerhalb von ein paar Minuten.
Und mit dieser Lösung hast du mehr Möglichkeiten als es die anderen bieten.


Markdown war nur ein Beispiel. Markdown ist halt passend, weil dies immer stärker in den Vordergrund kommt. (Z.B.: jede Doku in Github wird mit Markdown geschrieben)
Könnte aber auch mit JSON gemacht werden und es mit ein wenig HTML & Javascript darstellen lassen. Das ganze wird im IDE wie im Browser dargestellt.
Bei Bedarf kann ich da auch gerne unterstützen, kann aber auch jeder anderer der ein wenig sich mit HTML auskennt. Es gibt auch genug Beispielcode im Internet das man sofort via Copy/Paste verwenden könnte.


Du kannst dir gerne mein Projekt auf GitHub anschauen. Die Scripts habe ich alle mit Bash geschrieben.
Kann man aber auch mit Python, Node.js oder was auch immer machen wenn etwas zusätzlich benötigt wird.


Wenn du ein "fertiges" Produkt nimmst, und du brauchst eine Erweiterung, dann machst du das ja auch nicht selbst sondern du beauftragst den Hersteller (falls er das machen kann/will).
Genauso machst du es auch bei Open Source Projekten.
Der Unterschied ist nur, du bist nicht an den Hersteller gebunden. Jeder der sich in diesem Gebiet etwas auskennt kann das machen, schneller, einfacher, unkomplizierter, transparenter, kostengünstiger.


Die stärken der "fertigen" Produkten liegt wo anders.
Wenn du z.B. signierte Deployments benötigst, oder eine Zertifizierte Software brauchst, dann würde ich dir die kostenpflichtigen Lösungen empfehlen.


Was den RDi Betrifft:
Ich habe die RDi Phase hinter mich gelassen.
Jahrelang habe ich nur mit diesem gearbeitet (und würde es auch noch tun, wenn der SEU die einzige alternative wäre).
Ich habe auch einige Jahre im mit GIT im RDi und Sourcen in Source-Files gearbeitet.
Ist funktioniert alles grundsätzlich und ist besser als nichts.
Nur im täglichen leben hat mich einiges gestört, war nicht praktisch und teilweise eingeschränkt.
Der RDi selbst ist sowieso immer mehrere Generationen hinter dem "richtigen" Eclipse.
Deshalb bevorzuge ich den VSCode. Mein Build-Tool kannst du aber genauso auch mit RDi benützen.


Zu SRVPGM:
Mein Weg ist: 1 Modul = 1 SRVPGM
Ändere ich etwas im Modul werden automatisch alle abhängigen Sourcen mit kompiliert.
D.h. ändere füge ich eine Spalte hinzu, werden alle Module & PGMs neu erstellt, die darauf referenzieren. Und dann noch alle Module & PGMs die auf die zuvor neu erstellten Module zugreifen usw. usw.
Gerade bei DB Erweiterungen kann das einen Rattenschwanz an neu zu erstellenden Objekten mit sich führen.
Der Vorteil hier ist jedoch, dass der Entwickler weniger Fehlerquellen verursachen kann und ich durch die erneuten Kompiles diverse Prüfungen habe auf die ich nicht verzichten will.
So machen das übrigens auch die "fertige" Lösungen.

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