RDi STRG+Space

[Fuerchau]

Ich sagte ja, dass die Quellen an sich OK sind. Die temporären Quellen ebenso. Auch der Spool zeigte den SQL vollständig an.
Jedoch wurde der Case-Ausdruck bei *LVL2 als fehlerhaft abgewiesen weil er über 80 Stellen hinausgeht.
Wie immer das auch zusammenhängen mag.

[dschroeder]

OK, verstehe.

Ich weiß noch ziemlich sicher, dass wir ganz am Anfang von fully free (wir waren damals auf 7.1) das auch nicht zum Laufen bekommen haben, weil es Probleme mit den Sourcebreiten gab. Damals war ein PTF erforderlich. Später ist das dann mit neueren Releases direkt korrigiert worden. Ich meine, mit 7.2 waren auch PTFs erforderlich. Weil 7.2 am Anfang keine (großen) Unterschiede zu 7.1 hatte, aber für bestimmte Hardware erforderlich war.

Anders gesagt: Wenn dein Kunde mit weniger als 7.3 unterwegs ist, würde ich mal wegen der PTFs nachfragen.

[Fuerchau]

So, hier ist der SQL zum Testen:



// daten laden
exec sql
Declare SEARCHTEXT Cursor for
SELECT B.SYTEXTKEY, B.SYTXTDESCRIPTION
FROM sytbltxd1p a
join sytbltxh1p b
on b.recid=a.did
WHERE 1 = case when :pSuchstring = ' ' then 1
when :pSuchstring <> ' '
and locate( lower(:SearchString) , lower(SYTEXTVALUE) ) > 0 then 1
else 0
end
GROUP BY B.SYTEXTKEY, B.SYTXTDESCRIPTION
order by 1
;


Im Spoolerlisting ist das ">" nach der Locate()-Funktion auf Stelle 80.
Dies führt bei *LVL2 auf V7R2 zum Fehler.

Ggf. könnt ihr mir ja mal so den aktuellen PTF-Stand mitteilen, denn auf dem Kundensystem sieht das so nach Anfang 2017, also quasi mit Installationd er Maschine, aus.

[dschroeder]

Das SQL wird bei mir im SQLRPGLE problemlos kompiliert. Ich musste die Variablen Searchstring und psuchstring natürlich vorher noch deklarieren.

Das einzige Warnungsproblem bei mir ist, dass er die Spaltendefinition in den Tabellen nicht findet. Wir haben die Tabellen bei uns natürlich auch nicht.

Aber es gibt kein Kompilierproblem.

Unser Release ist V7R3 mit TR5.

Unsere PTF-Stand ist:


PTF-Status anzeigen
System
Produkt-ID . . . . . . . . . . . . . : 5770WDS
IPL-Quelle . . . . . . . . . . . . . : ##MACH#B
Release der Basisoption . . . . . . . : V7R3M0


Auswahl eingeben und Eingabetaste drücken.
5=PTF-Zusatzinformationen anzeigen 6=PTF-Begleitschreiben druc
8=PTF-Begleitschreiben anzeigen 10=PTF-Anlegeinformationen

Aus-
wahl PTF-ID Status IPL-Ak
SI68235 Temporär angelegt Keine
SI67823 Temporär angelegt Keine
SI67820 Temporär angelegt Keine
SI67717 Ersetzt Keine
SI67417 Temporär angelegt Keine
SI67185 Permanent angelegt Keine
SI67183 Temporär angelegt Keine


Noch eine Idee: Sind ALLE betroffenen Sourcefiles (also die des umzuwandelnden RPG-Programms als auch die der Include-Dateien) breit genug?
Es scheint so zu sein, dass die Basis-Sourcedatei die Breite der Temp-Sourcefile für den Compiler definiert. Wenn man dann breitere Includes einfügen will, hat man Probleme.

Ich kann dir echt nochmal folgenden Beitrag in diesem Forum ans Herz legen (Achtung: 2. Seite ist auch interessant!)
Umwandlung mit RPGPPOPT(*LVL2) (http://newsolutions.de/forum-systemi-as400-i5-iseries/threads/20827-Umwandlung-mit-RPGPPOPT(*LVL2)/page2)

[Fuerchau]

Danke für deinen Versuch.
Vielleicht erbarmt sich ja noch ein V7R2-Kandidat;-).

Der SQL stammt aus der Hauptquelle. Ich habe die Umwandlung im Dialog angeschmissen und konnte ja das Ergebnis der Tempfiles in QTEMP überprüfen.
Wie gesagt, der Spool zeigte den kompletten SQL aber den Fehler ab Spalte 80.

[dschroeder]

Wahrscheinlich ist genau das Problem im APAR SE63525 beschrieben.
http://www-01.ibm.com/support/docview.wss?uid=nas2SE63525

