RDi STRG+Space

[Fuerchau]

Ich muss das Thema noch mal aufwärmen.
Bei der Version RDi 9.6.0.0 tritt dieses Problem ebenso auf.
Vor allem beim Arbeiten mit langen Namen, geschachtelten Includes, ist es wirklich lästig, wenn das nicht funktioniert.
Ist das Problem behebbar?
Kennt jemand den Grund, warum das bei bestimmten Quellen nicht mehr funktioniert?

[dschroeder]

Meine Erfahrung ist, dass das Feature mit den RDi Versionen immer stabiler geworden ist. Ich würde zunächst auf die neueste Version wechseln. Kann man ja einfach bei IBM herunterladen. Die neueste Version ist 9.6.0.5. Du benötigst keine neue Lizenz dafür. Es ist nur ein Update.

Bei mir geht das Feature fast immer. Es gibt oft Probleme, wenn im Code weiter oben eine ungültige Syntax steht. Z.B. ein vergessenes Semikolon. Ich nutze das Feature allerdings nur bei RPGLE und SQLRPGLE. Für andere Quellenarten habe ich es noch nicht ausprobiert.

Dieter

[dschroeder]

Noch ein Hinweis: Das Feature funktioniert, wenn es den Quellcode fehlerfrei interpretieren kann. Wenn dein Quellcode z.B. /copy Strecken enthält, die wegen fehlender Bibliotheken nicht aufgelöst werden können, kann es eventuell nicht klappen.

[Fuerchau]

Das ist es definitiv nicht. Die Gliederungsansicht kann problemlos alle Copy's/Include's auflösen. Ich kann filtern und Verwendung ansehen. Das Klicken in der Gliederung mit Positionierung in der Quelle klappt ja auch.
Es sind auch nicht übermäßig viele Definitionen.
Syntaxfehler liegen keine vor, die Quelle ist fehlerfrei umgewandelt.

Bet STRG+Space werden ausschließlich die RPG-Grundbefehle angezeigt. Variablen und sonstige Definitionen funktionieren nicht mehr, es hat ja mal funktioniert.
In anderen Quellen klappts einwandfrei. Die Internetrecherche findet absolut keine Hinweise außer diesem Beitrag.

[dschroeder]

Wie gesagt: Die Version 9.6.0.0 ist ein "erster" Wurf der 9.6er Version. Die 5 Servicepacks (alle enthalten in 9.6.0.5) beheben einige Fehler, die wir anfangs mit der 9.6er-Version auch hatten. Ob das Autocomplete betroffen war, weiß ich allerdings nicht mehr.

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

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