Übertragen von Sourcen und Objekten auf eine andere iSeries

[dschroeder]

Hallo,
wir möchten Sourcen und Objekte von unserer Hauptmaschine auf eine Testmaschine übertragen. Wir haben unseren Programm- und Datenbestand einmalig bereits per Band auf die Testmaschine übertragen. Jetzt möchten wir alle Programmänderungen, die wir auf der Hauptmaschine vornehmen, zeitnah auf der anderen Maschine nachziehen. Wir stellen uns vor, dass unser Wandlungsprogramm jedes Programm, das erfolgreich kompiliert wurde, an die andere Maschine überträgt.

Was würdet ihr vorschlagen? Ist FTP die einzige Möglichkeit?
Früher haben wir so ähnliche Dinge gemacht, indem wir eine DDMF für Sourcen eingerichtet haben. Nach der Übertragung eines Source musste dann auf der Zielmaschine gewandelt werden. Jetzt würden wir lieber gleich das Objekt übertragen.

Dieter

[Robi]

Moin,

Ich würd mir überlegen ob ich das 'immer' bei erfolgreicher UW mache!
Warum kopierst du, bei erfolgreicher UW das Objekt nicht einfach in eine transfer Lib
(und ggf die Source, dann aber die "/Copy" Abends gemäß Änderungsdatum auch mitnehmen! )

Die Tranfer Lib wird Abends / Morgens mit FTP rübergeschoben und geleert.
Jeder erfolgreiche Umwandlung wäre mir zu viel overhead

Robi

[dschroeder]

Danke für die Anregung.

Aber wir möchten unser Testsystem "live" aktuell halten. Wenn ein User einen Fehler findet, möchten wir den sofort beheben und nicht erst am nächsten Tag eine verbesserte Version haben. Den Overhead sehe ich im Moment nicht. Wir würden einen automatisierten Transfer nach der Wandlung per SBMJOB starten. Dann dauert das Wandeln nicht länger.

Dieter

[BenderD]

SAVRSTOBJ ?
(laber wg. 20 Stellen)

[dschroeder]

Das klingt so, als würden wir genau das brauchen. Wir schauen uns das mal an.

Vielen Dank!

Dieter

[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