RDi STRG+Space

[dschroeder]

Ich habe dein Fehlerprotokoll gerade mal einem Kollegen aus unserem Java Team gezeigt. Er kannte den Fehler. Der Fehler tritt sporadisch auf, wenn bestimmte Vergleiche in Java wegen eines Hashwertes schiefgehen. Genauer kann ich das nicht erklären.
Wie dem auch sei, es gibt einen Workaround (sagt mein Kollege):

Man muss die eclipse.ini anpassen. Bei mir steht die im Pfad: C:\Program Files\IBM\SDP
Du musst natürlich gucken, wo genau die bei dir steht.

Dort muss folgende Zeile eingetragen werden:

-Djava.util.Arrays.useLegacyMergeSort=true

Ich würde die Zeile einfach ganz hinten in die ini-Datei schreiben. Die Zeile muss auf jeden Fall irgendwo unterhalb von
-vmargs kommen.

Danach muss RDi natürlich neu gestartet werden.

Die Zeile sorgt wohl dafür, dass irgendeine neuere Sortierfunktion (TIM...) noch mit altem Java klarkommt oder so ähnlich.

Grundsätzlich handelt es sich um einen Programmierfehler im RDi, der aber in Java scheinbar öfter vorkommt und mit dem workaround behoben werden kann.

Du kannst es ja mal probieren.

[Fuerchau]

Ich bin Dienstag wieder bei dem Kunden und werde dann berichten.

[Fuerchau]

So, ich habe die Zeile mal ergänzt. Bisher sieht es erstmal gut aus.
Ich werde auf jeden Fall berichten.

[Fuerchau]

So, hier ist der SQL zum Testen:



// daten laden
exec sql
Declare SEARCHTEXT Cursor for
SELECT B.SYTEXTKEY, B.SYTXTDESCRIPTION
FROM sytbltxd1p a
join sytbltxh1p b
on b.recid=a.did
WHERE 1 = case when :pSuchstring = ' ' then 1
when :pSuchstring <> ' '
and locate( lower(:SearchString) , lower(SYTEXTVALUE) ) > 0 then 1
else 0
end
GROUP BY B.SYTEXTKEY, B.SYTXTDESCRIPTION
order by 1
;


Im Spoolerlisting ist das ">" nach der Locate()-Funktion auf Stelle 80.
Dies führt bei *LVL2 auf V7R2 zum Fehler.

Ggf. könnt ihr mir ja mal so den aktuellen PTF-Stand mitteilen, denn auf dem Kundensystem sieht das so nach Anfang 2017, also quasi mit Installationd er Maschine, aus.

Da in diesem Thread leider 2 Themen gemischt sind, zu diesem Problem nun die Erfolgsmeldung.
Am WE wurde der letzte CUM-Stand aktualisiert, nun funktioniert auch *LVL2-Compilierung.

Und wieder mal ein "Hoch" auf das Forum. Vielen Dank, Leute.

[Fuerchau]

Zum LVL2-Problem gibt es doch noch keine endgültige Lösung.
Nun haben wir zwar aktuelle PTF's, jedoch lassen sich so manche "Alt"-ILE's nun mit LVL2 nicht mehr wandeln.
Da wird vom SQL-Precompiler plötzlich "where nicht erwartet, zulässig sind ..."-Meldung erzeugt.
Ohne LVL2 wird das Programm fehlerlos erstellt.

Da soll noch mal einer die IBM verstehen.

[dschroeder]

Ich weiß, dass wir vor einigen Jahren auch mit RPGPPOPT(*LVL2) Probleme hatten. Inzwischen geht das bei uns aber problemlos.

Keine Ahnung, ob die Info hilft:
Bei uns werden die SQLRPGLE-Programme mit RPGPPOPT(*LVL2) gewandelt. "Normale" RPGLE Programme bekommen diese Information nicht mit.

Ich meine, mich erinnern zu können, dass es bei Copy-Strecken auch einen Unterschied macht, ob die mit /COPY oder /INCLUDE eingebunden wurden. Das hatte auch etwas mit *LVL2 zu tun, glaube ich.

[Fuerchau]

Das hängt mit dem SQL-Precompiler zusammen.
Copy kann der auflösen, jedoch nicht geschachtelt (gibts eine Fehlermeldung).
Include wird von SQL ignoriert.
Dies führt dann bei Like-Definitionen zu Problemen, wenn diese auf Include's basieren.

Dies alles löst *LVL2 auf, da eben Copy/Include aufgelöst werden bevor der SQL-Precompiler aktiv wird.
Und genau deshalb verstehe ich nicht, dass ein und dieselbe Quelle vom SQL-Precompiler ohne *LVL2 einwandfrei compiliert wird aber bei *LVL2 bei einem simplen "Select bla from file where ..." dann scheitert.
Die erstellte Pre-Quelle kann man sich ja sehr schön in QTEMP ansehen.