Kann man Sourcefiles im IFS speichern und die Texte behalten?

[Fuerchau]

Ob RDI dir das dann abnimmt glaube ich eher nicht.
Auch ein Sourceverwaltungstool nimmt dir sowas nicht ab.
In "modernen" Umgebungen sprechen die Dateinamen für sich.
Oder warum glaubst du, kann man nun Namen bis 4K verwenden (das hat mit 4K-UHD nichts zu tun) und ist an die 80 Spalten nicht mehr gebunden?
Was soll denn die C++/.NET/Java/u.v.m.-Fraktion sagen, die solche Attribute noch nie hatten?

Wenn du sowas vorhast musst du ja auch alle Copy-Bezüge auf IFS-Verweise anpassen.
Dann kannst du auch gleich die Dateinamen aus dem Text entnehmen. Den Programm/Modulnamen spezifizierst du dann in den H-Bestimmungen mit "DFTNAME(rpg_name)", bzw. alternativ per "CTL-OPT DFTNAME(rpg_name);".

Willkommen in der "modernen" Welt.

[holgerscherer]

In "modernen" Umgebungen sprechen die Dateinamen für sich.
Oder warum glaubst du, kann man nun Namen bis 4K verwenden (das hat mit 4K-UHD nichts zu tun) und ist an die 80 Spalten nicht mehr gebunden?...

Willkommen in der "modernen" Welt.

ein sehr schwaches Argument, die Dateinamen für sich sprechen zu lassen. Da kann man ja noch einfacher mehr Unübersicht schaffen
Aber das ist ein Glaubenskrieg, den niemand gewinnen kann; ebenso wie die Frage, warum bei Dateinamen grossKLEIN unterschieden werden muss.

-h

[Pikachu]

Wenn du die Quellen mit dem Befehl CPY ins IFS kopiert hast, kamen die Beschreibungstexte mit. Leider kann man sie fast nur mit dem Befehl WRKLNK sehen. Näheres siehe: Handling extended attributes in the integrated file system

[dschroeder]

Vielen Dank für die Antworten. Ich wollte einfach mal wissen, ob jemand weiß, wie IBM sich das denkt. Klar, in Java z.B. sind die Objekt- und Methodennamen sprechend. Das geht sicherlich, wenn man das alles von vornherein darauf auslegt. Außerdem beherrschen Entwicklungsumgebungen wie Java ja auch Refactoring. Wahrscheinlich ist es dann relativ einfach, einen Namen an allen Stellen zu ändern.

Das Umstellen bestehender RPG Programme kann ich mir so nicht vorstellen. Es kann sich ja auch mal die Bedeutung eines Programmes etwas ändern. Dann kann man den Text aktualisieren und den nichtssagenden Programmnamen beibehalten.

Um mich nicht misszuverstehen: Längere Programm- und Objektnamen hätte ich sehr gerne auf der iSeries. Gerade bei unseren Serviceprogramme ist es störend, dass der exportierte, meistens sehr lange Procedurename nicht dem Membernamen entspricht. (Wir exportieren immer nur eine Procedure je Programm).

Aber ich sehe noch nicht so richtig, wie IBM sich das vorstellt. Also große Applikationen ins IFS zu bringen. Ich denke, da muss dann eine Zusatzsoftware her, die einem die gleichen Verwaltungsmöglichkeiten bietet, wie jetzt PDM.

Oder habe ich jetzt einen von euch missverstanden? Wenn ja, bitte nochmal antworten.

Herzlichen Dank.

Dieter

[andreaspr@aon.at]

Ich bin mir nicht sicher ob es sich lohnt "Altlasten" ins IFS zu übertragen (Kosten/Nutzen).
Macht eventuell mehr Sinn bei neuen Aufgaben.

[dschroeder]

Ich bin mir nicht sicher ob es sich lohnt "Altlasten" ins IFS zu übertragen (Kosten/Nutzen).
Macht eventuell mehr Sinn bei neuen Aufgaben.

Das ist ja genau die Frage. Wenn es ganz neue und unabhängige Aufgaben sind, würden die bei uns wahrscheinlich gleich in Java programmiert. Solange PDM bleibt, habe ich auch kein Problem mit dem jetzigen Ablagesystem für Sourcen.

[Fuerchau]

