View Full Version : HSpecs automatisch in Sourcen einbinden
Liebe Community,
Folgende Frage: Ich habe folgenden HSPEC:
H DATFMT(*EUR) ALWNULL(*USRCTL) DECEDIT('0,') DATEDIT(*DMY)
H OPTION(*NODEBUGIO: *SRCSTMT: *NOUNREF)
Dieser wird mit der Copy Funktion in jede zu veränderte Source vor dem Kompilieren eingefügt:
Meine Frage dazu: Gibt es eine Möglichkeit dies schneller einzubinden (automatisch) beim Kpompilieren ?
Ich habe bei RPG-Modul erstellen (CRTRPGMOD) folgenden Parameter gefunden:
Verzeichnis einschließen . . . . INCDIR *NONE
Kann man damit was machen ?
Oder kennt jemand eine bessere Lösung
Vielen Dank
Hannes
Wir haben da ein DTAARA RPGLEHSPEC.
Da sind die Dinge abgelegt.
Diese wird dann bei "14" mit eingebunden.
Gibt es in der Quelle H-Zeilen, wird das aus der DTAARA ignoriert
Gruß
Ronald
Hallo Ronald,
Vielen Dank für die Rückmeldung, das Problem ist, dass
wir in jeder Source H Anweisungen haben (2000-3000 Sourcen)
Gruß Hannes
Warum ist es denn ein Problem, wenn die H-Bestimmungen über Copy-Strecke (/COPY QSRCFILE,SrcMember oder /INCLUDE QSRCFILE,SrcMember) in die Quelle gezogen werden?
Das Einpflegen ist eine einmalige Aktion. Dann sind die Copy-Strecken (für immer) in der Quelle.
Ändert sich die Copy-Strecke, ist die Änderung nur an einer einzigen Stelle erforderlich. Die Programme müssen allerdings neu compiliert werden, damit die Änderung auch zieht.
Wenn man die einzelnen Schlüssel-Worte mit Compiler-Direktiven bedingt, ist es sogar möglich einzelne H-Bestimmungen in bestimmten Programmen zu deaktivieren und das Programm programmintern anders zu belegen.
Birgitta
Ändert sich die Copy-Strecke, ist die Änderung nur an einer einzigen Stelle erforderlich. Die Programme müssen allerdings neu compiliert werden, damit die Änderung auch zieht.
Birgitta
... das meinst Du doch nicht ernst? No risc. no fun, oder was???
D*B
Klar.
Ich war allerdings nun bei einem Kunden, der grundsätzlich keine Copystrecken verwendet.
Es wäre ihm zu aufwändig, beim Nachlesen in einem Programm immer in die Copystrecken reinschauen zu müssen um zu verstehen was da so abgeht.
Und "Copystrecken" sind daher bei ihm immer wartungsfrei da es keinen Grund gäbe diese jemals zu ändern.
Auch eine Art der Grundsatzentscheidung.
Da würde der RDi-Editor (egal welcher) helfen, wenn er Copy's dynamisch per auf/zuklappen innerhalb der Quelle sichtbar machen könnte.
ja, das wäre ne Hilfe!
Wir sind noch bei SEU, weil unser SEU, durch UserExit Pgmme, das kann!
/Copy separat anzeigen
/copy separat editieren
/copy integirert editieren und beim speichern wieder zurück schreiben
Vor dem aufklappen müßte RDI ein Userexit erlauben in dem man, je nach Projektstand, die Herkunftslib bestimmen kann.
Robi
andreaspr@aon.at
08-02-16, 08:41
Da würde der RDi-Editor (egal welcher) helfen, wenn er Copy's dynamisch per auf/zuklappen innerhalb der Quelle sichtbar machen könnte.
Das Auf/Zuklappen geht zwar nicht, aber mit einen Rechts-Klick auf die /Copy-Zeile kann der RDi die entsprechende Teildatei öffnen. Man braucht also nicht diese extra zu "suchen".
(Es wird die LIBL verwendet.)
In der Gliederungsansicht werden auch jene Variablen angezeigt, die auch in den Copy-Strecken definiert sind.
Und "Copystrecken" sind daher bei ihm immer wartungsfrei da es keinen Grund gäbe diese jemals zu ändern.
... das hört sich (fast) vernünftig an!!! Es gibt nicht nur keinen Grund zentrale Copystrecken zu ändern, es gibt dutzende Gründe zentrale Copystrecken keinesfalls zu ändern!!! Ungeprüft compilieren öffnet die Büchse der Pandorra, alles zu prüfen erzeugt mehr Aufwand, als man durch die Verwendung von Copystrecken einzusparen zu meinen glaubt.
D*B
Das hört sich etwas nach "Vererbung" an ...
Wie ist das bei objektorientierten Programmiersprachen?
Soll man da besser auch keine Methode mehr ändern, die vererbt worden ist?
... das hört sich (fast) vernünftig an!!! Es gibt nicht nur keinen Grund zentrale Copystrecken zu ändern, es gibt dutzende Gründe zentrale Copystrecken keinesfalls zu ändern!!! Ungeprüft compilieren öffnet die Büchse der Pandorra, alles zu prüfen erzeugt mehr Aufwand, als man durch die Verwendung von Copystrecken einzusparen zu meinen glaubt.