RDi STRG+Space

[dschroeder]

Ich habe zu dem Thema noch einen Forumseintrag gefunden. Suche im Forum über die Google Suche mal nach: Umwandlung mit RPGPPOPT(*LVL2)

Da haben wir schon mal über das Thema gesprochen. Da habe ich auch PTFs herausgesucht und einiges von IBM gepostet.

[Fuerchau]

Da ich das mit meiner Quelle probiert habe, muss ich noch mal mit dem Kollegen prüfen.
Aber im Spool war der gesamte SQL ja drin, also nicht abgeschnitten.
Es wurde nur ein ominöser Fehler "Fließkommawert unzulässig" gemeldet.
Ohne *LVL2 läuft der Compiler problemlos durch.
Ich schau mal, ob ich die Quelle einsehen und mal den Part posten kann.

[dschroeder]

*LVL2 geht definitiv. Bei uns wandeln SQLRPGLEs prinzipiell mit folgenden Parametern:

// Basis-Command festlegen:
cmd = 'CRTSQLRPGI COMMIT(*NONE) OBJTYPE(*MODULE) TGTRLS(*CURRENT) +
DATFMT(*EUR) DBGVIEW(*SOURCE) USRPRF(*OWNER) +
DYNUSRPRF(*OWNER) RPGPPOPT(*LVL2) ';

Im Joblog des Wandlungsjobs kann man auch sehen, dass temporäre Tabellen mit einer Breite von 240 Zeichen angelegt wurden:

Datei QSQLPRE in Bibliothek QTEMP erstellt.
Teildatei SIS02AEF zu Datei QSQLPRE in QTEMP hinzugefügt.
Teildatei SIS02AEF in Datei QSQLPRE in QTEMP geändert.
Diagnoseprüfung der Quelle ist beendet. Höchste Bewertungsstufe ist 00.
Eigentumsrecht für Objekt RETURNCODE in QTEMP Art *DTAARA geändert.
Datenbereich RETURNCODE in Bibliothek QTEMP erstellt.
Datei QSQLT00240 in Bibliothek QTEMP erstellt.
Teildatei SIS02AEF zu Datei QSQLT00240 in QTEMP hinzugefügt.

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

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