Pgm läst sich nicht mehr wandeln, SQL0312

[dibe]

Guten Tag.
Am Wochenende haben wir alle *RPG* Programme neu gewandelt.
wengen verschedenen Dateierweiterungen schien uns das einfacher als die Pgmme gezielt zu suchen und zu wandeln.

Dabei konnten 2 Pgmme nicht gewandelt werden.
Lt Debug sind die Statements die memängelt werden in dem laufenden OBJ identisch.

Bemeckert werden diverse Felder die in einem Select into befüllt werden.
Diese Felder kommmen aus einer Datei.

Also
FDatei UF A E K DISK
...
select sum(feld1), Count(*) into Dateifeld3 :IND1, Dateifeld7 :IND2 from ...where ...

Der Fehler ist SQL0312, Variable Dateifeld3 (für Dateifeld7 auch) nicht definiert oder aufgrund Ursachencode 6 nicht verwendbar.

WAS hat sich WARUM (heimlich?) verändert?
Muß ich jetzt für jedes Dateifeld ein Arbeitsfeld definieren oder kann ich in der Umwandlung einen Parameter setzen?

Vielen Dank
Dietlinde Beck

[Fuerchau]

Der SQL-Precompiler hat sich da leider etwas geändert und kann auf bestimmte Eigenschaften nicht mehr zugreifen.
Das sind i.W. Variablen, die automatsiert erst durch I-Bestimmungen definiert werden.
Abhilfe hier kann eine Umwandlungsoption sein:
RPGPPOPT *LVL1 / *LVL2
Damit wird der Compiler angewiesen, erst mal alle externen Definitionen zu laden bevor der SQL-Precompiler zuschlägt.
Leider gibts das nur für ILERPG.
Bei Non-ILE hilft dann schon mal eine externe DS anzulegen, die die Felder dann definiert.

[dibe]

ok, danke
Die Datei ist als E DS EXTNAME(Datei) auch definiert.
Das Pgm ist ILE und RPGPPOPT steht auf (*LVL2)

[B.Hauser]

Reason Code 6 bei SQLCODE 312 bedeutet:
Die Variable ist eine Konstante und kann nicht geändert werden.

Ihr definiert also F-Bestimmungen, um Felder aus embedded SQL zu füllen und habt zusätzlich noch eine externe unqualifizierte Datenstruktur???
Nicht unbedingt die beste Lösung!

Alle Host-Variablen, die befüllt werden (unabhängig davon, ob es sich um Dateifelder handelt oder Variablen) müssen mit einem führenden Doppelpunkt angegeben werden, was in Deinem Beispiel nicht der Fall ist.
Das war eine Unsauberkeit, die schon immer dokumentiert war, aber früher (vor 5.1 oder so) funktioniert hat. Heute wird das geprüft und führt zu einem Fehler.

Warum braucht ihr die F-Bestimmungen überhaupt? Für zusätzlichen native I/O?
Wenn nein! Nimm die F-Bestimmungen raus!
Externe Datenstrukturen sind normalerweise im embedded SQL kein Problem, sofern man die Hostvariablen (Datenstruktur und/oder Unterfelder) mit einem führenden Doppelpunkt angibt.

Die Compile-Option *LVL2 braucht man i.Ü. bloß um verschachtelte Copy-Strecken in denen Variablen-Definitionen hinterlegt sind aufzulösen. Hat also mit Eurem Problem nichts zu tun.

[dibe]

der Fehlende : ist ein Tippfehler, sorry

Die E DS ist da drann, weil wir sehr häufig Sätze als Parameter transportieren
Dann müssen wir uns bei neuen Feldern nicht drum Kümmern welcher Aufruf angepasst werden muß und welcher nicht. einfach alles Wandeln und es passt wieder.
Einige fer Felder können (mit unseren) SQL kenntnissen nicht gefüllt werden
zum Schluß wird der Satz, Komplett auf verschiedene Arten gefüllt, geschrieben oder geändert

[Fuerchau]

Ich habe auch immer mal wieder Probleme, wenn Variablen als Parameter übergeben werden, die auf Like-Basis definiert werden. Eine unqualified DS als Übergabeparameter kann von SQL-Precompiler nicht mehr erkannt werden, der wurde diesbezüglich typsicherer gemacht.
In diesen Fällen musst du leider lokale Hilfsvariablen (ohne Like) definieren und dann der Struktur zuweisen.

[KM]

Hallo Dietlinde,

den Fehler hatte ich vor kurzem auch. Bei uns hat folgendes PTF geholfen:

https://www.ibm.com/mysupport/s/defe...language=en_US

Viele Grüße,
KM

[Fuerchau]

Die LVL-Optionen dienen natürlich zur Auflösung von Copy, vor allem jedoch zur Auflösung von Include.
Die SQL-Precompiler kann kein Include und lässt nur 1 Copy-Ebene zu.

Und ja, beim Lesen aus IFS ist das kein Problem denn da gibts ausschließlich Include und keine Copy, das ist jedoch keine Option da ich Member-Texte und vor allem auch die Datum-Spalte noch für gut befinde.

Unqualifizierte externe DS'n kommen noch aus der Pre-Qualified-Zeit und wenn man Programme nur auf Free durchschleift wird sich keiner die Mühe machen, die unqualifizierten auf qualified umzustellen, da der Änderungsaufwand z.T. sehr massiv werden kann.

Es kann auch sein, da die CONST-Prüfung verschärft wurde, dass eine DS als Parameter per Const an eine Prozedur übergeben wird und das Zielfeld innerhalb der Struktur nun auch als Const angenommen wird.
Der Hintergrund hierzu ist, dass eine Variable bei identischer Länge zwischen Quelle und Const-Ziel nicht mehr kopiert wird, da sie durch Const nun geschützt ist.