SQL Pgm nicht mehr wandelbar

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

[camouflage]

Sieht halt so aus, als wäre nicht mehr so Big Blue an einer konsequenteren Weiterentwicklung des RPG nicht mehr richtig interessiert. Häppchenweise ein wenig SQL oder ein BIFchen nachschieben, damit ja kein Unmut aufkommt, die Kuh muss ja noch nicht vom Eis. Wieviele von den "Weiterentwicklungen" der letzten Jahre werden wirklich genutzt?

[Robi]

@Baldur

Nein, das muss mit dem PTF gekommen sein.
Es hat sich nichts geändert.
Auch das Original in der Produktiv Umgebung ließ sich nicht mehr wandeln

[BenderD]

@Baldur

Nein, das muss mit dem PTF gekommen sein.
Es hat sich nichts geändert.
Auch das Original in der Produktiv Umgebung ließ sich nicht mehr wandeln

... der Fehler kommt immer wieder mal nach Releasewechsel/PTF, wird dann wieder behoben, bis dann wieder ein Schrott PTF kommt. Soweit ich mich erinnere, wird das ausgelöst von Dateifeldern, die direkt im DSPF verwendet werden, um sich Zuweisungen zu sparen (gleicher Name, gleicher Inhalt). Für numerische Felder gibt es dann Typabweichungen zwischen dem Dateifeld und dem DSPF und das DSPF Feld ist "nicht verwendbar".

D*B

[Robi]

In diesem Fall waren es 'dumme' Bildschirmfelder.
In der Datei heißen die anders.