HSpecs automatisch in Sourcen einbinden

[boonkelz]

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

[malzusrex]

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

[boonkelz]

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

[B.Hauser]

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

[BenderD]

Ä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

[Fuerchau]

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.

[Robi]

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]

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.

[BenderD]

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

[Pikachu]

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.

[Fuerchau]

Gerade bei Objektorientierung verbietet sich sowas on Natur aus.
Außer in der Entwicklungsphase (da gibts dann Hilfen wie Refactoring um alle Verweise anzupassen) dürfen Methoden und Eigenschaften nicht mehr geändert werden.
Dafür gibt es genug andere Möglichkeiten wie Overloading (Gleicher Name, unterschiedliche Parameter).
Wenn sich der Inhalt einer Methode als grundsätzlich fehlerhaft erweist so lässt sich dies innerhalb natürlich korrigieren. Funktionserweiterungen sind da aber absolut schädlich. Da gibt es besser Direktivien in der Methode wie "depracticated" mit ggf. dem Hinweis auf neue Methoden.

[BenderD]

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 hat mit Vererbung nichts zu tun. Was OO angeht, kann ich da nur für Java sprechen und da gibt es ganz wesentliche Unterschiede, sowohl was die Sprache selber und auch den Compiler angeht.
- der Compiler prüft grundsätzlich alle Referenzen, auch externe auf Projekt-Ebene
- compiliert und deployed wird immer das gesamte Projekt
- für alles, was darüber hinaus sichtbar ist (public) gibt es eine glasklare Konvention, dass sich das aus der äußeren Sicht betrachtet, niemals ändern darf
- Copystrecken und ähnliche Krücken gibt es in Java nicht

Wenn man denn eine Analogie zur globalen Änderung von H Lochkarten ziehen wollte, dann müsste man in Java ein globales AntSkript für das Deployment aller Projekte verwenden, was kein Java Programmierer auch nur in Betracht ziehen würde und dann müsste man dieses globale Erstellungsskript auch noch ändern wollen und dann alles komplett redeployen, für den letzten Java Programmierer, der das versucht hat, hat man den Knast in Alcatraz wieder eröffnet und der sitzt jetzt dort und muss RPG Programme schreiben - lebenslänglich!!!

D*B