Externe Prozedur

[B.Hauser]

Hallo,

eine andere und m.E. sogar bessere Möglichkeit ist die folgende.
1. Erstellen Modul, in dem die Prozedur enthalten ist
2. Erstellen Service Programm, aus dem Modul
3. Einfügen des Service Programms in ein Binder-Verzeichnis.
Es sollte ein zentrales Binderverzeichnis pro Anwendung vorhanden sein.
4. Erstellen Programm, in dem die Prozedur aufgerufen wird, über CRTBNDRPG. Dabei darf die Default Aktivierungs-Gruppe nicht verwendet werden. Wird diese Option geändert, kann das Binder-Verzeichnis angegeben werden.

Die Verwendung eines Binderverzeichnisses ist vor allem dann von Vorteil, wenn in dem Programm viele Prozeduren aus vielen Service Programmen aufgerufen werden müssen. Bei der Compilierung werden die Einträge im Binder-Verzeichnis verarbeitet und die entsprechenden Signaturen der Service- Programme in das Programm-Objekt eingebunden. Es ist also nicht erforderlich die Service-Programme einzeln aufzuzählen.
Das Binder-Verzeichnis kann natürlich auch beim CRTPGM angegeben werden.

Besser noch ist, sowohl die Aktivierungs-Gruppe als auch das bzw. die verwendeten Binder-Verzeichnisse in den H-Bestimmungen über folgende Schlüssel-Worte zu hinterlegen:
1. DFTACTGRP(*NO)
2. ACTGRP('NAME') oder ACTGRP(*NEW) oder ACTGRP(*CALLER)
3. BNDDIR('MYBNDDIR1': 'MYBNDDIR2' ...)

In diesem Fall müssen die Compile-Optionen beim CRTBNDRPG oder CRTPGM nicht geändert werden.

Birgitta

[BenderD]

Hallo,

Geschmacksache, sagte der Affe und biss in die Seife.
Ich mag mich weder auf Binderverzeichnisse (in denen jeder rumfummelt und der grösste Chaot im Team den Ausschlag gibt) noch auf irgendwelche Defaults etc verlassen. Der resultierende Wirrwarr wird umso fataler je mehr Prozeduren aus zahlreichen Serviceprogrammen aufgerufen werden!!!
Neueste Erfahrungen damit haben einige mit V5R3 bereits hinter sich, bei dem beim CRTPGM ein neuer Wert gleich als default genommen wurde. Statt in Actgrp *new läuft da jetzt einiges plötzlich in QILE - mit teilweise fatalen Auswirkungen für remote SQL Zugriffe, Commit Steuerung und Overwrites (von denen ich eh abrate). Ich sage immer genau was ich haben will (das nur einmal, weil ich CM oder Pre Compiler einsetze) und habe 100% Reproduzierbarkeit.

mfg

Dieter Bender

Hallo,

eine andere und m.E. sogar bessere Möglichkeit ist die folgende.
1. Erstellen Modul, in dem die Prozedur enthalten ist
2. Erstellen Service Programm, aus dem Modul
3. Einfügen des Service Programms in ein Binder-Verzeichnis.
Es sollte ein zentrales Binderverzeichnis pro Anwendung vorhanden sein.
4. Erstellen Programm, in dem die Prozedur aufgerufen wird, über CRTBNDRPG. Dabei darf die Default Aktivierungs-Gruppe nicht verwendet werden. Wird diese Option geändert, kann das Binder-Verzeichnis angegeben werden.

Die Verwendung eines Binderverzeichnisses ist vor allem dann von Vorteil, wenn in dem Programm viele Prozeduren aus vielen Service Programmen aufgerufen werden müssen. Bei der Compilierung werden die Einträge im Binder-Verzeichnis verarbeitet und die entsprechenden Signaturen der Service- Programme in das Programm-Objekt eingebunden. Es ist also nicht erforderlich die Service-Programme einzeln aufzuzählen.
Das Binder-Verzeichnis kann natürlich auch beim CRTPGM angegeben werden.

Besser noch ist, sowohl die Aktivierungs-Gruppe als auch das bzw. die verwendeten Binder-Verzeichnisse in den H-Bestimmungen über folgende Schlüssel-Worte zu hinterlegen:
1. DFTACTGRP(*NO)
2. ACTGRP('NAME') oder ACTGRP(*NEW) oder ACTGRP(*CALLER)
3. BNDDIR('MYBNDDIR1': 'MYBNDDIR2' ...)

In diesem Fall müssen die Compile-Optionen beim CRTBNDRPG oder CRTPGM nicht geändert werden.

Birgitta

[B.Hauser]

Neueste Erfahrungen damit haben einige mit V5R3 bereits hinter sich, bei dem beim CRTPGM ein neuer Wert gleich als default genommen wurde. Statt in Actgrp *new läuft da jetzt einiges plötzlich in QILE - mit teilweise fatalen Auswirkungen für remote SQL Zugriffe, Commit Steuerung und Overwrites (von denen ich eh abrate). Ich sage immer genau was ich haben will (das nur einmal, weil ich CM oder Pre Compiler einsetze) und habe 100% Reproduzierbarkeit.

