Built in Funktion %SPLIT

[Andreas_Prouza]

Hi Rainer, was genau meinst du mit "zusammenhalten"?
Beim Programmieren kommt es darauf an ...
* ob man ein Produkt entwickelt, dass auf verschiedenen Systemen mit unterschiedlichen Releases läuft
* welches IBM i Release ich als Minimum vorgebe bzw. vorgegeben bekomme.
* wenn ich für das eigene Unternehmen entwickle, dann muss ich nur auf die eigenen Server Rücksicht nehmen.

Früher hat es öfters neue Releases gegeben.
Das hat die IBM dann irgendwann mal geändert und viele neuen Features einfach in PTFs ("Patches") verpackt (Stichwort: Technology Refresh).
Der Grund: Ein PTF im System einzuspielen ist einfacher als ein ganzes Release Update.
Wobei ein Release Update selten mit großem Aufwand oder großer Überraschung verbunden ist.

[Hubert]

Herzlichen Dank,

das PTF ist in der Tat nicht installiert. Werde ich mich drum kümmern müssen.

Viele Grüße
Hubert

[RXG4NWS2021]

Hallo Andreas,
solange ich auf meiner eigenen Entwicklerinsel bin, mag das irgendwie handelbar sein: solange man richtig dokumentiert...
Spannend wird's , wenn man später dazukommt oder die Software warten / migrieren soll.

Alternativ: man kann alles kapseln und subclassen - spricht einen abstraction layer einziehen -( macht aber auch Arbeit ).
Ich für meinem Teil ( Automotive world, dort gibts Regelwerke warum wieso und warum -Misra, Aspice , und das BMS des Konzerns- ) habs so gelöst, das alles in einer Software verwaltet wird, die das in einer Datenbank speichert.

VG Rainer

[B.Hauser]

Rainer,
vielleicht ist es Dir noch nicht bekannt, die IBM i Objekte sind aufwärts compatibel. Bei einem neuen PTF (Program Temporary Fix) oder Release-Wechsel müssen die Objekte nicht angefasst werden.
Aktuell laufen auf der IBM i auf dem aktuellen Release mit dem letzten PTF-Stand Programme, die das letzte Mal Ende der 80ger umgewandelt wurden.
Solange Du auf Deinem Release-Stand entwickelst brauchst Du Dich um nichts weiter zu kümmern. Neuerungen kannst Du natürlich erst verwenden, wenn das entsprechende Release mit dem aktuellen PTF installiert ist. Halbjährlich gibt es einen größeren Technology Refresh, bei dem die Neuerungen/Erweiterungen über PTF ausgeliefert werden.

Problematischer wird es, wenn die Software an Kunden gegeben werden soll, die einen niedereren Releasestand haben. Das ist jedoch i.d.R. bekannt und dann werden die Programme genau auf dieses Release gewandelt. Wenn man jetzt etwas verwendet, das in dem Ziel-Release noch nicht vorhanden war, wird das Programm oder Modul nicht umgewandelt.
Deshalb können Softwarehäuser immer als letzte die neuen Features nutzen, weil auf die Kunden mit älteren Release-Ständen Rücksicht genommen werden muss.

Ansonsten kapselt man alles in einer oder mehreren Bibliotheken.

Außerdem gibt es auch auf der IBM i Change Management Systeme.

[Fuerchau]

Das ist auch häufiger das Problem, dass man auf den Kundenmaschinen direkt entwickeln muss.
Im Betriebssystem muss man die Prev-Compiler der vorherigen Versionen haben um downgraden zu können.
Aber auch das ist nur meistens bis max. 2 Versionen möglich.
Z.B. V7R4 => V7R2.
Für V7R1 oder gar noch früher gehts halt nicht mehr.
Man kann sich da nicht auch noch mehrere Maschinen / Partitionen vorhalten.

Was dann sourcekompatibel ist merkt man dann beim Kunden.
Allerdings haben die meisten (meiner) Kunden auch Compiler.

[RXG4NWS2021]

Immerhin, in meiner alten Welt, besteht das BuildScript dann nur noch aus IFDEFs
- Da dreht sich dann der Releasemanager um, und weint bitterlich -

VG Raner

[BenderD]

... das Problem dabei sind ja die Varianten, die dabei entstehen, die dann später zu Inkompatibilitäten führen. Das ist aber im AS/400 Umfeld auch nicht besser. Da sind es aber meistens die Kundenspezifischen Anpassungen in schwach modularisierter Software und nicht die "neuen" Features, Das Gros der Software ist eh' noch auf dem Stand der 90er Jahre oder oft deutlich älter.

D*B

[RXG4NWS2021]

Solange es sauber dokumentiert ist, ist die Welt in Ordnung. Aber wehe wenn die Personen, die sich auskennen weg sind.

[Fuerchau]

Nun, ich habe mir mal sagen lassen:
Nur im Source-Code findet man die wahre Funktionsweise.
Wenn da dann noch ein paar verständliche Hinweise hinterlegt sind...

[RXG4NWS2021]

Naja, zur not kann man ja die ganzen Sourcen einsammeln und ein Script drüber laufen lassen.
Vielleicht ist sowas ja auch bei RDI dabei.
Ich hatte mal ein Projekt, da wurden meine Codeänderugnen nach einem Review in ein dickes Buch eingetragen. Und wenn man sich die Hochwasserbilder anschaut, nutzt auch Papier und Datensicherungsraum nix.

VG Rainer

[camouflage]

Solange noch S/36 Anwendungen im Einsatz sind, wundert mich eh nichts mehr. Das ist, glaube nur auf, sage ich jetzt bewusst, auf einer AS400 möglich. Es sind jedoch auch zuweilen die Softies daran Schuld, welche die Releases nicht nachführen, in der Angst den Kunden zu verlieren. Ein wenig Konsequenz wäre nicht schlecht.

Wie heisst so ein berühmter Spruch: "Nichts muss, alles kann".
Oh Mann!

Just my 2cts.

[RXG4NWS2021]

Genau. Ironie des Schicksal : war mal Softwareentwickler, dann kam das Thema Integration auf.
Und jeder Entwickler hat mir erzählt, das Binary bau ich mir selber, wozu ein Integrator.
Die Zeiten haben sich ( zumindest in Automotive ) gewandelt. Es wird sehr viel Geld in Tools investiert, um das Thema in eine gewisse Richtung zu treiben, und permanent zu auditieren.

VG Rainer