View Full Version : Program sourcen kopieren von AS/400 nach AS/400 aber altes Release
camouflage
20-11-24, 13:20
Ganz sicher nicht, real 7.5 und auch kein chgcmdft für den savlib. Es hat halt keine kompilierten Objekte drin, sondern nur Dateien.
Andreas_Prouza
20-11-24, 14:15
Über IFS habe ich das nur via GiT (o.ä.) und Inhaltsvergleiche. Wobei eben letztere nur 2 Dateien vergleichen und mir Unterschiede anzeigen. Schwieriger wirds dann, wann welche Änderung im Einzelnen genau gemacht wurde. Da hab ich im Git nur eine History-Übersicht.
Wenn GIT im Einsatz ist, sehe ich für jede Zeile wann, wer, was (und warum) geändert hat.
Jedes Commit hat ja auch ein Datum dabei ;-)
Außerdem sehe ich auch die gelöschten Zeilen.
Wenn ich, im Laufe der Jahre, 100e commits habe, wirds schon etwas mühsam;-).
Andreas_Prouza
20-11-24, 15:48
Dafür gibt es ja IDEs. Im vscode oder auch RDi kannst du dir für jede Code Zeile den letzten Commit anzeigen lassen.
Im vscode ist das schon so integriert, dass dies automatisch passiert, wenn du mit der Maus über die Zeile fährst.
Man muss ja auch nicht die gesamte techn. Gebrauchsanleitung des Motors lesen um ein Auto starten zu können ;-)
Verstehe ich nicht. Warum machst Du keinen Save der Dateien, Objekte gehen ja nicht da von 7.4 ist max. 7.2 möglich. Erstelle eine savf und dann per ftp verschieben.
Probiers doch selber mal aus. Das mit den möglichen Werten beim Parameter TGTRLS beim SAVOBJ usw. macht da ja wirklich keinen Sinn, ist aber leider so.
Leute, das war doch schon immer so! Die IBM-Befehle unterstützen nur 3 Release, das aktuelle und die beiden vorhergehenden! Also wenn das aktuelle Release7.5 ist ist das niederste Release 7.2. Wenn das aktuelle Release 7.4 ist, dann ist das niederste 7.1.
Das haben wir doch früher schon so gemacht! Für das niederste Release gesichert auf einem anderen System mit niedererem Release zurückgesichert und dann erneut mit dem niedersten Release gesichert.
Fragt nicht, wie oft ich in meiner Anfangszeit zur IBM nach Frankfurt geschickt wurde, um Bibliotheken "umsetzen" zu lassen.
Bei einem Zip oder Jar ist das ja zum Glück anders. Und unter OS/400 V4R5 ging‘s auch zurück bis V3R2. Warum muß das überhaupt sein? Programme erhalten doch ihr eigenes Ziel-Release beim Wandeln. Also warum muß man beim SAVLIB/SAVOBJ/SAVDLO/SAV überhaupt ein Ziel-Release angeben? Weil wir das schon immer so gemacht haben? Bei einem Zip oder Jar ja wohl nicht!?
Ggf. hat IBM das für Files stillschweigend etwas erleichtert, da sich da an der Objektstruktur seltener was ändert.
Bei SQL-Tables und Views kann es etwas anders aussehen, aber die Erstellbefehle sind im Objekt gespeichert (DSPFD) und der Restore könnte diese also recompilen.
Bei Programmobjekten, incl. Services, werden die internen MI-Abbilder beim Restore u.U. recompiled.
Wenn neuere Funktionen (e.g. %xxx) verwendet wurden, dann scheitert die Erstellung und das Objekt wird nicht restored, da die Referenzen auf Servicemodule/-funktionen ja nicht gefunden werden.
Bestimmte Softwarelieferanten machen auch gerne einen RMVOBS, damit wird das Objekt-Template für Recompile dann entfernt, was beim Restore dann halt fehlt und dieser erfolglos bleibt.
Hier könnte bereits der SAVOBJ/-LIB scheitern, wenn der Recompile bereits beim Sichern stattfindet.
Aber das sind so die Geheimnisse der IBM;-).
Leute, das war doch schon immer so! Die IBM-Befehle unterstützen nur 3 Release, das aktuelle und die beiden vorhergehenden! Also wenn das aktuelle Release7.5 ist ist das niederste Release 7.2. Wenn das aktuelle Release 7.4 ist, dann ist das niederste 7.1.
...
Du meinst bei Release 7.5 ist es 7.3
und bei 7.4 ist es 7.2
Du meinst bei Release 7.5 ist es 7.3
und bei 7.4 ist es 7.2
Wer rechnen kann ist klar im Vorteil