View Full Version : Sperrproblem bei parallelem Kompilieren
dschroeder
16-11-12, 10:17
Hallo,
wir haben folgendes Problem: Wenn wir viele Programme im Batch kompilieren möchten, verwenden wir gerne eine JOBQ, die Parallelverarbeitung unterstützt (z.B. 20 Jobs gleichzeitig). Das reduziert die Wandlungszeit beträchtlich. Leider haben wir das Problem, dass die gleichzeitige Wandlung von Serviceprogrammen nicht möglich ist. Wenn ich z.B. 3 Serviceprogramme gleichzeitig wandle, bleiben alle 3 Wandlungen stehen mit LCKW beim CRTSRVPGM. Nach einiger Zeit brechen dann 2 Wandlungen ab. Eine klappt in der Regel. Die Fehlermeldung ist "Objekt IDM99A1F03 in EDPGMLIB Art SRVPGM kann nicht zugeordnet werden." Wir erstellen pro Serviceprogramm einen Source und exportieren auch nur eine Procedure pro Serviceprogramm. Alle Serviceprogramm befinden sich in einem BNDDIR, dass bei jeder Wandlung benutzt wird. Ich verstehe nicht, wieso eine Sperrung auf dem Serviceprogramm-Objekt liegt. Wenn wir "normale" RPGLE-Programme wandeln (die benutzen auch das Binderverzeichnis), ist parallele Wandlung überhaupt kein Problem.
Vielleicht hat jemand eine Idee?
Gruß,
Dieter
andreaspr@aon.at
16-11-12, 10:31
Beim CRTSRVPGM wird eine Teildatei mit den Daten der Prozeduren erstellt.
Ich kann mir vorstellen, dass da ein LOCK gemacht wird.
Export . . . . . . . . . . . . . EXPORT *SRCFILE
Exportquellendatei . . . . . . . SRCFILE QSRVSRC
Bibliothek . . . . . . . . . . *LIBL
Exportquellenteildatei . . . . . SRCMBR *SRVPGM
lg Andreas
dschroeder
16-11-12, 10:42
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?
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
16-11-12, 11:41
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?
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
19-11-12, 08:32
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.
Das Binderverzeichnis sperrt dann die Objekte, da ja die Referenzen benötigt werden.
dschroeder
19-11-12, 09:41
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.
Nur paralleles Kompilieren von Service-Programmen ist das Problem.