ILE Quellen IFS vs Source Files

[Malte]

Moin *all,

wir haben aktuell bei uns historisch bedingt alle Quellen in Source Files und sind grade am überlegen ins IFS zu wechseln.

Da wir uns hier Vorteile für eine GIT Integration erhoffen, aktuell haben wir da eine selbst gebaute Lösung.
Zudem ist es recht ansprechend Sourcen Themen Bezogen in Ordner zusammen zufassen.

Nun meine Frage wie handhabt ihr das ?

• Sind eure Sourcen in IFS ?
• Verwendet Ihr GIT ?
• Was für Vor-/Nachteile gibt es bei Quellen im IFS ?

Ich freu mich von euren Erfahrungen zu hören.

[Fuerchau]

GIT bietet auf jeden Fall Vorteile, da man an Projekten gemeinsam arbeiten kann.
Durch sog. Branches kann man Versionen verwalten und an älteren Releasen schon mal Patches erstellen und diese in das Hauptprojekt mergen.
Mit RPGLE sollte dies auch funktionieren.
Allerdings benötigt ihr dann wohl eher Visual Studio Code, da es eine Projektverwaltung meines Wissens nach für RDi so nicht gibt. Es gibt zwar CMOne als Addon für RDi und IBM i, aber das Mergen von Quellen und Branches finde ich da nicht.

Durch Git im VS werden in den Projektdateien auch die Änderungen, was und von wem, vermerkt und können in den Quellen auch jederzeit angezeigt werden.
Die Quellen müssen für diese Zwecke dann wohl auch im IFS liegen.
Ins besonders überzeugt die Geschwindigkeit, die bei RDi manchmal sehr zu wünschen übrig lässt.

