neue BIFS nutzen %UPPER

[Fuerchau]

Die Lizenzen benötigst du für die Compiler sowieso, der RDi ist, nach meinem Kenntnisstand, automatisch dann dabei.

[Andreas_Prouza]

Das der RDi automatisch dabei wäre ist mir neu. Wenn die IBM in letzter Zeit nicht etwas geändert hat, muss für jeden User eine Lizenz erworben werden.
Und CMS Systeme wie MDCMS, CMOne & Co kosten auch nicht wenig.

[Fuerchau]

Wahrscheinlich habe ich bisher immer nur mit "Einterprise"-Kunden zu tun gehabt, da ich noch nie eine Lizenz benötigt habe;-).
CMOne ist gar nicht so ohne, was die Funktionalität angeht.
Ich habe das bei einem Kunden kennengelernt und 2 Funktionen sprechen dafür, was ich im Git-Standard noch nicht entdeckt habe:

Das Stufenkonzept
Ich checke mehrere Quellen im Kontext der Aufgabe aus, nie das gesamte Projekt.
Dabei kann ich nur auchecken, was nicht in anderen Teilaufgaben ausgecheckt ist.
Diese werden in meiner eigenen Umgebung dann geändert, ergänzt und getestet.

Soweit ich es erlebt habe, kann in Git jeder ein Projekt auschecken und beim EInchecken wird geprüft, in wie weit Quellen dann via Konfliktlösung gemerged werden müssen.

Dann gibts die "Hochstufung".
D.h., die ausgecheckten Quellen werden gebündelt in eine "Form" gepackt, die dann in die nächste Ebene hochgestuft werden. Dabei werden alle abhängigen Quellen der nächsten Stufe automatisch als "Recompile" mit in diese Form eingetragen.
Anschließend kann ich diese Form freigegeben, wobei dann noch geprüft wird, in wie weit die abhängigen Dateien, Tables, DSPF's nicht in laufenden Jobs in Verwendung sind.
Der Compile wird dann genau in der Reihenfolge der Abhängigkeiten durchgeführt: Dateien, Trigger, Indizes, Views, Services, Programme.
Diese Hochstufung, zumindest bei meinem Kunden, erfolgt in 3 Stufen, Test, Usertest, Freigabe.
Mit der Freigabe wird dann diese Form auf das Echstsystem gebeamt und in eine Queue gelegt.
Bei der Ausführung dieser Teilaufgabe wird zusätzlich (also neben der InUse-Prüfung) auch geprüft, ob vorherige Formen in der Queue u.U. vorher ausgeführt werden müssen, da sie z.T. dieselben Quellen umfasst.

Fazit:
Ich muss mich nur um das Auschecken und das Hochstufen kümmern, alles andere macht dann CMOne, natürlich für Geld.

Bei deinem OBI sehe ich nur ca. 1/3 des Konzepts:
Git als Source-Verwaltungs-System (mit dem man Single-Projekte gut managen kann, aber alles halt zusammen hängt, was in einem Projekt definiert ist). Multi-Use-Quellen in verschiedenen Projekten sind da nicht vorgesehen. Eine Prüfung, welcher User ein Projekt als lokale Kopie pflegt, gibts hier nicht.
Erst beim Hochladen (Commit) erfolgt die Konfliktprüfung, wobei jeder selber entscheiden kann, welche Änderungen denn bei Konflikten bestehen bleibt.

Verwaltung der IBM incl. der abhängigen Recompiles. Wobei ich da nicht weiß, in wie weit du dann die Quellen ermittelst, die zu recompilen sind, obwohl sie nicht Bestandteil des Projektes sind (Teilprojekt).

Wie aber sieht das in einer Umgebung aus, in der ich halt eine Entwicklungssystem habe, jeder User seine Entwicklungsumgebung, eine Enduser-Testumgebung und ein Zielsystem existiert?

[Andreas_Prouza]

Wahrscheinlich habe ich bisher immer nur mit "Einterprise"-Kunden zu tun gehabt, da ich noch nie eine Lizenz benötigt habe;-).

Ich meine, dass jeder Entwickler eine Lizenz benötigt. Du darfst dabei nicht Lizenzierung und Lizenzprüfung verwechseln.
Die technische Lizenzprüfung im RDi ist so gut wie gar nicht vorhanden. Es gibt lediglich eine dubiose jar Datei die einmal eingespielt werden muss.

Das Stufenkonzept
Ich checke mehrere Quellen im Kontext der Aufgabe aus, nie das gesamte Projekt.
Dabei kann ich nur auchecken, was nicht in anderen Teilaufgaben ausgecheckt ist.
Diese werden in meiner eigenen Umgebung dann geändert, ergänzt und getestet.

Hier sieht man, dass die Entwickler aus der IBM i Welt kommen und die IT Entwicklung der letzten 20 Jahre verschlafen haben.
Dies gab es vor rund 20 Jahren bereits (CVS).
Ja, GIT hat das aus gutem Grund nicht, denn das hatte viele Nachteile. (Kann man alles nachlesen)

