Sperrproblem bei parallelem Kompilieren

[dschroeder]

Danke für die Antwort. Ich glaube allerdings, dass der Parameter EXPORT nicht angibt, dass eine Teildatei erstellt wird, sondern dass er in der Export-Teildatei Anweisungen für die zu exportierenden Prozeduren findet. Wir verwenden für Export den Wert *ALL. Das kann es also eigentlich nicht sein. Die Fehlermeldung sagt bei uns ja auch "Objekt IDM99A1F03 in EDPGMLIB Art SRVPGM kann nicht zugeordnet werden." Das ist das Serviceprogramm, das erstellt werden soll. Er kann also das Programmobjekt nicht zuordnen. Aber wer sperrt das? Kann es sein, dass alle Objekte, die in einem Binderverzeichnis angegeben sind, gesperrt werden?

[Fuerchau]

Ein aktives Serviceprogramm kann zur Laufzeit nicht ersetzt werden, will heißen, wenn es in Verwendung ist.

Normale Programme werden ja in die QRPLOBJ verschoben bevor das neue Objekt erstellt wird.
Ist das Programm noch aktiv in einem anderen Job, arbeitet dieser noch mit der alten Version.

Bei Serviceprogrammen ist das nicht möglich.
Um es zu ersetzen darf es nicht durch irgend einen anderen Aufruf gesperrt werden.

Per WRKOBJLCK lässt sich die Sperre ermitteln.

[dschroeder]

Ich habe das gerade mal ausprobiert und 3 Serviceprogramme IDM99A1F05, IDM99A1F06 und IDM99A1F07 in die parallele Wandlung geschickt. Die Programme haben vor der Wandlung keine Objektsperren. Während der Wandlung haben alle Programme jedoch Sperren durch den den eigenen und durch die anderen Wandlungsjobs.

Hier mal der WRKOBJLCK für das Objekt IDM99A1F06:
Job Benutzer Sperre Status
IDM99A1F05 SCHRO970 *SHRRD HELD
IDM99A1F06 SCHRO970 *SHRRD HELD
*EXCL WART
IDM99A1F07 SCHRO970 *SHRRD HELD

Das heißt, die Kompilierung sperrt die Programmobjekte. Aber wieso? Das ein Job das Programm sperrt, welches er gerade kompilieren und ersetzen will, ist ja klar. Aber wieso sperrt er die anderen Programmobjekte?

[Fuerchau]

Wenn beim Compile auf ein anderes Serviceprogramm referiert wird, löst der Compiler die Referenz bereits auf (Grund sind Signaturprüfungen u.ä.).
Deshalb wird die Sperre benötigt.

Du kannst z.B. kein ILEPGM auf eine Maschine zurückspeichern, wenn die Referenz zu einem Serviceprogramm nicht da ist. Also der RSTOBJ greift in diesem Fall auch bereits auf das Serviceprogramm zu.

Ich hatte leider mal den Fall, dass ich eine C-Routine eingebunden hatte die auf dem Zielsystem noch nicht vorhanden war. Der RSTOBJ ist da bereits gescheitert.
Ich konnte also nicht wie gedacht, per Monitor-Anweisung die Existenz der Routine prüfen, das erledigt bereits das System lange vorher.

[dschroeder]

Ich habe mir gerade nochmal die Sourcen der 3 Serviceprogramme angesehen. Bei diesen 3 Programmen ist es so, dass keines der Programme irgendwelche Referenzen auf andere Serviceprogramme hat. Die einzige Gemeinsamkeit der 3 Programme ist, dass sie im gleichen Binderverzeichnis stehen. Beim Compile wird das Binderverzeichnis (das ist unser zentrales Binderverzeichnis) allerdings bei jedem Programm angegeben.

[Fuerchau]

Das Binderverzeichnis sperrt dann die Objekte, da ja die Referenzen benötigt werden.

[dschroeder]

Vielen Dank für die Antwort. Dann heißt das für uns anscheinend, dass wir parallele Kompilieren vergessen können, sobald wir Binderverzeichnisse einsetzen. Tja, dann müssen wir wohl damit leben.

[Fuerchau]

Nur paralleles Kompilieren von Service-Programmen ist das Problem.

[dschroeder]

Das lässt sich bei uns nicht so einfach unterscheiden. Wenn wir wegen einer Dateiänderung alles neu kompilieren wollen, was diese Datei verwendet, sind da natürlich auch Serviceprogramme dabei.