Übertragen von Sourcen und Objekten auf eine andere iSeries

[Robi]

Wenn im Testsystem jemand ein DSPF verwendet das du ersetzen willst bekommst du Probleme.
Ok, bin bei savrstobj nich ganz sicher ob das trotzdem geht, wandeln geht jedenfalls nicht, da IBM die QRPLOBJ Logik bei DSPF nicht macht.

Bei uns wird auf dem 'TEST' System auch entwickelt.

Je 'Projekt' ein Lib mit den Sourcen, + OBJ. Eine anständige Verwaltung drum herum und es ist möglich
die gleiche Source auch mal in mehreren Projekten gleichzeitig zu ändern. Ist nicht so toll, kommt aber vor und funktioniert mit etwas Aufwand auch gut.
Solltet ihr ähnlich arbeite nun du hier nur von 'sofort-korrekturen' direkt im Echtsystem sprechen,
vergiss nicht die Source(n) in den Projekten zu mischen!
Robi

[dschroeder]

Wenn im Testsystem jemand ein DSPF verwendet das du ersetzen willst bekommst du Probleme.
Ok, bin bei savrstobj nich ganz sicher ob das trotzdem geht, wandeln geht jedenfalls nicht, da IBM die QRPLOBJ Logik bei DSPF nicht macht.

Danke für den Hinweis. Das Ersetzen von DSPF macht nur bei den "alten" Green Screen Masken Lockprobleme. Masken, die wir neu entwickeln, werden fast ausschließlich mit ProfoundUI grafisch entwickelt. Das sind im Endeffekt zwar auch DSPF, aber das RPG-Programm hält keinen Lock auf so einer DSPF (Liegt wahrscheinlich an dem Verfahren mit dem Open Access Handler). Man kann die jederzeit austauschen.

Dieter

[hel400]

Dann wäre das von Hrn. Bender empfohlene SAVRST* ja absolut passend.

Ein kleiner Denkanstoß noch bzgl. der Hintergrundübertragung:
Ihr könntet das ja zB auch so machen, dass EIN zentraler Batchjob im Hintergrund das Auditjournal gezielt auf CREATEs durchliest und sobald ein Objekt in der/den zu überwachenden Bibliotheken erstellt wird, werden Src u. Obj auf die Testmaschine übertragen (nur mal so ein Gedanke)
Damit wäre sichergstellt, dass nichts übersehen/vergessen wird.

.. also quasi ein "Vision light" :-)

[dschroeder]

Gute Idee, danke. Ich weiß allerdings nicht, wie leicht so ein Journal auszulesen ist.
Mal sehen, ob wir das hinkriegen.

Dieter

[TheDevil]

Hallo.
Wäre nicht auch eine Spielgesoftware ala BUS400 eine Lösung. Dadruch habt ihr immer eine duplizierte Maschine mit dem aktuellsten Bestand. Wenn die Datenbestände z. b. nicht mit gezogen werden sollen kann man diese ja auch ausklammern. Aber vielleicht ist es auch eine Kostenfrage.
Gruß,
Ralf

[BenderD]

... da wäre RCVJRNE euer Freund, aber m.E. ist das Overkill, wenn man schon einen zentralen Compile hat, hängt man das da dran und gut ist. Wichtig ist da nur, dass der Transfer selber unkaputtbar ist (gilt aber auch für die JRN Variante).

[dschroeder]

Ja, das sehe ich genauso. Allerdings gilt unser zentraler Compile für nur für alles außer unserer ProfoundUI Display Files. Die werden direkt aus dem ProfoundUI Designer heraus erstellt. Da greift unser zentraler Compile nicht. Vielleicht müssen wir eine Lösung finden, solche Sourcen auch von unserem zentralen Compile aus zu erstellen. Technisch ist das Compile kein Problem. So eine Datei ist auch nur eine normale DSPF. Aber es gibt meiner Meinung nach keine Möglichkeit, den Compile aus Profound heraus anzustoßen. Ich werde da aber mal nachhaken.

Dieter

[Frank Hildebrandt]

Ein Change Management System ist dein Freund.

[dschroeder]

Vielen Dank an alle.
Wir sind im Moment erstmal auf der Suche nach einer kleinen Lösung ohne externe Software. Die käme ins Spiel, wenn wir grundsätzlich unsere Entwicklungsstrategie überdenken würden. Wir werden es jetzt wohl so machen, dass wir auch unsere Profound DSPFs über unser Wandlungsscript erzeugen. Damit müssten wir alles, was erfolgreich gewandelt ist, auf das 2. System übertragen können. Wir müssen allerdings noch etwas Konfigurationsarbeit leisten. Der von Dieter Bender empfohlene Befehl SAVRSTOBJ verlangt einen Parameter RMTLOCNAME. Das ist bei uns noch nicht eingerichtet. Eine IP-Adresse reicht da nicht aus. Wahrscheinlich müssen wir da einen Leitwegeintrag oder so erstellen. (Ist nicht gerade mein Fachgebiet). Und der Kollege aus dem Systembereich hat Urlaub :-(