ILE Quellen IFS vs Source Files

[dschroeder]

Hallo Malte, hallo Andreas,

vielen Dank für eure Antworten.

1. Andreas schrieb, dass das Filtern kein Problem sei über bestimmte Tools. Mir geht es darum, ob ich das direkt aus der IDE (also dann aus dem VSCode machen kann). Zur Zeit arbeite ich mit RDi und unser "Haupt-Arbeitsgerät" ist die Objekttabelle im RDi. Da habe ich die Filter immer offen (bei einem großen Bildschirm kann man das gut machen) und kann da dann relativ schnell durch meine Sourcen navigieren. Unsere Sourcemember sind relativ klein. Aber dafür haben wir sehr viele Member.
Gibt es im VSCode bereits Filtermöglichkeiten, die ähnlich wie in der Objekttabelle des RDi sind?

2. Wir arbeiten viel mit iSphere. Die Suche ist sehr schnell und flexibel. Ich kann nach mehreren Begriffen suchen (auch negativ) und z.B. angeben, dass beide Begriffe in einer Zeile auftauchen müssen. Gibt es eine starke, schnelle Suchen auch im VSCode?

3. Bei uns umfassen Änderungsprojekte oft mehrere Member, die gleichzeitig angepasst werden müssen und miteinander korrespondieren müssen. Wenn ich Teile dieser Programmgruppe zusätzlich in anderen Branches habe, dann kann ich doch nicht so einfach mergen. Das kann ich mir kaum vorstellen. Vielleicht spricht die eine Änderung ein neues Feld in einer Bildschirmmaske an und die Änderung im anderen Branch benötigt ebenfalls ein (anderes) neues Feld in der Maske. Da muss das Ändern und Ausrollen doch extrem koordiniert ablaufen. Das kann einem Git doch nicht abnehmen. Oder verstehe ich da etwas falsch?

[Fuerchau]

Zu 1+2: Es gibt im VS eine Suche über alle Projektdateien, auch mit Mustervergleichen.
Dazu braucht man ein Masterprojekt, das dann auch Subprojekte enthalten kann, die dann alle durchsucht werden.
Am Beispiel eines ERP's habe ich ein Gesamtprojekt, das sich aber in Teilprojekte wie Auftragswesen, Bestellwesen u.v.m., aufteilen lässt, sowie einem weiteren Subprojekt für übergreifende Services.

Das Branch-Handling ist zugegeben sehr komplex, und bedarf natürlich einer gewissen Dispziplin.
Gehen wir von einem normalen Projekt aus, so kann jeder nur einzeln an einem Objekt arbeiten.
D.h., ich arbeite an ProgA mit DSPF A und ggf. weiteren Abhängikeiten, die das Programm betreffen.
Du kannst dann an ProgB arbeiten.

Gemeinsame Ressourcen wie die Datenbank (Tabellen, Views, Indexe, Trigger, Constraints, ...) werden je Objekt gezielt einzeln durchgeschossen, wie ich oben schon mal sagte, und könnten in einem eigenen Subprojekt liegen.

Mit Branches hat das noch nichts jzu tun.
Branches benötigt man für Releases des Gesamtprojektes, bzw. von Teilprojekten.
Dabei geht immer vom Kontext des Projekts und nicht der Objekte aus.

Wenn ich also ein Release V1 erstellt habe, das natürlich gestestet und stabil ist;-), kann ich das in einem Branch V1 fixieren.
Das aktuelle Projekt ist dann weiter das Entwicklungsprojekt.

Treten nun im freigegebenen V1 wider jeglicher Erwartung nun doch Fehler auf, dann behebe ich in V1 den Fehler, kann das dann in Echt als V1.1, ggf. als Branch, deployen.
Gemachte Ergänzungen merge ich dann ins aktuelle Projekt.

Jetzt habe ich also 3 Branches. An die Ableitungen V1, V1.1 arbeite ich erst mal nicht weiter.

Soweit nun die blanke Theorie.
Die Anzahl der Branches wird durch die Anzahl verschiedener Installationen bestimmt. Wenn die Version eines Branches nicht mehr installiert ist, kann ich diesen auch löschen.

Bei selbstprogrammierenden Anwendern reicht i.d.R die aktuelle Umgebung und genau 1 Branch der produktiven Umgebung um schnelle Korrekturen zu ermöglichen.

[Andreas_Prouza]

