Proceduren / Serviceprogramm / BIND-Verzeichnis

[BenderD]

... so unterschiedlich scheint mir das garnicht.
- die Copystrecken für die Prototypen sind wohl überall gängig.
- der eine löscht die Module, der andere nicht.
- ein Modul = 1 Serviceprogramm scheint sich ebenfalls durchgesetzt zu haben
- bei dem zentralen Binderverzeichnis muss man sicherstellen, dass die Procedures alle eindeutig benamt sind und bleiben (meistens werden die dann mit dem Modulnamen als prefix versehen, entweder schon im Interface, oder im Prototyp umbenannt - ich mache das im Prototyp) (was mich von dem zentralen Binderverzeichnis abhält: das Ding vermüllt, weil keiner aufräumt und der größte Chaot im Team hat den größten EInfluss auf das Binderverzeichnis...)

--- die Unterschiede reduzieren sich in letzter Konsequenz darauf, ob man Binderlanguage verwendet oder schlicht EXPORT(*ALL) sagt. Bei der Verwendung von Binderlanguage (wenn man es denn richtig macht), kann man sich rebinds sparen; verwendet man export(*all) kriegt man in der Regel eine Signature Änderung, sodass verwendende Programme sofort beim Aufruf abschmieren, wenn sie nicht neu gebunden wurden. Habe ich lauter Birgittas, oder Thomas, oder Mihaels, oder Barbaras im Team, oder einer von denen hat die anderen unter der Knute geht das gut, bei einigen Gesichtern, die ich gerade vor mir sehe, eben nicht. (nebenbei bemerkt: beim statischen binden mehrerer Module in ein Service Programm ist Binder Language unverzictbar)
- Compile aus dem PDM ist kein Hexenwerk, da bastelt sich jeder seinen Command - es sei denn, man setzt Change Management Software ein, was sicherlich die bessere Lösung wäre.

D*B

Da gibt es unterschiedliche Ansätze:

Bei uns werden die (exportierten) Prozeduren nach Funktionalität in Teildateien geordnet.

• Aus jeder Teildatei, die i.d.R. mehrere Prozeduren beinhaltet wird zunächst ein Modul und anschließend aus dem Modul ein Service-Programm erstellt. Das Modul wird anschließend sofort gelöscht.
• Für jede Teildatei gibt es ein Copy-Member mit dem gleichen Namen in einer eigenen Source File QPROLESRC, in der die Prototypen für die exportierten Prozeduren hinterlegt sind. (Für die Faulen haben wir noch ein Copy-Member, indem die einzelnen Prototyp-Copymember über Copy zusammengefasst sind. Damit muss man nur eine Copy-Strecke angeben. Allerdings bei vielen vielen Prototypen, kann dabei aus einem 3 Zeiler Programm durchaus eine 300 seitige Umwandlungsliste entstehen). Ich bevorzuge allerdings die einzelnen Prototypen-Copystrecken, dann sehe ich gleich am Source Code was verwendet wurde.
• Ebenso gibt es für jede Teildatei eine Binderquelle in der die exportierten Prozeduren eingetragen sind.
• Alle Service-Programme werde in ein einziges Binderverzeichnis eingetragen.
• Dieses Binderverzeichnis wird jeweils beim Erstellen eines Service-Programs oder eines Programms angegeben.
• In allen Programmen wird das Binder-Verzeichnis wie folgt in den H-Bestimmungen hinterlegt. Dadurch wird das Binder-Verzeichnis mit jeder Compilierung über 14=Umwandeln (oder CRTBNDRPG) gezogen, ohne dass der Compile-Befehl geändert werden muss. Damit können alle Programme wie bisher mit Auswahl 14=Umwandeln (oder CRTBNDRPG) erstellt werden.

 /If Defined (*CRTBNDRPG)
H DftActGrP(*No) BndDir('QC2LE': 'MYBNDDIR')
 /EndIf

Um das Ganze zu vereinfachen habe ich bereits vor Jahren (inzwischen schon zum 3. Mal - nach 2 Firmenwecheln) einen Compile-Befehl geschrieben, der mir die ganze Arbeit, also Erstellen Modul, Erstellen oder Aktualisieren Bindersprache, Erstellen des Service-Programs, Hinzufügen des Service-Programs in das Binder-Verzeichnis und Löschen des Moduls abnimmt. Damit kann ich jedes Service-Programm einfach über PDM compilieren. Die einzige Voraussetzung ist, dass jeweils nur eine Quelle in ein Service-Program (oder Programm) gebunden wird und die neuen exportierten Prozeduren am Ende des Source Codes eingefügt werden.

(eigentlich wollte mein Chef diesen Command mal zum freien Download zur Verfügung stellen, ist aber bis dato noch nicht passiert )

Birgitta

[B.Hauser]

- der eine löscht die Module, der andere nicht.

Das Problem mit den stehengelassenen Modulen fängt dann an, wenn die Spezialisten Module in das Binderverzeichnis stellen (weil sie mehrere Module in Service-Programme oder Programme binden wollen). Damit sind Module und Service-Programme mit den gleichen Prozeduren im gleichen Binderverzeichnis. Das gibt zwar ein Problem beim Binden (per Default sind doppelte Prozedur-Namen nicht erlaubt). Aber die Spezialisten sind ja nicht dumm. Es gibt ja zum Glück die Option *DUPROC in den Binderbefehlen (die doppelte Prozedurnamen zulässt), die man ja angeben kann ...

... und juhu fallera, Module werden gebunden statt Service-Programme. Beim nächsten Update des Service-Programms rufen die (Service-)Programme, in denen das Modul (anstatt des Service-Programms) gebunden wurde, weiterhin den alten Schrott auf!

... und dann viel Spass beim Suchen!
... sch........ööööööööönes ILE!

Birgitta