SQL Pgm nicht mehr wandelbar

[Robi]

Moin und frohes neues ...

Ich habe hier ein SQLRPGLE Pgm, das sich plötzlich nicht mehr wandeln lässt und stehe komplett auf dem Schlauch.

Ich bekomme 2 Spool.
1. Diagnoseprüfung --> alles OK, höchste Fehler 00
2. CRTSQLRPGI: Hier wird ein Sql - Statement das 2 Felder holt bemängelt.
Die Zielfelder sind nicht definiert oder wegen Ursachencode 6 nicht verwendbar.

Beide Felder sind in der BS-Maske definiert
Ein DSPFFD auf die Maske (mit *libl) enthällt beide Felder.

Die Diagnoseprüfung zeigt nicht, welches DSPF verwendet wurde.
Da dieses Statement und diese BS-Felder seit 2020 im Pgm sind, und nix mit der versuchten Änderung zu tun haben, bin ich etwas ratlos.
Selbst wenn ein älteres DSPF verwendet würde, die felder sind so alt, das muß da schon drin sein. Sowohl im Batch als auch im Dialog bekomme ich diesen Fehler.

Ich habe z.Zt. keinen Ansatz wo ich suchen soll!

FYI:
Der Dienstleister des Kunden hat zum Jahreswechsel aktuelle PTF eingespielt.
Danach hatten wir Probleme, das ein ADDPFTRG andere Berechtigungen hatte.

V7R5

Danke

[B.Hauser]

Welcher Compile-Code (Message-Id) und was besagt Ursachencode 6?

Könnte es sein, dass in dem Programm Copy-Strecken enthalten sind?
Wenn ja, könnte es sein, dass die Option RPG-Vorprozessoroptionen (RPGPPOPT) im Compile-Befehl mit *NONE angegeben ist?

[Robi]

Hallo Birgitta,

die MsgId ist SQL0312
6 bedeute es ist eine Konstannte die nicht verwendet werden kann.

Beide Felder sind als O im DSPF definiert.

Die Source enthällt /Copy
RPGPPOPT wird auf *LVL2 gesetzt.

An den Umwandlungsroutinen hat sich 'ewig' nix geändert

Ich habe nicht einmal eine Idee, was ich noch ansehen kann.

[Robi]

Ich habe jetz mal über die qsys2/ptf_info nachgesehen ob es das Coverletter zu einem der PTF's gab.
Fehlanzeige.
Dann DÜRFTE ja eigendlich keine gravierende Änderung mit dem PTF gekommen sein.
Aber wie gesagt, ein täglich laufender Job ist nach den PTF's (mit IPL) auf Fehler gelaufen
weil ein ADDPFTRG plötzlich nicht mehr vom Systermuser ausgeführt werden durfte.
Hätte ich auch ne info im Coverletter erwartet.

[camouflage]

Q&D Workaround: Definiere doch mal die Felder nochmals in der RPG Source. Vielleicht hilft es.

[Robi]

Danke,

aber das habe ich, obwohl es mir zuwider ist, zuerst gemacht.

Unmittelbar vor dem /exec sql habe ich ein

move ' '   Feld1    1
move ' '   Feld2   20

selbe Fehler

[Robi]

so sieht das im Pgm aus.

Die definition der Felder im Code ist neu, die Felder sind im DSPF auch so definiert

[Robi]

Hammer ....

habe DAS hier im Forum gefunden. Von 2016

mache den SQL nun in 'Eigene' Variablen, die ich anschl. mit EVAL in die BS-Felder schiebe.

Umwandlung geht wieder!
Das war vor dem PTF kein Problem.

Danke für Eure Ideen

@Birgitta
eigendlich müsste ich das m.e. an IBM melden.
Das ist aber immer ein riesen Akt, da es über den Dienstleister des Kunden gehen müsste.
Ich mach da nix!

Robert

[BenderD]

... ich weiß schon, warum ich das seit (gefühlt) 1870 so mache - ich halte mir Probleme vom Hals, die ich nicht haben muss!
D*B

[Fuerchau]

Das geht in die selbe Richtung wie /Copy und /Include.
/Include wird vom Precompiler aus PF-SRC immer noch nicht aufgelöst.
/Copy kann trotz Copynest-Angabe vom SQL-Precompiler immer noch nicht geschachtelt werden, was mit /Include ja geht.
Wenn man die Vorumwandlungsoptionen *RPGLVL1/2 zum Auflösen der Include/Copy sowie Felddefinitionen verwendet, werden SQL's auf 80 Stellen abgeschnitten.
Der SQL-Procompiler bricht längere SQL's auf 80-Stellen um, nur die abgschnittenen führen auch wieder zu Fehlern.
Und ja, DS-Strukturen von Bildschirmen mit LikeRec werden vom SQL-Precompiler ebenso nicht aufgelöst, daher kennt er die Bildschirmvariablen nicht.
Alles nicht stringent.

Die Ursache obigen Fehlers kann auch sein, dass du die Quelle ggf. in ILERPG-Format umgewandelt hast (RDi oder CVTRPGSRC). Dann hast du den SQLRPGLE-Precompiler und mit dem SQLRPG-Precomplier hat das früher halt geklappt.