View Full Version : ILE Quellen IFS vs Source Files
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.
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.
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 ?
Eventuell kommen Quellenart und Text der Quellenteildateien beim Kopieren ins IFS nicht mit!?
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/items?itemName=HalcyonTechLtd.code-for-ibmi
https://marketplace.visualstudio.com/items?itemName=HalcyonTechLtd.ibm-i-development-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.
@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
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).
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.
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.
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.