SQL Pgm nicht mehr wandelbar

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

[Fuerchau]

Tja, da sieht man wieder, dass Laufzeitprüfungen nicht passieren und wenn man Datei-Felder nur umbenennt, gibts anscheinend keine Signaturänderung sonst würde man ja bereits beim Open auf die Nase fallen.

Ich bin auch schon des öfteren mal bei RGPIV reingefallen, vor allem was die Typsicherheit angeht.
In der PF ist ein Feld packed(11, 2) definert.
In der DSPF ist das Feld mit 11S 2 definiert.
Wird nun von der PF eine E DS definiert und beide Dateien verwendet, wird in der DS die 11S 2-Variante generiert.
Dem RPG ists egal, da bei den Verwendungen Zoned und Packed gemischt verwendet werden.
Ebenso werden ja auch Moves zwischen DS und File-Puffern generiert, die dann die Typumwandlung vornehmen.

Allerdings nicht beim CALL!
Das Empfangs-Unterprogramm hatte nur die PF am Wickel, somit war der Parameter mit packed(11, 2) definiert.
Beim CALL mit dem Feld aus obiger DS aber wurd nun Zoned(11, 2) übergeben.

Gott sei Dank hat sich das mit Prototypen erledigt. Wobei Strukturen da leider nur als CHAR(n) geprüft werden, nicht aber die Unterfelder.
Somit gibts keine Compilerfehler bei der Übergabe von DS's an DS CONST, es wird einfach eine Kopie der DS in der Länge des Ziels erstellt. Ob die DS überhaupt die Richtige ist, wird nicht geprüft.
Dasselbe gilt für Return-DS'n.