Aus diesem Grund habe ich ja auch vorgeschlagen die entsprechenden Werte in die H-Bestimmungen einzutragen.
Das gibt auch dann keine Probleme, falls IBM mal wieder auf die Idee kommen sollte Default-Werte in den Commands zu ändern. Ob bei CRTPGM nun *NEW oder *ENTMOD eingetragen ist, ist dann gleich, da die Aktivierungs-Gruppe aus den H-Bestimmungen verwendet wird.

Grundsätzlich sollte man, sofern man embedded SQL verwendet eine zwei-stufige (Modul/Programm bzw. Service Programm) Compilierung durchführen. Der Grund dafür, ist, dass der Befehl CRTSQLRPGI keine Optionen für Aktivierungs-Gruppe, Binderverzeichnis und (so man denn will) Binder-Service-Programme hat. Die Aktivierungs-Gruppe wird bei Programmen gnadenlos auf die Default-Aktivierungs-Gruppe gesetzt und bei Service-Programmen auf *CALLER.

Birgitta

[BenderD]

Hallo,

ich denke es ist deutlich geworden, dass die Programmerstellung reproduzierbar sein muss und dass das in ILE etwas komplizierter ist, als in OPM.
Ich persönlich bevorzuge die Pre Compiler Variante aus Gründen der Einheitlichkeit und Einfachheit und das unabhängig von der Objekt Art und aus Gründen der Lesbarkeit. Noch lieber wäre mir ein Ant Skript (System unabhängiger Batch Interpreter aus der Java Welt), aber das hat noch keiner portiert. Bei der Pre Compiler Variante kann man zudem weitere Tasks in den Ablauf einhängen und das ohne jeden Verwaltungs Overhead. Es sei an dieser Stelle auch eingestanden: die Idee habe ich mir bei SYNON1 abgeschaut, soweit das noch jemand kennt.
Die Variante mit den H Zeilen hat auch ihren Reiz, geht aber nur für RPG, da nicht überall, hat zusätzlich zu deinen genannten weitere Einschränkungen in älteren Releases und ich bekomme Unterschiede im Handling, da ja die Activation Group keine Eigenschaft des Moduls, sondern eine Eigenschaft des Programms/Service Programms ist und bei Wechsel von einstufiger zu zweistufiger Erstellung taucht dann wieder eine Fehlerquelle auf.

mfg

Dieter Bender

Aus diesem Grund habe ich ja auch vorgeschlagen die entsprechenden Werte in die H-Bestimmungen einzutragen.
Das gibt auch dann keine Probleme, falls IBM mal wieder auf die Idee kommen sollte Default-Werte in den Commands zu ändern. Ob bei CRTPGM nun *NEW oder *ENTMOD eingetragen ist, ist dann gleich, da die Aktivierungs-Gruppe aus den H-Bestimmungen verwendet wird.

Grundsätzlich sollte man, sofern man embedded SQL verwendet eine zwei-stufige (Modul/Programm bzw. Service Programm) Compilierung durchführen. Der Grund dafür, ist, dass der Befehl CRTSQLRPGI keine Optionen für Aktivierungs-Gruppe, Binderverzeichnis und (so man denn will) Binder-Service-Programme hat. Die Aktivierungs-Gruppe wird bei Programmen gnadenlos auf die Default-Aktivierungs-Gruppe gesetzt und bei Service-Programmen auf *CALLER.

Birgitta

[Muchi]

Hallo,

ich denke es ist deutlich geworden, dass die Programmerstellung reproduzierbar sein muss und dass das in ILE etwas komplizierter ist, als in OPM.
Ich persönlich bevorzuge die Pre Compiler Variante aus Gründen der Einheitlichkeit und Einfachheit und das unabhängig von der Objekt Art und aus Gründen der Lesbarkeit. Noch lieber wäre mir ein Ant Skript (System unabhängiger Batch Interpreter aus der Java Welt), aber das hat noch keiner portiert. Bei der Pre Compiler Variante kann man zudem weitere Tasks in den Ablauf einhängen und das ohne jeden Verwaltungs Overhead. Es sei an dieser Stelle auch eingestanden: die Idee habe ich mir bei SYNON1 abgeschaut, soweit das noch jemand kennt.
Die Variante mit den H Zeilen hat auch ihren Reiz, geht aber nur für RPG, da nicht überall, hat zusätzlich zu deinen genannten weitere Einschränkungen in älteren Releases und ich bekomme Unterschiede im Handling, da ja die Activation Group keine Eigenschaft des Moduls, sondern eine Eigenschaft des Programms/Service Programms ist und bei Wechsel von einstufiger zu zweistufiger Erstellung taucht dann wieder eine Fehlerquelle auf.

mfg

Dieter Bender

Vielen Dank für Eure Hilfe.
Gruß Michael