Built in Funktion %SPLIT

[Hubert]

Guten Morgen,

in der RPG Referenz wird die built in Funktion %SPLIT beschrieben:

%SPLIT (Split String into Substrings)
%SPLIT(string {: separators })
%SPLIT splits a string into an array of substrings. It returns a temporary array of the substrings.

Wenn ich die aber verwenden will, meckert der Compiler:

098500     texte = %split(tdaten:';');                                         
======>            aaaaaa       bccc                                           
*RNF0604 20 a      098500  Das Token ist ungültig; das Token wird ignoriert.   
*RNF0312 20 b      098500  Rechte runde Klammer erwartet, aber nicht gefunden. 
*RNF5377 20 c      098500  Ende des Ausdrucks erwartet.

Was passiert da?

Herzlichen Dank im Voraus für Eure Unterstützung

Hubert

[Andreas_Prouza]

Hi Hubert,

hast du das entsprechende PTF installiert?

7.3: PTF SI76098
7.4: PTF SI76099


lg Andreas

[B.Hauser]

Erste Frage! Seid Ihr auf dem aktuellen Release und habt Ihr auch die entsprechenden PTFs geladen.
Für die Funktionen %SPLIT, %UPPER, %LOWER ist ein Runtime PTF erforderlich!

RPG Cafe: New built-ins %LOWER, %UPPER, and %SPLIT

[RXG4NWS2021]

Frage : wie hält man denn da seine Sourcen zusammen ? Oder geht man davon aus,alles immer auf dem gleichen Zielsystem und gleichen Release / Patchlevel ?

VG Rainer

[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.