@1: Erstes Bild in der Doku von der vscode Extension https://marketplace.visualstudio.com...eas-prouza.obi

@2: vscode hat standardmäßig eine umfangreiche Source-Suche. Hat viele Möglichkeiten und auch Regex.

@3: Koordination ist nicht das wichtigste. Zu Verstehen wie Git funktioniert und wie man es sich für seine Bedürfnisse verwendet ist hier wichtiger.
Das gleiche Problem gibt es auch bei anderen Sprachen und funktioniert.
Am besten nimmt man sich jemandem (entweder intern oder extern) mit dem diese Themen z.B. als Workshop durchgegangen wird.

[dschroeder]

Vielen Dank für die Antworten.

Wenn ich mit einem kleinen Schritt anfangen möchte, bliebe mir doch nur, zunächst die IBM i Erweiterungen für VSCode zu installieren und zunächst mit den Sourcen in Teildateien weiter zu arbeiten, oder?

Jede andere Lösung, die die Sourcen im IFS verlangt, wäre ja ein Riesen-Break, der alle anderen IBM i Programmierer sofort beeinträchtigen würde. Meine Kollegen wollen sicherlich erstmal alle weiterhin mit RDi arbeiten.

[Fuerchau]

Ein Einstieg ist sicherlich einfacher als ein Umstieg.
Allerdings könnte der Einstieg in VS durchaus von Vorteil sein, denn RDi lässt ganz schön zu wünschen übrig. Ins besonders was das berühmte Intellisence angeht, das Autovervollständigen.
Unter bestimmten Bedingungen klappt das nämlich überhaupt nicht, da die Syntaxanalyse nicht erkennt, dass da u.U. Namen gepromptet werden müssen.
Bei qualified DS wird z.B. immer gleich der Name der DS als auch gleich aller Subnamen geprompted.
Wenn ich viele DS habe die in den erst 5 - 10 Buchstaben identisch sind, würde mir der DS-Name da reichen, denn nach dem Punkt könnte ich ja den 2. Prompt bekommen.
Da ist VS bestimmt besser und daher eben auch schneller. Denn beide, VS und RDi müssen die Datei ja sowieso lokal runter laden.

[Pikachu]

Wie empfiehlt IBM eigentlich die Quellen ins IFS zu umzuziehen und alles weitere?

[dschroeder]

Wie empfiehlt IBM eigentlich die Quellen ins IFS zu umzuziehen und alles weitere?

Das ist eine sehr gute Frage!

Ich habe darauf bei Vorträgen oder in direkten Gesprächen bisher unzureichende Antworten bekommen. Das alte Projekt BOB "Better Object Builder" (Bitte nicht verwechseln mit dem neuen KI-Projekt Bob!!) sollte das ermöglichen. Wenn ich nach Details gefragt habe, wie z.B. "wo bleiben denn die Source-Beschreibungstexte?" hieß es in etwa:
- Die meisten Programmierer sind nicht auf die Texte angewiesen
- Wenn mein Gesamtprojekt so groß ist, dass ich auf die Texte nicht verzichten kann, dann ist mein Gesamtprojekt eben nicht optimal.
=> Das hilft mir natürlich nicht weiter. Meine Gesamt-Anwendung ist eben so wie sie ist. Es nützt mir nichts, wenn man mir sagt, sie müsste kleinteiliger geschnitten sein.

[Andreas_Prouza]

Wenn ich nach Details gefragt habe, wie z.B. "wo bleiben denn die Source-Beschreibungstexte?" hieß es in etwa:
- Die meisten Programmierer sind nicht auf die Texte angewiesen
- Wenn mein Gesamtprojekt so groß ist, dass ich auf die Texte nicht verzichten kann, dann ist mein Gesamtprojekt eben nicht optimal.

Diese Aussagen und noch andere waren der Grund warum ich OBI ins Leben gerufen habe.
Leider heutzutage, wenn ein Tool eine Anforderung nicht erfüllen kann, ist automatisch die Anforderung falsch, ohne jegliche Reflexion ob die Anforderung eventuell sogar eine Bereicherung für das Tool wäre.

OBI ist nicht perfekt. Jedoch können Kundenwünsche schnell und unbürokratisch übernommen werden. Ich glaube sogar es war deine Aussage über die Source-Texte, die mich dazu veranlasst haben dieses Feature zu implementieren.

