neue BIFS nutzen %UPPER

[camouflage]

Also die Suchfunktion über alle Quellen im RDi nebst Anzeige der gefundenen Quelle sowie die Zeile und dann anschließenden Klick in die Quelle finde ich schon sehr hilfreich.

Kann ich dir nicht zustimmen. PDM geht gleich der Editor auf (nix klicki klicki), ausserdem kann ich verschiedene Aktionen hinterlegen. Und mir reicht in der Regel eine Quelle. Den F5 nach Verlassen darf man halt nicht vergessen, das ist das kleinste Problem.

Doch wie gesagt, "It Depends" (nach IBM Slang)

[Andreas_Prouza]

Jetzt darf ich auch mal Schaum-Eier spielen ...
Über den PDM kannst du auch über mehrere Quellen auf einmal suchen: STRPDM --> 2 --> 25 bei allen gewünschten Quellen.

Ich habe Kunde mit klassisch tausenden von Sourcen. Alles im lokal am PC (sync via GIT) und arbeite mit VSCode zusammen mit der OBI Extension.
Es gibt nichts was schneller ist im Zugriff, bei der Suche oder sonst was.

Alles was eine aktive Verbindung zur IBM i benötigt ist anfällig für Verbindungsprobleme und langsam.

[Fuerchau]

Es sei denn, du kannst die Suchen per SQL oder mit einem Service von Remote auf der IBM durchführen.
Der RDi durchsucht die Quellen direkt auf der IBM und zeigt mir daher die Ergebnisse auch zügig an.
Welchen Service RDi verwendet, kann ich allerdings nicht sagen.
Es könnte sich auch um temporäre "Create Alias Qtemp.MyAlias for MyFile (Member)" handeln, da diese keine lange Zeit kosten.
Wenn ich Remote mit meinem tollen DSL (70/20) auf der IBM arbeite ist RDi immer noch schnell.
Wenn VSCODE allerdings jede Quelle erst downloaden muss, ist die Langsamkeit durchaus verständlich.

[Andreas_Prouza]

Genau das eben nicht.
Wie gesagt, ich arbeite mit GIT. D.h. ich habe bereits alle Sourcen lokal und lade deshalb auch gar nichts von der IBM i.
Ich brauche lediglich eine Verbindung, wenn ich Kompilieren will, ansonsten bin ich die ganze Zeit verbindungsfrei.

Ich habe lange mit RDi gearbeitet. Es gibt absolut nichts schnelleres als die Konstellation mit lokalen Sourcen.

Als ich letztens bei der Common (AT) das Konzept mit GIT & OBI vorgestellt hatte, bekam ich gleich danach einen Anruf von einem Unternehmen, welches RDi und ein bekanntes CMS im Einsatz haben und meinte, sie wussten gar nicht was heute alles möglich sei und gab zu, dass er erkennen musste noch in der Steinzeit zu arbeiten.

Wenn man bis dato im PDM (zu fuß) gearbeitet hat ist der RDi wie ein Fiat Punto. Auf jeden Fall besser.
Wenn ich aber auch einen Ford Mustang haben kann und das sogar ohne Lizenzkosten ...

[Dschainers]

Eigentlich war hier etwas ganz anderes gefragt.
Dies wurde bereits in den ersten 3 Posts erledigt.

[KingofKning]

Eigentlich war hier etwas ganz anderes gefragt.
Dies wurde bereits in den ersten 3 Posts erledigt.

Ja, hast Du recht, aber ich finde es immer mal wieder interessant was es alles so gibt.

GG 1882

[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 :-)