Service Programm in mehreren Bibliotheken

[Christoph]

Hallo,

ich hätte mal ne Frage.

Ich habe ein Service Programm geschrieben. Dieses steht in einer
Standard Bibliothek. Nun muss ich dieses SRVPGM für einen Kunden anpassen,
d.h. in der Kundenbibl. vorlagern.

Hierbei hab ich jetzt das Problem, wie muss ich das SRVPGM binden damit es
wenn ich in der Standard-Umgebung bin, das SRVPGM aus der Stanardbibl. zieht und in der Kundenumgebung das SRVPGM aus der Kundenbibl.

Bei mir gibts immer nen CPF, weil er immer auf das zu letzt gewandelte SRVPGM zugreift.

Weiß jemand Rat.

Gruß
Christoph

[Fuerchau]

Die Verweise auf Service-Programme werden bereits zur Erstellung (Binderverzeichnis) festgelegt.
Die Lib für Service-PGM'e braucht daher auch nicht in der Libl zu stehen. Es kann daher keine 2 Versionen eines Service-Pgm's geben.
Um 2 Versionen zu haben, müssen auch alle Programme, die dieses Service-PGM nutzen in einer 2. Version erstellt werden.

Der Call auf eine Funktion/Prozedur nennt sich auch "statisch", weil die Adresse zur Funktion eine Konstante ist.

Um dynamische Call's zu verwenden muss man die Lösung "dynamischer Call von Prozeduren" von Dieter Bender (auf seiner Homepage) verwenden.

Die andere Version wäre halt wieder ein dynamischer Call eines Programmes an Stelle einer Prozedur, da das Programm immer über die Libl gesucht wird.

[BenderD]

Hallo Christoph,

das sieht so aus, als ob da mit den Signaturen was krumm ist; das Binden scheint korrekt zu sein, sonst käme keine Fehlermeldung. Schreib doc mal genauer, was Du für eine CPF bekommst und was Du genau machst.

@Baldur: Das ist doch gerade der Trick bei Serviceprogrammen, dass keine festen Adressen gebunden werden, sondern nur ein (auch per LIBL auflösbarer) Link auf das Serviceprogramm (entspricht DLL), über den die Adressen der Prozeduren bei Aktivierung aufgelöst werden.
Beim dynamischen Binden wird das Serviceprogramm gesteuert aktiviert und die Referenzen zu den Prozeduren explizit zugeordnet.

mfg

Dieter Bender

Hallo,

ich hätte mal ne Frage.

Ich habe ein Service Programm geschrieben. Dieses steht in einer
Standard Bibliothek. Nun muss ich dieses SRVPGM für einen Kunden anpassen,
d.h. in der Kundenbibl. vorlagern.

Hierbei hab ich jetzt das Problem, wie muss ich das SRVPGM binden damit es
wenn ich in der Standard-Umgebung bin, das SRVPGM aus der Stanardbibl. zieht und in der Kundenumgebung das SRVPGM aus der Kundenbibl.

Bei mir gibts immer nen CPF, weil er immer auf das zu letzt gewandelte SRVPGM zugreift.

Weiß jemand Rat.

Gruß
Christoph

[Fuerchau]

@Dieter
Stimmt, nur die C-Routinen und die Runtime-Funktionen sind "hart" verbunden.

@Chrisoph
Wichtig ist also, dass ALLE Serviceroutinen in dem anderen Service-Programm enthalten sind.
Es kann also nicht eine Routine über LibA und die andere über LibB ermittelt werden, da die Suchfolge 1. Programm und 2. Routine ist.

[BenderD]

Hallo,

@Baldur
am Besten sieht man am CRTPGM und DSPPGM was da geht:
man kann ein SRVPGM mit *LIBL binden und qualifiziert und das geht für jedes SRVPGM extra.
Im PGM Objekt sind dann alle benötigten Procedures über ihre Serviceprogramme gebunden und werden bei Aktivierung (zur Startzeit des Programmes) entsprechend der Bindeangabe (LIBL oder qualifiziert) auf Procedure Pointer vernagelt. Selbstverständlich müssen die zur Laufzeit (wie auch immer) gefundenen Serviceprogramme dieselbe Signatur haben (die gleichen Exporte anbieten), wie das SRVPGM, das beim Compile verwendet wurde (nur Virtuosen oder Wahnsinnige verwalten Signaturen selber und wer ist schon Virtuose?!).
Zur Aufrufzeit werden dann nur noch Procedure Pointer stumpf verwendet, wenn das schief geht, geht's halt schief.
An die Runtime Funktionen kommt man nicht dran, da hier die Bindeangaben hart verdrahtet sind, zudem werden diese nicht als SRVPGM, sondern als Module by copy gebunden und alles was by copy gebunden wird steht zur Compiletime statisch im PGM Objekt drin. Soweit C Routinen (welche auch immer) über ein SRVPGM by reference gebunden werden, lässt sich LIBL oder qualifiziert wieder einstellen, im Binding Directory, oder beim BNDSRVPGM des CRTPGM - genau diese Lage ist einer der wesentlichen Gründe, weshalb ich dazu rate auf Binding Directories zu verzichten, den Quatsch mit Binder Language zu unterlassen und stattdessen die Create Befehle in die Quellen zu schreiben (da gibt es ein kleines Tool auf meiner Freeware Seite...) oder Change Management Software zu verwenden.

mfg

Dieter Bender

@Dieter
Stimmt, nur die C-Routinen und die Runtime-Funktionen sind "hart" verbunden.

@Chrisoph
Wichtig ist also, dass ALLE Serviceroutinen in dem anderen Service-Programm enthalten sind.
Es kann also nicht eine Routine über LibA und die andere über LibB ermittelt werden, da die Suchfolge 1. Programm und 2. Routine ist.