Nutzung von **free RPG und SQL Precompiler wirft Fehler?

[Fuerchau]

Wenn es sich tatsächlich um ein CCSID-Problem handelte prüfe mal, ob dein Umwandlungs-Job (Batch/Dialog) auch mit einer passenden CCSID gesetzt ist.
Es wird nämlich immer wieder gerne vergessen, dem Job eine andere CCSID als 65535 zu geben.
Dann muss der Compiler irgendeine CCSID verarbeiten und bestimmte Zeichen sind eben CCSID-abhängig und können dann falsch interpretiert werden.

[Dominic K.]

Ich konnte das Problem jetzt weiter eingrenzen und auch lösen. So müssen die SQL Statements aussehen:

EXEC SQL
                SELECT
                  CASE
                    WHEN apkflgnr > 49999999 THEN apkflgnr - 40000000 ELSE
                    apkflgnr
                  END
                  INTO :liegenschaftsnummer
                  FROM apkopfp
                  WHERE apkfaufnr = :auftragsnummer;

EXEC SQL
              SELECT COUNT(*)
                INTO :count
                FROM apkopfp
                JOIN apumstp ON
                  CASE
                    WHEN INT(SUBSTR(DIGITS(apkflgnr), 1, 3)) < 500
                      THEN INT(SUBSTR(DIGITS(apkflgnr), 1, 3))
                    ELSE INT(SUBSTR(DIGITS(apkflgnr), 1, 3)) - 400 END
                   = apumbezr
                WHERE apkfaufnr = :auftragsnummer;

Das ELSE und das END sind jeweils eine Zeile nach oben gerückt. Damit lässt es sich nun auch mit **free kompilieren. Ich habe zwar keinen Plan warum das nun klappt, eigentlich sollte das dem Precompiler ja egal sein wie viele Leerzeiche oder Enter dazwischen liegen da er das ja sowieso alles entfernt, oder?

@dschroeder: Deine genannten PTFs haben wir anscheinend noch nicht installiert, die werden wohl wenn ich das richtig verstanden habe erst in ein paar Monaten wenn wir 7.3 installieren in einem Cumtabe mitinstalliert.

Werde aber den Quellcode mal als SAVF mit einen Report an IBM geben vllt. können die ja genauer auskunft geben warum das END und ELSE da nicht sitzten darf.....

[Fuerchau]

Ggf. kann dein Precompiler noch nicht breiter als 72 Stellen und dein SQL war eben breiter.
Dies ist aber mit neueren Versionen/Releasen/PTF's schon behoben.

[Dominic K.]

Meine SQL Anweisungen sind nicht breiter als 72 Stellen, habe darauf geachtet weil dschroeder
oben bereits ja das gleiche angedeutet hatte. Wenn du dir die Statement noch einmal anschaust wirst du auch shehen das die Statements jetzt sogar noch breiter sind als vorher(aber noch kleiner als 72 Stellen), weil das END und ELSE ja in die Zeile darüber positioniert worden sind, damit sind beide Zeilen jetzt 4 Stellen breiter als vorher.

Interessant ist auch das wenn ich die die beiden ersten SQL Statements komplett kopiere und in eine neue Quellcodedatei übertrage sie auf anhieb funktionieren, auch mit **free und keinen Fehler auswerfen.
Kopiere ich diese gesamte Quelle in eine neue Teiledatei gibt es am wieder den gleichen Fehler.

Alles echt ein wenig seltsam.....

[dschroeder]

Kopierst du sie denn in die selbe Sourcedatei? (Also in dieselbe QRPGLESRC)?
Ganz blöde Frage: Deine Teildatei hat aber schon die Art "SQLRPGLE") ?

[Dominic K.]

Ja kopiere manuell mit Ctrl+C aus der alten Quelle in die neue und die neue Datei ist auch definitiv eine SQLRPGLE Datei : )

EDIT: Nein habe testweise in eine andere Sourcedatei kopiert, wieso?
EDIT2: Habe mal nachgeschaut die Sourcedateien haben die gleiche CCSID und auch sonst sind diese identisch, mal von Name und Größe ect. abgesehen

[dschroeder]

Was heißt "von Größe abgesehen"? Haben die Dateien eine unterschiedlichen Breite (also Satzlänge)?

[Dominic K.]

Nein Satzlänge ist mit 112 identisch, mit Größe meinte ich Spiechgröße usw. also Werte wo klar ist das die eh nicht identisch sein müssen.

[BenderD]

... da steht noch so ein Hex-Frickel, den Du durch die Else überklatschst.

D*B

[Dominic K.]

OK, wie hast du den gefunden?
Habe den Quellcode selber schon in Notepad++ gepackt und mir alle(auch die sonst nicht sichtbaren) Zeichen anzeigen lassen, konnte nicht auffälliges finden.

Ist den auch bei dem anderen SQL noch ein HEX Wert da, der Fehler taucht ja bei beiden Statements auf.

Hier auch sonst noch einmal das *SRVPGM: http://pastebin.com/3B4iPzi1
die auskommentieren Bereiche sind nicht wichtig, sind nur weg weil ihr das sonst nicht testen könnt. Hat keinen Einfluss auf die Fehler

[BenderD]

... suchen würde ich den mit DSPPFM und F10 - finden kann den hier bei diesem Ratespiel niemand, außer Dir selber.

D*B