View Full Version : Kann man Sourcefiles im IFS speichern und die Texte behalten?
andreaspr@aon.at
18-05-16, 15:45
Außer Syntax-Gedöhns gibts ja funktional wirklich keine Erweiterungen die nicht auch mit PDM erreichbar wären.
Das Hauptproblem des RDi sind die diversen Versionen und man kann ja wohl nur eine Installieren.
Wir brauchen da aber nicht näher darauf herumreiten.
Nur noch als Ergänzung zu den Lizenzen:
Die Lizenzen sind nicht mit dem Server gebunden. Du installierst es dir einfach auf deinen PC und importierst auch im RDi dann den Lizenzkey (jar File).
Auf dem Server müssen lediglich diverse 5770WDS Lizenzprogramme installiert sein damit die Kommunikation klappt.
Ich habe auch schon mit der vorherigen Version des RDi auf die neue IBM i 7.3er zugreifen können.
Genauso kann ich mit meiner aktuellen Version auch auf ältere Systeme zugreifen (solange die Lizenzprogramme installiert sind, was jedoch meistens der Falls ist).
Als ich damals auf diversen Kunden-Systemen mit diversen Releases gearbeitet habe, gab es nie ein Problem. Allerdings alles 5.4 und aufwärts.
Auf 5.2 musste ich schon lange nicht mehr arbeiten ... Gott seis gedankt :)
OK, ein Fall gab es schon, aber da war einfach das Subsystem QUSRSYS nicht gestartet.
dschroeder
18-05-16, 15:46
Noch eines: Du kannst RDi ja einfach bei IBM herunterladen und für einige Zeit testen. Nach Ende der Testphase funktioniert es dann einfach nicht mehr. Ist aus meiner Sicht risikolos.
Hallo,
den meisten würde ich nicht empfehlen, den Quelltext im IFS abzuspeichern. IBM unterstützt noch nicht komplett Quelltexte im IFS. Für RPG und CL Programme ist das okay. Die Compile Befehle unterstützen hier IFS Sourcen. Für Binder Source sieht es dann wieder schlecht aus. Genauso wie bei Bildschirm- und Druckerdateien. Hier bekommt man das nur über einen Hack hin, indem man die Quelltexte temporär in Datenbankquelldateien speichert. Für den produktiven Einsatz in der Entwicklung nicht wirklich schön. Also lieber die Finger von weglassen.
... und was ist das für ein Qua..... mit einer Prozedur pro Serviceprogramm???? Ein Modul pro Serviceprogramm könnte ich noch verstehen, aber eine Prozedur pro Serviceprogramm?!?!??! Das macht aus mehreren Gründen schon keinen Sinn. Alleine die Verwaltung der Module ... das bläht sich doch dermassen auf, das ist doch ein Verwaltungshorror (... ausser ihr schreibt so gut wie keine Prozeduren in Serviceprogrammen, aber dann stellen sich gleich noch ganz andere Fragen.... ).
... und lange Dateinamen im IFS sind schön, aber man muss bedenken, dass die Module, Programme und Serviceprogramme wieder kurze Namen brauchen. Auch nicht schön.
Fazit: Das Konzept Quelltexte im IFS ist für den RPG/CL Entwickler nicht rund und scheinbar legt IBM auch keinen Wert darauf (da hat sich in den vergangenen Jahren/Releases nix getan).
Meine 2 Cent.
Mihael
... und was ist das für ein Qua..... mit einer Prozedur pro Serviceprogramm????
Mihael
... das kann man doch wieder ausgleichen, indem man mehrere Programme zu einem zusammenpackt mit einer generischen Schnittstelle und einem zusätzlichen Parameter Action und über letzteren dann steuert, welche Funktion ausgeführt wird. Da kommen die Russen lange nicht dahinter, warum man seine Programme mit CRTSRVPGM und seine Serviceprogramme mit CRTPGM umwandelt...
D*B
"eine Prozedur pro Serviceprogramm" ist auch Perfomance-Suboptimal.
Je externen Verweis auf ein Programmobjekt (egal ob Service oder nicht), verwaltet ein Programm einen sog. "Systempointer". Dieser wird beim Laden eines Programmes initialisiert.
Schlägt der Init fehl, kommt es allerdings erst zur Laufzeit zu einem Laufzeitfehler.
Je mehr Systempointer ich nun habe, desto länger die Ladezeit beim Erstaufruf da jedes Objekt über die LIBL gesucht werden muss, was zugegeben auch ziehmlich schnell ist.
Bei INLR = *ON oder MAIN-Programmen werden die Verweise ja wieder aufgehoben.
Warum führt das System wohl über das interne Systemobjekt QINSEPT eine Verweisliste auf alle möglichen Runtime-Module?
Die Compiler generieren da nämlich Aufrufe wie "call Ptr(4711)..." um die Initialisierungen zusparen.
... das kann man doch wieder ausgleichen, indem man mehrere Programme zu einem zusammenpackt mit einer generischen Schnittstelle und einem zusätzlichen Parameter Action und über letzteren dann steuert, welche Funktion ausgeführt wird. Da kommen die Russen lange nicht dahinter, warum man seine Programme mit CRTSRVPGM und seine Serviceprogramme mit CRTPGM umwandelt...
D*B
ATOMROFL =)
Danke!!! Du hast meinen Tag gerettet. =) =D
BTW: .... schon mal etwas tiefer in das JTOpen Projekt eingetaucht. Da findest Du genau diese Methodik wieder. brrrr..... alleine bei dem Gedanken schüttelt es mich.
BTW: .... schon mal etwas tiefer in das JTOpen Projekt eingetaucht. Da findest Du genau diese Methodik wieder. brrrr..... alleine bei dem Gedanken schüttelt es mich.
... zum lachen finde ich das nicht, da fällt mir als gottlosem Ungläubigen eher Lukas 22 62 ein
... zum lachen finde ich das nicht, da fällt mir als gottlosem Ungläubigen eher Lukas 22 62 ein
Gut das es für Ungläubige wie mich einen Herr Google gibt, 22-62 übersetzen kann ;-)
dschroeder
19-05-16, 10:21
Zu dem Thema "nur eine exportierte Procedure pro Serviceprogramm" habe ich mich schon des öfteren geäußert. Das läuft bei uns sehr gut. Wir haben keinerlei Probleme, irgendwelche Module zu verwalten. Warum auch? Module interessieren uns gar nicht. Da gibt es nichts zu verwalten. Jedes Serviceprogramm wird in unser Binderverzeichnis eingetragen (geschieht automatisch durch unser Compile-Programm).
Wir haben keine Versionsprobleme mit Signaturen, da jedes Serviceprogramm nur für sich selbst verantwortlich ist. Einfacher geht es doch kaum.
Dass es performancemäßig suboptimal ist, kann sein. Das kann ich ja so nicht testen. Aber wir haben da keinen Performanceengpass.
Unser Compile-Programm füllt bei jedem Kompiliervorgang auch gleich unser eigenes Repository, sodass wir ein komfortables Suchprogramm für die Suche nach bestimmten Programmen nutzen können.
Außerdem erzeugt unser Compile-Programm auch gleich den passenden Prototype für das umgewandelte Programm und legt den Verweis darauf ebenfalls in unserem Repository ab.
Als besonderes Feature haben uns unsere Java-Entwickler dann noch ein kleines Plugin für den LPEX Editor im RDi geschrieben. Das Plugin trägt automatisch alle benötigten Copy-Strecken für unsere Prototypes in den Sourcecode im LPEX Editor ein. (Es scannt einmal kurz den Source im Editor und holt die passenden Copy-Strecken Anweisungen dann aus dem Repository).
Fazit: Wir müssen eigentlich gar nichts mehr manuell tun, was mit Compiling oder der Unterscheidung zwischen Serviceprogrammen und normalen Programmen zu tun hat. Ich schreibe einfach ein Serviceprogramm und kompiliere es. Dann kann ich es in jedem anderen Programm benutzen. Fertig.
Dieter
In diesem Gesamtcontext wird da nun einiges klarer.
Bei den extrahierten Einzelaussagen kann es eben zu den schlimmsten Vermutungen kommen.