ILE Quellen IFS vs Source Files

[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

[Malte]

Hi Andreas,

ich habe jetzt die CopySrc im IFS auch geändert dann habe ich keine Probleme mehr aber wenn ich die CopySrc auf den SrcFile drinn lasse klappt es nicht

[Fuerchau]

Ja, der Compiler hat ein Problem mit Misch-CCSID's.
Bei Standard-CCSID's in SRC-PF's wird i.d.R. jede Quelle, da es ja eine Datenbank-Tabelle ist, in die Job-CCSID umgewandelt. Bei IFS macht er das halt nicht per Default, da das ja ansonsten eine Datenbank-Standard-Funktion ist und eine IFS-Datei nicht in einer DB liegt.

Ich frage mich bei UTF8 halt nur, ob Textkonstanten in der Quelle mit Sonderzeichen wie Umlauten nicht automatisch dann auch als UTF8 im Objekt abgelegt wird.
Da Konstanten im Objekt allerdings keiner Codewandlung unterliegen, ist da u.U. Chaos vorprogrammiert.
1208 könnte also eine schlechte Wahl sein. Wenn man keine Sonderzeichen, außer vielleicht Kommentare in der Quelle hat, reicht auch 1252 für Windows-ANSI.
Allerdings sollte man CCSID-abhängige Konstanten sowieso immer aus einer Datei laden;-).

[BenderD]

... ich denke mal, der Compiler hat bei Unicode auch Probleme mit Knast (#) und Co (andere invariante Zeichen im EBCDIC). Für mich ist das alles letztlich nicht zu Ende gedachter Murks.
D*B

[Andreas_Prouza]

wenn ich die CopySrc auf den SrcFile drinn lasse klappt es nicht

Was schreibt das Spool/Joblog?