Sperrproblem bei parallelem Kompilieren

[dschroeder]

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]

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]

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.

[BenderD]

Wir erstellen pro Serviceprogramm einen Source und exportieren auch nur eine Procedure pro Serviceprogramm.

... kann es sein, dass ihr das ILE Konzept nicht begriffen habt? Wenn man mal die technischen Eigenschaften des (lästigen) bindens weglässt, ist der Unterschied zwischen einem Programm und einem Serviceprogramm der, dass ein Serviceprogramm mehrere Entrypoints haben kann - benutze ich allerdings grundsätzlich nur einen, kann man sich den ganzen Zinnober des bindens komplett sparen und sollte das auch tun!!!

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.

... kann es sein, dass ihr den Prozess des bindens auch nicht verstanden habt? Wenn keine zur Compiletime nicht auflösbaren Referenzen beim binden aufgelöst werden müssen, braucht man kein Binderverzeichnis anzugeben.

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.

Wie kommt man eigentlich auf die Idee ein zentrales Binderverzeichnis zu benutzen? Binderverzeichnisse sind nur sinnvoll für externe Komponenten Bibliotheken - und dann ein eigenes pro Komponenten Bibliothek (man schaue sich mal das Binderverzeichnis QC2LE an). Im laufenden Projekt (sprich innerhalb der Anwendung) ist die Angabe der zu bindenden Komponenten aus Gründen der Stabilität und Reproduzierbarkeit sinnvoller - erfordert allerdings ein Minimum an Change Management.

D*B