Nachteile durch das IFS entstehen eigentlich keine, wenn man GIT einsetzt. Ohne GIT sind die Nachteile allerdings größer.
Gravierender Vorteil wird dann bei SQL sein, da ja COPY durch INCLUDE wohl generell ausgetauscht wird, dass dann wohl endlich auch mehr als 1 Verschachtelungsstufe möglich wird.
Denn SQL via SRCPF supportet da nur COPY und da auch nur 1 Ebene, obwohl RPGLE da mehr kann.
*LVL1/*LVL2-Umwandlungen, also Copy/Includes/E DS aufzulösen, hilft da leider nicht immer, da SQL-Statements da nicht umgebrochen werden und dann zu Compilerfehlern führen. Ohne *LVLx macht das nämlich der SQL-Precompiler.

Nachteile sehe ich da überhaupt keine, wenn man
- GIT o.ä. einsetzt
- Projekte und Abhängigkeiten, ggf. Multi-Projekte, verwalten kann.

[Malte]

Danke für die schnelle und ausführlich Antwort.

Ja die Vorteile von GIT kennen wir da wir GIT mit DevOps schon bei anderen Sprachen/Projekten verwenden und diese Prozesse natürlich auch im IBM i Umfeld nutzen wollen.

Das mit Include in SQLRPGLE hatte aber auch schon in Source Files bei uns funktioniert.
Hier hatten wir schon /Include verwendet und beim Compiler *LVL2 verwendet.
Zur weitern Info, wir sind aktuell auf V7r4

Gab es beim RDI nicht auch eine GIT integration mit "i Projekt" oder funktioniert dieses nur mit Source Files ?

Bei der Verwendung von GIT mit VSCode sollte man hier dann local mit den Sourcen abreiten?
Wenn ja, gibt es von IBM hier schon deployment Beispiel um die Sourcen bzw. das Objekt auf die IBM i zu bekommen ?

[Pikachu]

Eventuell kommen Quellenart und Text der Quellenteildateien beim Kopieren ins IFS nicht mit!?

[Fuerchau]

Für VSCode gibts bereits AddIns für die IBM i, die die Quellen aufs IFS schieben und den Compiler dann anschmeißen.
Z.B. https://marketplace.visualstudio.com....code-for-ibmi
https://marketplace.visualstudio.com...velopment-pack

*LVL2 funktioniert nur, wenn du SQL's nicht breiter schreibst als die Standard ILE-SRC von 112 Zeichen.
Verwendest du breitere SQL's werden sie ohne *LVL2 vom precomipler auf 112 umgebrochen, mit *LVL2 bei 112 abgeschnitten.
Da durchaus von RDi größere Breiten erlaubt sind und auch genutzt werden, muss man bei SQL dann halt aufpassen. Dieser Nachteil besteht schon, seit dem man breiter als 112 Stellen erfassen kann.
Warum die IBM an diesem simplen Problem immer noch nichts macht, kann ich nicht nachvollziehen.

Das lokale Arbeiten ist erheblich schneller, da dies auch Remote im Homeoffice geht und das IFS im Vergleich zum Windows-NTFS sehr langsam ist. Und da man Quellen ein- und auscheckt werden die Quellen ja sowieso kopiert. An Projekten arbeitet man gemeinsam und synct diese per Merge mit seinen eigenen Quellen.

[Malte]

@Pikachu meinst du wenn die Sourcen aus den Source Files ins IFS kopiert werden ?
Weil da für habe ich mir ein Kleine tool geschrieben was das löst.
Oder meinst du das es mit GIT da ein Problem geben könnte ?

@Fuerchau die Extension haben wir uns schon mal ein bisschen angeguckt aber bis jetzt nur mit Quellen auf der Ibm i

Das mit dem lokalem arbeiten werde ich mir dann noch mal angucken, danke dir

[RobertPic]

Eventuell kommen Quellenart und Text der Quellenteildateien beim Kopieren ins IFS nicht mit!?

Die Quellenart sollte doch die File-Extension sein?
Den Text kann man als Variable in Source(Kommentar) ablegen und beim Kompilieren berücksichtigen.
Allerdings weiß ich nicht ob das irgendein PlugIn automatisch macht.

Derzeit konzentrieren wir uns noch darauf möglichst viele Sourcen (Cobol) auszurangieren und gar nicht übernehmen zu müssen.

Was meines Wissens verloren geht ist das Änderungsdatum auf Zeilenebene. Mit einem kleinen Hilfsprogramm sollte man das hinbekommen - historisch zu commiten (Datum als Kommentar zum Commit bzw. als Parameter). Damit kann man im VSCode dann auch das alter der Zeile abrufen. (theoretisch - wie gesagt, das dauert noch bei uns).

[Fuerchau]

Nun, der Typ der Quelle im IFS wird durch die Endung festgelegt, so wie es bei Windows i.d.R. gültig ist.
cs = C#, vb = VB.Net, cpp = C++, usw.
Warum also nicht .rpgle, .sqlrpgle, .clp, .cle.
Was den SRC-Text angeht, so kann man den Namen der Quelle ja sprechender gestalten.
Immerhin kann man den Namen des Programmes/Moduls ja im ctl-opt angeben.
DFTNAME('MYPROG')
DFTNAME('MYMODUL')

Und insgesamt gibts mehr Möglichkeiten mal was zu suchen, da die Dateien schneller zu durchsuchen sind.

[Malte]

beim dem lokalen Arbeiten mit GIT wie geht ihr denn dann beim Teste damit um ?
Aktuell haben wir ein DEV System auf dem wir parallel entwickeln.

Gibt es dann da eine Funktion um pro Branche eine Lib zu erstellen?

Derzeit konzentrieren wir uns noch darauf möglichst viele Sourcen (Cobol) auszurangieren und gar nicht übernehmen zu müssen.

Am Aussortieren nicht mehr benötigter Sourcen sind wir auch grade dabei um hier ein paar Altlasten los zu werden.

[Fuerchau]

Auch bei gemeinsamen Projekten kümmert sich immer nur Einer um eine Quelle.
Quellsharing ist zwar erlaubt, gerade aber im Zusammenhang mit der IBM i dann u.U. wenig sinnvoll.
Als Ziellib sollte man eine versionierte LIBVnRn verwenden, dem Branch entsprechend, die dann alle Objekte beinhaltet.
Für Tabellen und Daten reicht i.d.R. eine Dev-Lib und ein Echt-Lib, da Tabellenergänzungen-/Erweiterungen in einer Vorstufe incl. Neuerstellung aller Beteiligten problemlos möglich ist.
Denn was ein Programm nicht kennt, wird auch nicht berührt.
Dann kann man anschließend in Ruhe an der neuen Version arbeiten.

[Andreas_Prouza]

Hi Malte,

zunächst mal gratuliere ich für den mutigen Schritt die alten SRC-PF verlassen zu wollen!

@GIT-Branches

Als Richtwert könntest du dir Gitflow ansehen. Hier bekommst du einen guten Überblick wie mit Branches im Git gearbeitet wird.
Ich begleite mitlerweile immer mehr Firmen beim Umstieg. Auch in den Academys an denen ich unterrichte, ist dies mitlerweile pflicht.

Meine Empfehlung: Macht es langsam!
Führt nicht gleich am Anfang das ganze Branchen-Konzept ein, sondern lernt zunächst die Basics und dann Schritt für Schritt.
Es ist wichtig am Anfang bewusst Fehler machen zu dürfen, um die ganzen Vorteile von Branches sehr schätzen zu lernen.

@GIT Repo Server

Verwendet ein Webbasiertes Repo wie Github. Es gibt einige Open Source Tools wie Gitlab, die lokal installiert werden können.
Ich bevorzuge hier Gitea oder Forgejo welche ein Fork von Gitlab.
Außerdem sind diese auch auf einer POWER Architektur unter Linux installierbar. Ich persönlich verwende am liebsten eine simple Linux VM auf X86 Basis für alles was außerhalb der IBM i ist. Da gibt es weniger Probleme mit Kompatibilitäten.
Forgejo hat auch keine bereiche wo dann doch noch Lizenzkosten anfallen, deshalb ist dieser meine Empfehlung wenn man hier Kosten sparen möchte.

Die Verwaltung und Handhabung der Repos geht hiermit viel besser und ist somit Pflicht!


@Abhängigkeiten & Automatisierte Builds

Ich hab ein Open Source Projekt (OBI) für diesen Punkt entwickelt, welches auch als Extension im VSCode Verfügbar ist.
https://marketplace.visualstudio.com...eas-prouza.obi
Ziel: Wenn ich eine PF, LF, DSPF, SRVPGM etc. ändere, sollen automatisch alle abhängige Objekte mit umgewandelt werden und das mit den richtigen Befehlen in der richtigen Reihenfolge.
D.h. der Developer soll sich nicht mehr darum kümmern müssen.

@Source Beschreibungstexte

Diese sind mit OBI ebenfalls weiterhin vorhanden. (Siehe Bilder im Link oben)

@Cloud Development

Heute gibt es viel zu viele Abhängigkeiten am lokalen PC:
* Netzwerk verbindung zuden Servern (FW etc.)
* Installation diverser Software (Java, Git, Python, vscode, extensions usw.)
* uvm.

Es entsteht also viel Aufwand PCs der Entwickler einzurichten.
Dafür gibt es ebenfalls ein freies Tools wie z.B. Coder (coder.com), das hier einem Unterstützt die Entwicklung zu zentralisieren:
https://github.com/andreas-prouza/blog/issues/8

@Deployment

Hierfür habe ich ebenfalls ein Open Source Projekt i-Releaser (https://github.com/andreas-prouza/i-releaser).
Ist ein Workflow System.
Du musst also die Steps definieren und die Tasks die er in jedem Step auszuführen hat.

Ich hoffe das hilft weiter. Lass es mich wissen wenn du mal nähere Infos oder Unterstützung benötigst.
lg Andreas

[dschroeder]

Hallo Malte,
ich finde das Thema "Umstieg auf IFS" hochspannend. Wir überlegen auch immer mehr, ob wir den Schritt gehen sollten. Es sieht ja so aus, als sei zukünftig VSCode für IBM die IDE der Wahl.

Git ist für uns bisher kein Grund, umzusteigen. Unsere selbstgeschriebene Versionierung reicht uns zur Zeit aus. Die Frage, die wir uns immer stellen, ist, ab wann die Vorteile der Umstellung die Nachteile und den Umstellungsaufwand überwiegen.

Deshalb hätte ich mal ein paar Fragen an dich (gerne auch an andere Teilnehmer):

1. Mit wie vielen Programmen hantiert ein Entwickler bei euch so am Tag? Könnt ihr das gut filtern? (Bei uns sind es meistens so viele Programme, dass nur die Programmnamen nicht reichen. Ich filtere sehr viel über den Beschreibungstext des Members.)
2. Habt ihr größere Copy-Strecken, die ihr einbinden müsst? (Bei uns sind alle Datenstrukturen, die zwischen Programmen als Parameter hin- und her gereicht werden, in einer sehr großen Copy-Strecke. Wir überlegen, das dann auseinander zunehmen und die Strukturen als einzelne Files im IFS zu speichern)
3. Wenn ihr mit Git arbeiten wollt: Würde es wirklich funktionieren, mehrere Branches zu machen, in denen ein Source dann mehrfachen Änderungen unterworfen ist? Kann es wirklich klappen, so etwas automatisch zu mergen? (Ich kann mir das einfach nicht so recht vorstellen).
4. Falls ihr umstellt: Mit welchem Schritt würdet ihr anfangen?
5. Welcher Zeitaufwand für die Gesamtumstellung erscheint euch akzeptabel?

LG, Dieter