Dann gibts die "Hochstufung".

Das ist lediglich ein Konzept wie man Objekte in unterschiedlichen Umgebungen ausrollen kann.
Wenn man mit GIT arbeitet kann man ähnliche Konzepte z.B. mit Hilfe von Branches und GitActions realisieren.
Ich habe auch ein Open Source Projekt für diesen Bereich entwickelt i-Releaser. Ein workflow basiertes Deployment-Tool. Hier könnte man z.B. auch JIRA integrieren für Genehmigung/Start usw.
Das alles kann man also auch einfach miteinander kombinieren oder austauschen.

Eine Prüfung, welcher User ein Projekt als lokale Kopie pflegt, gibts hier nicht.
Erst beim Hochladen (Commit) erfolgt die Konfliktprüfung, wobei jeder selber entscheiden kann, welche Änderungen denn bei Konflikten bestehen bleibt.

Du kannst mit Github/Gitlab/Gitea/Forgejo (letzteres mein Favourit) Berechtigungen für User setzen. (Sogar auch mit Active Directory verknüpfen).
Der Rest ist auch gewünscht so, siehe oben.

Verwaltung der IBM incl. der abhängigen Recompiles. Wobei ich da nicht weiß, in wie weit du dann die Quellen ermittelst, die zu recompilen sind, obwohl sie nicht Bestandteil des Projektes sind (Teilprojekt).

Hier ist für mich eher die Frage was man als "Teilprojekt" versteht. Wie gesagt, es gibt kein unnötiges "check-out".

Wie aber sieht das in einer Umgebung aus, in der ich halt eine Entwicklungssystem habe, jeder User seine Entwicklungsumgebung, eine Enduser-Testumgebung und ein Zielsystem existiert?

Im OBI kannst du mehrere Profile hinterlegen. Es gibt das "Haupt"-Profil welches die Basis bildet und fix im GIT-Projekt drinnen ist.
Jeder Entwickler kann dieses mit einem eigenen Profil überschreiben: eigene LIBL, Ziel-Lib (u.a auch Lib-Mapping) uvm.
Du kannst auch ein Profil für Dev-, Test- u. Prod-Umgebung definieren.

Ich habe mit CMOne und MDCMS bereits bei Kunden arbeiten (müssen).
Diese Tools waren der Grund warum ich OBI ins Leben gerufen habe.
Für jemandem der bis vor kurzem nur PDM kannte, mögen diese Tools ein großer Sprung sein.
Da ich auch seit über 15 Jahren in der Welt von GIT, Linux, Python, Java etc. arbeite, sehe ich den großen Spring nicht.
Vor 20 Jahren wäre das sicher "state of the art" gewesen.
Ich sehe auch keine Zukunftsperspektiven mit diesen Tools.
Beide Extensions für vscode sind sehr Fehleranfällig.
Und man ist darauf angewiesen welche Technologien der Herstelle in seinem Tool integrieren kann/will.

Wie gesagt, ich habe bereits einige Migrationsprojekte, da immer mehr die ganzen Vorteile der "neue Welt" mit GIT & Co erkennen.

K.I. hab ich da ja noch gar nicht erwähnt.
Ein K.I. Entwickler-Team hat OBI geliebt, weil OBI alle Daten im JSON oder TOML speichert und K.I. dies optimal zum lernen verwenden kann.

Und wir stehen hier erst am Anfang ...

[camouflage]

Andreas,
das sehe ich auch so. Ich denke, es wird in den nächsten Jahren so oder so einen bedeutenden Umbruch geben. Persönlich stelle ich auch ein Fragezeichen hinter die Datenbanken. Einzig der Umstand, dass die bestehenden Lösungen noch unterhalten werden müssen, hält diese so hoch. Da gibt es innovativere Angebote. Ich gehe davon aus, dass KI massgeben helfen wird, neue Lösungen aufgrund neuer Ansätze innert nützlicher Zeit zu entwickeln. Was müssen wir uns dann über solche trivialen BIF Funktionen noch unterhalten müssen. Doch sind wir mittlerweile ziemlich vom Thema des TO abgewichen ...

[Andreas_Prouza]

Die IBM i ist auch heute noch ein geniales Konzept im Bereich OS (Sicherheit, Stabilität, Ressourcenverwaltung) und Relationale DB.
Es ist nicht die Frage: entweder/oder, sondern: wie kann ich das Beste aus verschiedenen Welten vereinen.
Im OS Bereich z.B. IBM i & Linux: IBM i Backend mit Linux für Frontend Entwicklung.
Damit habe ich IBM i Legacy Systeme mit modernen Frontends verbunden.
Da wir das Glück haben, dass die IBM i sehr abgekapselt aufgebaut ist, ist es einfach hier moderne Bausteine zu integrieren.
Viel einfacher als ich es bei den "modernen" Systemen habe.

Ich bin normal auch gegen Off-Topic, da es aber sonst hier nicht viel gibt, halten solche Diskussionen zumindest das ganze hier etwas mehr am Leben :-)