Dort steht auch, welches PTF für welche Version zur Behebung erforderlich ist:
PTFs Available
<tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;">R710 </tt><tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;">SI58914</tt> <tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;"> 6120
</tt><tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;">R720 </tt><tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;">SI58916</tt> <tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;"> 6127
</tt><tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;">R730 </tt><tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;">SI59847</tt> <tt style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; font-size: inherit; overflow-wrap: break-word;"> 6085</tt>

[Fuerchau]

Nein, dies kann es nicht sein, da die Quelle des RPG-Procompilers sauber erstellt wird.
Es fehlte nichts, es wurde nichts abgeschnitten.
Es werden ja nicht generell alle SQL's abgelehnt sondern nur SQL's mit einem CASE-Ausdruck.
Ich habe in einer Quelle einen SQL komplett so weit wie es ging nach rechts verschoben, er wurde problemlos compiliert.
Obiger SQL mit dem CASE-Ausdruck wurde jedoch ab Spalte 80 abgelehnt.
Dies ist aber Sache des SQL-Compilers und nicht des RPG-Precompilers für die Auflösung der Copy/Includes.

[Radinator]

Was bei mir z.B. auftritt ist das Problem, dass bei Subprocedures ich auf den (umbenannten) Recordnamen nicht zugreifen kann. Egal ob RPGLE/Free oder "normales" RPGLE. Außerdem wird mir, wenn ich mit dcl-s ein standalone Feld definiere diese im nachfolgenden Code nicht mit der Autocomplete Funktion angezeigt, bevor ich es nicht einmal verwendet habe. Sprich ich muss den Namen des Feldes mindestens einmal in der Subprozedur selber hingeschrieben haben, damit mir der Editor das Feld in der Autocomplete anzeigt. Ist bei kurzen Variablen nicht weiter tragisch, sind eh hingeschrieben, bevor ich überhaupt Strg+Space gedrückt und ausgewählt habe. Aber gerade bei längeren Variablen oder auch DS, die als likerec(recordformat) definiert sind und dessen Unterfeldern, ist das schon ein wenig nervig. Hatte dazu bereits auf developerworks einen REF Eintrag geschrieben (vor mehreren Monaten!). Bisher keine Antwort/Reaktion darauf.

[dschroeder]

Wenn du ein kleines Codebeispiel hast, was bei dir nicht geht, probiere ich gerne mal aus, ob das Autocomplete in meinem RDi geht.

Bei mir geht die Autocomplete Funktion meistens.

[Radinator]

Also ich hab hier mal ein Beispielprogramm:

DDS Source:


A R PFA002R
A
A FLD01 2S 0 COLHDG('FELD 01 ')
A FLD02 10A COLHDG('FELD 02 ')


Inhalt der Datei PFA002P:


*...+....1..
01Text 1
02Text 2
03Text 3
04Text 4
05Text 5
06Text 6
07Text 7
08Text 8
09Text 9
10Text 10


Und hier der Programmcode:



**free
ctl-opt decedit('0,') datedit(*dmy) dftactgrp(*no) option(*nodebugio:*srcstmt:*nounref);

dcl-pr GibText char(10);
$1id zoned(2) const;
end-pr;

dcl-s i int(3);
dcl-s text char(10);

text = *blanks;
i = 5;
text = GibText(i);
dsply text;

*inlr = *on;

// Subprozedur
dcl-proc GibText;
// Datei und Host-DS einbinden
dcl-f pfa002p disk usage(*input);
dcl-ds pfa002rDS likerec(pfa002r); // "pfa002r" wird im likerec auch nicht erkannt :(
// Prozedure-Interface
dcl-pi GibText char(10);
$1id zoned(2) const;
end-pi;
// Lokale Felder
dcl-s x1id like($1id); // $1id wurde bereits verwendet -> wird auch vorgeschlagen
dcl-s result like(pfa002rDS.fld02); // Teilweise wurde hier schon die Autocomplete verweigert
// Beginn der Programmlogik
x1id = $1id; // Muss selber tippen, da x1 noch nicht verwendet wurde
read pfa002r pfa002rDS; // Auch hier musste ich den Namen selber schreiben. Vorgeschlagen wird nur der Dateiname, nicht der Satzformatname
dow (not %eof(pfa002p));
if (pfa002rDS.fld01 = x1id); // Ab hier kannte RDi den Namen "pfa002rDS"
result = pfa002rDS.fld02;
leave;
endif;
read pfa002r pfa002rDS;
enddo;

return result;
end-proc;


Probier mal das ganze nachzustellen/nachzuschreiben. Vielleicht hast Du ja auch bei den Kommentierten Stellen das Problem.
So, wie das Programm oben aussieht (bzw eigentlich die Subprozedur "GibText", bau ich im Normalfall alle meine Unterprozeduren auf (Zuerst die Datei, dann Host-DS, PI, Lokale Felder und dann erst der Programmcode).