Was die (IBM) Empfehlungen betrifft ...
Für mich stellt sich die Frage: Möchte/Muss ich in den nächsten Jahren neue Entwickler ins Boot holen.
Wenn ja, welche Anforderungen sind nötig und wieviele Bewerber decken diese ab?
Mit IFS, Git und Vscode habe ich eine Basis mit der sich mehr Entwickler einfangen lassen, als mit SRC-PF & Co.

Nicht nur, dass ich mit diesem Weg mehr Möglichkeiten zur Integration diverser Tools habe (z.B. CI/CD), man wird auch interessanter für Unternehmen und eine Umschulung auf IBM i wäre einfacher zu Argumentieren.


Was das GIT MERGE betrifft, wie gesagt: Du kannst es einstellen wie du es haben möchtest. So auch ...
1. Entwickler A ändert Source ABC.RPG
2. Entwickler B ändert Source ABC.RPG
3. Entwickler A Commited seine Änderung und überträgt diese ins remote Git
4. Entwickler B Commited seine Änderung und möchte ebenfalls überträgen
4.a. Entwickler B bekommt von Git die Info, dass bereits Änderungen durchgeführt wurden und diese vorher übernommen werden müssen
4.b. Entwickler B sieht dann in einer Vergleichs-Ansicht seine Änderungen und die des Entwickler A
4.c. Entwickler B entscheidet welche Änderungen übernommen werden soll bzw. kann den Code in der Vergleichs-Ansicht auch direkt noch anpassen.
4.d. Wenn Entwickler B den MERGE abgeschlossen hat, Commited er den Merge und überträgt die Änderungen ins remote Git

Im Git ist nun alles transparent, wer was geändert und zusammengeführt (Merge) hat.

Arbeiten nun Entwickler A wochenlang an einer Source, die zwischenzeitlich von Entwickler B (wegen eines Hotfix) angepasst wurde, kann Entwickler A sich jederzeit die Änderungen von Entwickler B holen und mergen.
Somit muss Entwickler A nicht bis zur finalen Fertigstellung mit dem Merge warten.

Git kann noch viel mehr. Nicht alles wird benötigt. Dadurch ist Git DAS Versionsverwaltungs-Tool und wird in sehr vielen anderen Tools unterstützt. (JIRA, VSCode, Eclipse, Azure, Slack, Teams, Kubernetes, AWS)

[Pikachu]

In welche CCSID kopiert man die CL- und RPG-Quellen aus den Quellenteildateien am besten ins IFS?

[Andreas_Prouza]

Ich speichere sie alle als UTF-8 (ccsid 1208)

[Malte]

Was den GIT Merge Angeht habe ich bis jetzt hauptsächlich gute Erfahrungen gemacht.
Aber wenn du es mal ausprobieren willst kannst du in VScode auch einfach ein lokales GIT Repo erstellen und mal so einen Merge Conflict provozieren.

@Andreas_Prouza ich hatte das mit UTF-8 Probiert aber dann bekomme ich einen Fehler beim Compilern das 1208 nicht unterstützt wir. Muss ich hier noch was angeben beim "CRTBNDRPG"?
PS: ok googlen hilft...
Compile RPG from Unicode source - new TGTCCSID parameter in 7.1, 7.2, 7.3

PPS: Wenn ich das versuche bekomme ich diesen Fehler:
Umwandlung gestoppt. Interner Fehler aufgetreten. Fehlercode ist 1
1 - Fehler im Front-End des Umwandlungsprogramms aufgetreten.

Kann ich dann keine CoopyBooks meher verwenden mit anderer CCSID ?

[Andreas_Prouza]

Hi Malte,


Die Fehlermeldung sieht für mich wie ein Folgefehler aus. Schau mal ins Spool & Joblog.


Die Copy-Source muss ebenfalls die CCSID 1208 haben.
Im RPG musst du die Copy-Strecke auch anpassen.
Von: /copy qcpysrc,mysource
zu: /copy 'qcpysrc/mysource.rpgle'


Bei mir sieht der Build-Befehl so aus:


CRTRPGMOD MODULE(prouzalib/test1) SRCSTMF('src/prouzalib/qrpglesrc/test1.rpgle.pgm') DBGVIEW(*ALL) REPLACE(*YES) TGTCCSID(*JOB) INCDIR('./src/prouzalib')


Du könntest auch weiterhin die Copy-Sourcen aus den Src-Libs nehmen.
Mit beiden habe ich keine Probleme.


lg Andreas