[Pikachu]

Was macht IBM i eigentlich so "Legacy" (ist es COBOL/RPG/DDS)?

Und was macht Linux so "Modern" (ist es Unix/Java/SQL/GPL)?

[Andreas_Prouza]

Mit Legacy habe ich im vor allem die SW gemeint, die auf der i Läuft.

Der Grund warum ich Linux für moderne Applikationen bevorzuge (wenn vorhanden, mit IBM i im Backend):

* Extrem hoher Support bei Technologien
Z.B.: wegen fehlenden Rust Kompiler auf der IBM i, kann ich vieles nicht verwenden. Den Request bei der IBM gibt es bereit.

* Sehr hohe Anpassungsfähigkeit. Linux wird z.B. bei allen verschiedenen Arten von Geräten (Handy, PC, Router, Switch, TV, Kühlschrank, IoT, ...)

* Nach IBM i ein stabiles, performantes und sicheres System.

[Pikachu]

Mit Legacy habe ich im vor allem die SW gemeint, die auf der i Läuft.

Ist Fix Form RPG "Legacy"? Oder sind da mehr Bildschirmdateien (DSPF) und Druckerdateien (PRTF) und Physische/Logische Dateien (PF/LF-DDS) ohne SQL und Java gemeint?

[Fuerchau]

Laut diesem Thread ist alles Legacy, was auf der IBM i entwickelt wird. Einzig die DB2 for i gilt demnach als modern.
Immerhin ist alles was die IBM tut um die IBM i am Leben zu halten Legacy.

Jedoch kann man durchaus auch mit Legacy moderne Anwendungen entwickeln.
C# basiert letztlich auf C++, ist also Legacy.
Visual Basic basiert auf Visual Basic (VB6 + VBA), ist also Legacy.
Phyton wurde im letzten Jahrhundert entwickilt, ist also Legacy, gilt aber heute als modern, nur weil man KI-Bibliotheken leicht aufrufen kann. Dies kann man aber i.W. mit jeder Sprache, denn letztlich werden auch nur Services aufgerufen.

Wenn man sich anschaut was als modern gilt
https://www.request-solutions.at/blo...ammiersprachen
sind dies alles i.W. Legacy-Sprachen mit ein paar neuen Syntaxerweiterungen.

SQL ist in den 1970ern entwickelt und nach und nach erweitert worden, könnte ebenso als Legacy bezeichnet werden.
NoSQL (Not only SQL) kommt auch noch aus dem letzte Jahrhundert.

Was also gilt da als Legacy oder modern?

Von der Technologiebasis her ist es egal mit was ich entwickle, das Ergebnis ist das was im Endeffekt zählt.

ILE (Integrated Language Environment) ist mit .Net vergleichbar. Auch da kann ich mit verschiedenen Sprachen entwickeln, so gar mit Powershell, das als Scriptsprache daherkommt aber .Net basiert ist.

Warum muss ich unbedingt auf Linux entwickeln wenn ich vom Ergebnis dasselbe mit ILERPG + SQL erreiche?
Ich kann auf Microsoft mit .Net ebenso für Linux, Android, IOS entwickeln, da ist man heute komplett frei.
Wobei C# und Net-Framework bereits Anfang des Jahrhunderts gebaut wurde. Ist das deshalb moderner?
Warum sich die IBM allerdings weigert, den .Net-Port auf die IBM i durchzuführen entzieht sich mir. Schießlich hats ja mit den anderen Systemen auch funktioniert.

Modern sind Funktionen, also das was man mit den Legacyumgebungen erstellt. Nur weil man es auf Linux/Windows entwickelt ist ILERPG auf der IBM deshalb schlechter?

Und was für Linux gilt, gilt auch für Android.

[Andreas_Prouza]

Da wird hier ja gleich Kraut und Rüben übereinander geworfen.
Ich glaube gibt leichte Unterschiede was man unter Legacy versteht.
DDS ist für mich definitiv Legacy. Fix Form RPG auch.

Wenn ich komplexere JSON, TOML oder XML erzeuge/einlese, will ich das mit einer einzigen Zeile code können. Max. 2 Zeilen, wenn ich noch ein import/include benötige.
Dynamische Listen & Dictionaries usw. das gleiche

Ich verwende auch SQL mit RPG um JSON zu generieren oder zu lesen, weil ich nicht mitten in einem RPG Prozess auf eine andere Sprache ausweichen möchte.
Web-Services & Web-Applikationen aber würde ich heute nicht mit RPG schreiben.

Ich bin genauso IBM i Enwickler und entwickle sehr viel im RPG mit Service Programme & Co.
Für Backend-Prozesse perfekt!

Alles neue geht fast ausschließlich ins Web. Dementsprechend bevorzuge ich für solche Entwicklungen Sprachen und Umgebungen, die dies sehr stark untersütz.
Was das Thema MS betrifft (Windows, .Net, VBA) können wir tatsächlich gerne einen neuen Thread starten.