RDi STRG+Space

[dschroeder]

Noch eine Idee: Möglicherweise ist etwas im workspace von RDi defekt. In einem alten Infobeitrag bei uns steht (allerdings für den Vorgänger RDP), dass man den Workspace aufräumen könnte.

Es gibt eine Aufrufoption -clean für den RDP. Damit sollen Cacheinhalte beim Starten gelöscht werden. Wenn es Probleme mit dem workspace gibt, hilft das möglicherweise. Die Performance leidet natürlich darunter.

[Fuerchau]

Die Cleanoption hat hier nichts gebracht.
Aber:
Da ich gerne Vereinfachungen liebe, habe ich in mein Hauptcopy weitere Includes hinzugefügt, die ich halt so benötige (i.w. sind das Prototypen von Service-Prozeduren).
Da habe ich dann wohl einen zuviel hinzugefügt (es waren ja nur 5).
Nach dem ich die Includes in die Hauptquelle als Copy verschoben habe, klappts nun auch wieder mit STRG+Space.

Da hat RDi schon so viele Versionen hinter sich gebracht, aber an sowas scheitert RDi immer noch.

[dschroeder]

Schön, dass das Problem behoben ist.

Wir haben unsere Includes so bedingt, dass sie nicht doppelt vorkommen können:
/if not defined(COPY__###)
/INCLUDE EDPGMLIB/QRPGLESRC,COPY__###
/endif

Hast du denn inzwischen auf die 9.6.0.5 upgedated?

Kann ich nur empfehlen.

[Fuerchau]

Ich sitze beim Kunden, das kann ich allenfalls vorschlagen.
Aber Installationen laufen hier häufiger auf Fehler (Win7!).

RDi kommt mit den geschachtelten Includes z.T. wohl nicht zurecht, Copy's klappen aber.
Nun hatte ich die Includes auf Copy umgestellt, so dass RDi nun hilfreich ist, im 1. Schritt beim CRTSQLRPGI aber gescheitert.
SQL-Fehler: geschachtelte Copy nicht zulässig!

Also "CRTSQLRPGI RPGPPOPT(*LVL2)" gesetzt und alles ist gut.
Mein Programm wurde fehlerfrei umgewandelt, da ich optisch immer noch gerne auch komplexere SQL's und Prozeduraufrufe selber umbreche.
Das sieht einfach übersichtlicher aus.

Nun sind hier die Quellen auch inzwischen 200 Stellen breit und dies wird z.T. halt auch ausgenutzt.
Hier kommt dann wieder der Unterschied SQL-Precompiler und RPG-Compiler-Phase1 zum Tragen.
Durch *LVL2 wird erst RPG-Phase1 zum Auflösen geschachtelter Copy/Includes aufgerufen und in QTEMP eine Quelle erstellt.
Dann kommt der SQL-Precompiler.
Und somit folgt wieder ein neues Problem:
SQL-Statements die nun wieder breiter als 80 Stellen werden, können z.T. nicht korrekt verarbeitet werden. In diesem Fall war es in einer anderen Quelle ein Case-When-Ausdruck, der über 80 Stellen hinaus ging.
Ein normaler SQL-Select ohne Case kann wiederum breiter als 80 sein!

Was soll wieder dieser Unfug?
Wieso kann der SQL-Compiler mit *LVL2 die SQL's wieder nicht analysieren, die bei *NONE noch funktionieren?

Also wieder zurück:
Precompiler wieder mit *NONE, Copy's wieder nicht geschachtelt wegen RDi, 1-stufiges Include (da SQL-Precompiler wohl nicht mehr kann?) und RDi sonst wieder bei STRG+Space streikt.

[dschroeder]

SQLRPGLE mit mehr als 80 Stellen funktioniert definitiv. Bei uns sind alle Sourcefiles 240 Zeichen breit.

Aber ich kann mich erinnern, dass ich ganz am Anfang der Umstellung auf breite Sourcen genau das gleiche Problem mit SQLRPGLE beim Pre-Compiler hatte. Ich muss mal schauen, ob ich mir da etwas notiert habe.

Ich meine, dass es da auch ein PTF gab. Kann es sein, dass der Kunde noch auf 7.1 läuft? Da musste man bestimmte PTFs haben, damit das ganze mit fully free und größerer Breite funktionierte.

Ich schaue gleich mal nach, ob ich bei mir noch etwas zu dem Thema finde.

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