Wie die IBM denkt weiß wohl sowieso kaum einer.
Bei Orion denke ich auch eher an Dietmar Schönherr und Cliff McLane.
Wenn man dann endlich auf der Seite ankommt so sieht das dann aus wie immer (Eclipse?) wobei dieser sich auf Java Script spezialisiert, also noch ein Produkt unter gaaanz vielen.
Und außer einem Codeeditor scheint es nicht viel mehr zu geben.
Da bringt ja Eclipse schon mehr mit.

Und wenn man schon bei ILERPG bleibt, wer braucht denn da wirklich RDi und Full-Freeform?
Außer Syntax-Gedöhns gibts ja funktional wirklich keine Erweiterungen die nicht auch mit PDM erreichbar wären.
Für andere Sprachen greife ich halt gerne auf Eclips und VisualStudio zu da es sowieso kaum was anderes gibt.

[andreaspr@aon.at]

Und wenn man schon bei ILERPG bleibt, wer braucht denn da wirklich RDi und Full-Freeform?
Außer Syntax-Gedöhns gibts ja funktional wirklich keine Erweiterungen die nicht auch mit PDM erreichbar wären.

... im Ernst jetzt??? (Ist nicht als Frage gemeint!)

@Dieter: Ich würde empfehlen die Sourcen weiter in SRC-PFs zu belassen. Ich persönlich glaube, wenn es den PDM irgendwann nicht mehr geben sollte, wird auch die Frage wo die Sourcen sein zu haben eine überflüssige sein.

[dschroeder]

Danke, ich sehe das genauso. Aber ich wollte einfach mal wissen, ob es etwas neues in der Sache gibt.

Und zum RDi: Ich weiß, dass Baldur Probleme mitv RDi hat, weil er sich immer wieder auf Kundensystem einwählt. Ich weiß nicht, wie schnell RDi dann ist.
Aber ich persönlich möchte auf RDi keinesfalls mehr verzichten. Ich glaube, dass das jeder so sehen würde. der RDi im Echteinsatz hat (und es beherrscht).

[Fuerchau]

Das Hauptproblem des RDi sind die diversen Versionen und man kann ja wohl nur eine Installieren.
Außerdem hat nicht jeder Kunde sowas im Einsatz bzw. lizensiert.
Und ehrlich gesagt habe ich RDi wirklich noch nie verwendet und von keinem Kunden als Voraussetzung erlebt. Ich lese hier halt immer nur was damit alles nicht geht und spare mir das.

[camouflage]

Vielleicht auch noch meinen Senf dazu.

Ich hab sogar 3 Versionen 2xRDi, 1xRBD, man verwendet einfach verschiedene Arbeitsbereiche.
Soll es mal ganz schnelle gehen, nehm ich den PDM - aber nur für bestehende Sourcen. Warum?
Weil ich die Member einfach schneller finde und auch schneller editiere. Allerdings hab ich auch eine ganze Menge an Arbeitsbiliotheken, die ein "normaler" Anwender so nicht hat. Und Filter bis an's Ende der Welt mag ich auch nicht bauen.

Allerdings wenn's mit RPG an neue oder umfangreiche Applikationen geht, ohne RDi - no way! Gerade mit Free RPG gibts dazu nicht viele Alternativen. Und ja, es stimmt auch - man kann sich über RDi auch gewaltig ärgern.

[andreaspr@aon.at]

Das Hauptproblem des RDi sind die diversen Versionen und man kann ja wohl nur eine Installieren.
Außerdem hat nicht jeder Kunde sowas im Einsatz bzw. lizensiert.
Und ehrlich gesagt habe ich RDi wirklich noch nie verwendet und von keinem Kunden als Voraussetzung erlebt. Ich lese hier halt immer nur was damit alles nicht geht und spare mir das.

Wenn du sagst, dass du den RDi noch nie verwendet hast, aber dennoch Behauptungen aufstellst die schlichtweg falsch sind, dann spricht das nicht für deine Glaubwürdigkeit!
Nur so als Tipp am Rande.

Die Lizenzen für den RDi sind auch je Arbeitsplatz zugeordnet und nicht je Server.
D.h. selbst wenn es ein Kunde lizensiert hat heißt es noch lange nicht, dass du die Lizenz automatisch auch hast.

Und wie auch camouflage schon schrieb, RDi ist Eclipse basierend und auch im Eclipse kannst du verschiedenste Versionen haben.
Ich habe zwar auch die letzten 2 Versionen installiert (da z.B. ein PlugIn mit der neuen Eclipse Version nicht mehr kompatible war). Ansonsten brauchst du normaler weise nicht verschiedene Versionen.