RDi STRG+Space

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

[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/docvie...id=nas2SE63525

Dort steht auch, welches PTF für welche Version zur Behebung erforderlich ist:
PTFs Available
R710 SI58914 6120
R720 SI58916 6127
R730 SI59847 6085

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

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

Da in diesem Thread leider 2 Themen gemischt sind, zu diesem Problem nun die Erfolgsmeldung.
Am WE wurde der letzte CUM-Stand aktualisiert, nun funktioniert auch *LVL2-Compilierung.

Und wieder mal ein "Hoch" auf das Forum. Vielen Dank, Leute.

[Fuerchau]

Zum LVL2-Problem gibt es doch noch keine endgültige Lösung.
Nun haben wir zwar aktuelle PTF's, jedoch lassen sich so manche "Alt"-ILE's nun mit LVL2 nicht mehr wandeln.
Da wird vom SQL-Precompiler plötzlich "where nicht erwartet, zulässig sind ..."-Meldung erzeugt.
Ohne LVL2 wird das Programm fehlerlos erstellt.

Da soll noch mal einer die IBM verstehen.

[dschroeder]

Ich weiß, dass wir vor einigen Jahren auch mit RPGPPOPT(*LVL2) Probleme hatten. Inzwischen geht das bei uns aber problemlos.

Keine Ahnung, ob die Info hilft:
Bei uns werden die SQLRPGLE-Programme mit RPGPPOPT(*LVL2) gewandelt. "Normale" RPGLE Programme bekommen diese Information nicht mit.

Ich meine, mich erinnern zu können, dass es bei Copy-Strecken auch einen Unterschied macht, ob die mit /COPY oder /INCLUDE eingebunden wurden. Das hatte auch etwas mit *LVL2 zu tun, glaube ich.

[Fuerchau]

Das hängt mit dem SQL-Precompiler zusammen.
Copy kann der auflösen, jedoch nicht geschachtelt (gibts eine Fehlermeldung).
Include wird von SQL ignoriert.
Dies führt dann bei Like-Definitionen zu Problemen, wenn diese auf Include's basieren.

Dies alles löst *LVL2 auf, da eben Copy/Include aufgelöst werden bevor der SQL-Precompiler aktiv wird.
Und genau deshalb verstehe ich nicht, dass ein und dieselbe Quelle vom SQL-Precompiler ohne *LVL2 einwandfrei compiliert wird aber bei *LVL2 bei einem simplen "Select bla from file where ..." dann scheitert.
Die erstellte Pre-Quelle kann man sich ja sehr schön in QTEMP ansehen.