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

[dschroeder]

Ich habe sogar noch den Beispielsource, den ich an IBM geschickt habe, um das Problem nachzuvollziehen. Das war genau so , wie du sagst: Sobal eine embedded SQL - Anweisung vorkam, egal wie trivial, gab es das Problem.

Vielleicht erinnere ich mich auch falsch und es hatte nichts mit der Breite, sondern mit der CCSID der Sourcedatei zu tun. Jedenfalls konnte IBM das Problem damals erst nicht nachvollziehen, weil ich das kurze Beispielprogramm einfach als txt-Datei geschickt hatte und IBM hat das dann in einen Editor kopiert. Da trat der Fehler bei IBM nicht auf. Erst als ich per SAVF den Source mit der Sourcefile geschickt habe, hatte IBM das gleiche Problem. Es hatte auf jedenfall etwas mit der Sourcefile zu tun.

Wenn du also einen Bug bei IBM aufmachst, solltest du ein kleines Beispielprogramm zur Verfügung stellen und komplett mit Sourcefile als SAVF zu IBM schicken.

Ich melde Software-Bugs meistens telefonisch unter:

IBM-Software-Support:
Hotline-Nr. 0800 / 5253553

(Wir haben allerdings einen entsprechenden Wartungsvertrag).

Dieter

[Dominic K.]

Ah super dann weis ich Bescheid wo ich das melden kann! Wartungsvertrag haben wir auch, meine ich, sollte alles klappen. Ich frage sonst nochmal meine Führungskraft sobald diese wieder verfügbar ist.

Danke noch einmal!

[dschroeder]

Ich denke, wenn du die Nummer anrufst, kann man dir gleich sagen, ob ihr einen passenden Wartungsvertrag habt. Du musst nur eure Kundennummer wissen. Ggf. reicht auch die Seriennummer eurer Maschine.

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