SQLRPGLE, Free-Format und Umlaute in Kommentaren mit C-Karte

[Wittmann Benjamin]

Hi *ALL,
ich bin gerade über einen Umwandlungsfehler gestolpert und habe keine logische Erklärung dafür.

Hintergrund: Wir sind seit längerem dabei unsere Programmierung vom klassischen Spaltenorientierten RPG auf Free-Format (nur C-Karte, kein komplett Free) umzustellen. Da alte Programme nicht vollständig überarbeitet werden, wenn in ihnen Ergänzungen eingebaut werden, kommt es vor, dass gelegentlich Mischmasch zwischen beiden Codierungen in diesen Programmen vorkommt.

Ich habe in einem solchen Programm ein Embedded-SQL (dementsprechend den Source von RPGLE auf SQLRPGLE geändert) und einige Zeilen Free-Format ergänzt und erhalte jetzt die folgende Fehlermeldung vom SQL-Precompiler:

SQL0007  20      20  Position 28 Zeichen 'ü' (HEX X'D0') in SQL-Anweisung nicht gültig.

Die Meldung scheint auf den ersten Augenblick klar, aber als ich die fehlerhafte Stelle gesucht habe bin ich darüber gestolpert, dass es gar nichts mit dem SQL-Statement zu tun hat.
Ich habe das gesamte Programm zerlegt und habe folgende Konstellation ermittelt, die den Fehler auslöst:

  // Free-Format Zeile
  Write Satzformat;
C* Ein Kommentar mit ü

Versucht man diese zwei Zeilen Code mit CRTSQLRPGI umzuwandeln wird die obige Fehlermeldung erzeugt.
Ich habe spaßeshalber verschiedene C-Zeilen, mal mit, mal ohne Kommentar-* eingefügt, der Compilerfehler trat weiterhin auf. Nur wenn ich zwischen den Free-Format Write und die Kommentarzeile z.B. FeldA = FeldB; in Free-Format schreibe, funktioniert es wieder. Ebenfalls geholfen hat es, als ich statt C* einen Free-Format Kommentar mit // draus gemacht hatte.

Nachdem ich jetzt eine halbe Seite Erklärung geschrieben habe, hier nun meine eigentliche Frage:
Mache ich hier etwas falsch, ich war der Meinung, dass es kein Problem ist FREE-Format (ohne /FREE und /END-FREE) und klassische Codierung, übertrieben gesagt „kreuz und quer“, zu mischen? Ich hab mich auch bei Google umgesehen, aber außer einem PTF für V5R4M0 von August 2016 hab ich nichts gefunden, was irgendwie mit dem Fehler zusammen passt. Oder ist das eventuell ein Problem vom SQL-Precompiler selbst?

Vielleicht habt ihr eine Idee, es ist kein dramatischer Fehler, aber trotzdem nervig, wenn man erstmal seine SQL-Statements und Änderungen nach dem mysteriösen Umlaut absucht, der in Wirklichkeit in irgendeinem Kommentar von 199x steht

Mit freundlichen Grüßen,
Benjamin

[Fuerchau]

Das ist ein Fehler des SQL-Precompilers.
Aber wo in deinem Beispiel ist denn da die SQL-Anweisung?
Der Codeausschnitt ist dafür mal zu klein.

[Wittmann Benjamin]

Hallo Herr Fürchau,

danke für die schnelle Antwort.
Die SQL-Anweisung hatte ich nicht mit in dem Codeschnipsel, da der Pre-Compiler den SQL0007 immer wirft, egal ob irgendwo im Programm eine SQL-Anweisung vor den zwei Zeilen steht oder danach (oder gar keine SQL-Anweisung im Programm vorhanden ist).
Die SQL-Anweisung selbst ist soweit fehlerfrei (ein einfacher Select-Into) und funktioniert. Wenn ich die C*-Zeile entferne, lässt sich das Programm fehlerfrei kompilieren.

Also auch die Varianten:

  exec sql select Feld into :felda from Datei where EindeutigeBedingung;
  write satzformat;                                 
C* Ein Kommentar mit ü

bzw.

  write satzformat;                                 
C* Ein Kommentar mit ü    
  exec sql select Feld into :felda from Datei where EindeutigeBedingung;

Führen zu dem SQL0007, nur wenn das "ü" in der C*-Zeile entfernt wird, wird der Fehler nicht mehr erzeugt. Mit meinem Codeschnipsel aus dem ersten Post wird nur zusätzlich noch eine Warnung vom Pre-Compiler erzeugt, dass das Programm keine SQL-Anweisungen enthält.

Ich bin wie gesagt nur unsicher, ob das ein Fehler von meiner Seite ist, weil ich Free-Format und spaltenorientiertes Format auf eine Art mische, die u.U. nicht korrekt ist oder ob es ein "echter" Fehler im Pre-Compiler ist, der von IBM korrigiert werden müsste (oder schon behoben ist und mir nur ein PTF fehlt).

[Pikachu]

Das wird dieser Fehler sein, behoben durch PTF SI25530 (V5R4).

[Fuerchau]

In neueren Releases sollte das längst kein Thema mehr sein.
Prüfe mal die CCSID des Jobs zur Compilezeit.
Falls *HEX (65535) setze mal 273.
Bei fehlender CCSID kann es schon mal zu Ungereimtheiten kommen.
Man sollte Umwandlungen nie ohne CCSID machen.