Sperrproblem bei parallelem Kompilieren

[dschroeder]

Erst mal vielen Dank für die ausführliche Antwort. Es kann durchaus sein, dass wir einige Dinge nicht verstanden haben. Wir sind deshalb für jede Hilfe dankbar. Die Tatsache, dass wir jedes Serviceprogramm in einem eigenen Source und mit nur einer exportierten Procedure erstellen, liegt daran, dass Serviceprogramme unseres Wissens nach ihre Signatur ändern, wenn man z.B. eine weitere Procedure exportiert. Das würde bedeuten, dass wir alle Programme, die irgendeine der exportieren Procedures benutzen, neu kompilieren müssten, wenn wir dem Serviceprogramm eine neue Procedure hinzufügen.

Die Sache mit den Binden haben wir wahrscheinlich wirklich nicht gut verstanden. Wir wollen nicht pro Programm ein eigenes Compileprogramm erstellen und binden deshalb beim Compile-Process alles ein, was wir haben (nämlich unser zentrales Binderverzeichnis). Der Compiler kann dann ja alle Referenzen auflösen. Was er nicht braucht, lässt er weg.

Wir haben zur Zeit keine praktikable bessere Idee. Die schon mehrfach im Forum genannte Idee, alle Wandlungsoptionen als Kommentar im Source zu verdrahten und vor der Kompilierung zu interpretieren, gefällt mir grundsätzlich ganz gut, lässt sich aber nachträglich in vielen tausend Sourcen bei uns schlecht einbauen.

[BenderD]

- statt eines Service Programmes mit einer einzigen exportierten Prozedur kann man besser ein Programm daraus erstellen.
- bei Änderung der Signatur wird im schlimmsten Falle neues binden erforderlich, ein compile nicht.
- Änderungen von Signaturen sind bei sorgfältigem Design eher selten als die Regel
- Signaturänderungen lassen sich auch durch BinderSource verhindern
- Signaturänderungen sind bei dynamischem binden zur Laufzeit unschädlich
- alle Objekte (Module, SRVPGM, PGM) enthalten alle Informationen, die zu ihrer Erstellung benötigt werden. Daraus kann man sowohl die Compile Anweisungen in die Quellen generieren, die Objekt neu erstellen, das Repository eines change Management tools füllen, make Skripte erstelle, oder was immer man will. Die Anzahl der vorhandenen Programme überzeugt mich hier keineswegs.

mfg von Dieter zu Dieter

[dschroeder]

Wir wollen ja gerade kein "normales" Programm erstellen, weil wir den komfortablen Aufruf eines Serviceprogramms im free format schätzen.
Die Sache mit "Compile ist nicht erforderlich, sondern nur neu binden" kann natürlich sein, hilft uns jedoch nicht. Wenn wir die Signatur eines Serviceprogramms ändern, bekommen meines Wissens nach alle Programme, die das Serviceprogramm eingebunden haben, Probleme. Eine neues Durchwandeln ist dann jedenfalls erforderlich. Ob das Kompilieren unnötig ist, spielt für uns dabei keine Rolle. Wir müssen auf jeden Fall neu "wandeln".
Die Sache mit der unschädliches Signaturänderung bei dynamischem Binden finde ich sehr interessant. Ich muss gestehen, dass mit anscheinend nicht klar ist, was "dynamisches Binden" ist. Ich dachte immer, wir machen so etwas. Wenn wir ein Serviceprogramm ändern und neu kompilieren, wirkt das sofort auf alle Programme, die es verwenden.
Über die andere Sache mit dem Generieren der Erstellungsinformationen werden wir auf jeden Fall auch noch mal nachdenken.

[BenderD]

Der entscheidende Punkt beim Aufruf ist die Verwendung eines Prototyps und nicht die technische Erstellung des Objektes (SRVPGM oder PGM). Der einzige Unterschied, der da sichtbar wird ist, ob es einen Rückgabewert gibt, oder die Rückgabe in einem Aufrufparameter zurückkommt.
Dynamisches binden kann man auf zwei Wegen, entweder durch die Maskierung als SQL Function, oder über die Verwendung von APIs. Im Prototyp wird dann ein Procedure Pointer deklariert, der vor dem ersten Aufruf zugeordnet werden muss (siehe PROCP4NAME auf meiner Freeware Seite).

Der entscheidende Punkt bei der ganzen Angelegenheit ist das Design der Anwendung: bei gutem Design sind Signatur Änderungen selten!!! Programmieren ist eine Design lastige Tätigkeit und gutes Design (erst überlegen, dann tippen) wird immer durch einfache Implementierung und gute Wartbarkeit belohnt. Natürlich muss man dann vom oft zu hörenden "Fang schon mal an..." (zieh Dir schon mal die Hose hoch, den Hintern kannst Du Dir später noch abwischen...) weg.

D*B

[dschroeder]

Ich sehe nicht ein, weshalb Signaturänderungen selten sein sollten. Wenn eine Signaturänderung bedeutet, dass sich der Aufruf- oder Rückgabeparameter einer Procedure ändert, so stimme ich zu: Das kommt selten vor. Aber so weit ich weiß, reicht schon das Hinzufügen einer neuen exportierten Procedure zu einem Serviceprogramm, dass sich die Gesamtsignatur des Serviceprogramms ändert. Und das kommt definitiv häufig vor. Z.B. wenn man ein Serviceprogramm mit Tools für Stringoperationen erstellen würde. Das Serviceprogramm kennt vielleicht 10 exportierte Funktionen. Wenn man dann eine neue Stringfunktion hinzuprogrammiert, hat man in allen Programmen, die eine der bestehenden Funktionen nutzen, Probleme. Bei uns kommen jeden Tag neue Funktionen hinzu.

Irgendwie verstehe ich nicht, weshalb das ganze Verfahren so kompliziert sein muss. IBM müsste sich doch auf überlegen, dass sich die meisten Programmierer lieber mit ihrem Sourcecode beschäftigen wollen anstatt sich erst ein Kompilier-Infrastruktur selbst zu bauen.

[Fuerchau]

Mit den Signaturänderungen kann Dieter das sicherlich besser erklären.
Aber irgendwas scheint da unklar zu sein.

Ich habe bereits mehrere Programme mit der Verwendung von C-Funktionen über das QC2LE eingebunden.
Die Programme, die ich bereits auf V4R5 entwickelt habe, musste ich bis V6R1 noch nicht neu umwandeln obwohl sicherlich in den Service-Programmen einige Aufruf dazugekommen sind die es früher nicht gab ohne das die Signatur der Aufrufe davon betroffen ist.

[BenderD]

Parameterschnittstellen ändern bei vorhandenen Funktionen sollte man ohnehin nie machen, da kommt allenfalls eine neue Funktion dazu, oder es wird eine (später dann) nicht mehr benötigt.

Signaturänderungen beim hinzufügen von Funktionen kann man sich mit Binder Language ersparen (die man sich ebenfalls generieren könnte). Da laufen dann zwei Anforderungen konkurrierend, mehr Komplexität durch Binder Language oder einfacheres Handling und mehr Stabilität durch Rebinds und mehr zu verteilende Objkekte erkaufen. Beides kann man mit change Management Tools, die man kaufen oder selbst entwickeln muss, automatisieren - beides ist kein Hexenwerk.

Bei dem Beispiel mit den String Operationen würde gutes Design statt 10 Funktionen, die akut benötigt werden, eventuell 15 Prozeduren definieren von denen die 10 jetzt benötigten angelegt werden...

Eklatanter wird das, bei richtig gutem Design! Ein Datenbankzugriffsmodul würde alle Zugriffe auf eine bestimmte Tabelle in einem Modul zentralisieren und welche da gebraucht werden, weiß man bevor die erste implementiert wird. Es ist eben gerade nicht egal in welchem Modul eine Procedure loaklisiert ist und zuerst müssen Orte und Zuständigkeit definiert werden, was dann bei der Erfordernis von technischen Rebinds die Auswirkungenh zudem noch lokal hält.

Die Frage warum IBM das so kompliziert gemacht hat, kann ich ebensowenig beantworten, wie die Frage warum sich die meisten Verwender von ILE das Leben dann noch unnötig erschweren. (Bei Java jedenfalls kompiliert mir meine Entwicklungsumgebung immer automatisch was benötigt wird und deployed wird zuemeist ein komplettes Jar File - sprich eine komplette Anwendung).

D*B

[dschroeder]

Ich habe jetzt viele Dinge gehört, über die ich mir erstmal Gedanken machen muss. Z.B. habe ich mich noch nie mit Binder Language beschäftigt. Ich werde die Sache mit mehreren Procedureexporten in einem Serviceprogramm auch nochmal ausprobieren und überprüfen, ob die Probleme, die ich vor Jahren damit hatte, immer noch existieren. Vielleicht geht das ganze ja doch. Baldur scheint damit ja keine Probleme zu haben, wenn ich ihn richtig verstanden haben. Nichtsdestotrotz habe ich einen Call bei IBM aufgemacht. Die sollen mir das Locking-Verhalten beim CRTSRVPGM mal erklären. Wenn ich da etwas erfahre, werde ich es gerne hier berichten.

Vielen Dank erstmal an alle. Vielleicht gibt es ja auch noch weitere Ideen, wie man sich das Kompilieren einfacher machen kann. Falls ja, bitte posten.

Gruß,
Dieter

[BenderD]

...ich empfehle (und mache das auch selber so):
- ein Modul ein Serviceprogramm
- Module haben ein Substantiv als sprechenden Namen
- Module enthalten alles, was an Verhalten zu diesem Objekt gehört
- keine Binderlanguage
- rebinds bei den (seltenen) Änderungen
- kritische Module kriegen ihre Komponenten zur Laufzeit gebunden und benötigen keinerlei rebinds wg. Abhängigkeiten
- keine Verwendung von Binding directories
- alle Quellen sind self containing (komplette Erstellung im Quellcode)
- getrennter Compile und bind

Das gab bisher noch nie irgendwelche Probleme, sowohl beim erstellen, einzel oder parallel, rebind oder Deployment (außer bei zweitbesten Änderungen)

D*B,
der keinen Bock auf Probleme hat, die man nicht haben muss!

[dschroeder]

Vielen Dank für diese Tipps. Wir müssen mal sehen, ob wir etwas davon in unsere Programmierlandschaft übernehmen können. Der beschriebene Ansatz geht ja durchaus in Richtung Objektorientierung. So wie ich es verstehe, wird ein Modul als Klasse und die beinhalteten Prozeduren als Methoden der Klasse betrachtet. Wir versuchen das so ähnlich zu machen, allerdings wird die Bindung der Methoden zu ihrer Klasse nicht durch Modulerstellung sondern durch Namenskonvention geregelt.
Vielen Dank soweit.

[BenderD]

So wie ich es verstehe, wird ein Modul als Klasse und die beinhalteten Prozeduren als Methoden der Klasse betrachtet. Wir versuchen das so ähnlich zu machen, allerdings wird die Bindung der Methoden zu ihrer Klasse nicht durch Modulerstellung sondern durch Namenskonvention geregelt.
Vielen Dank soweit.

... die Analogie ist erst mal richtig erkannt. Die Procedures (Methoden) sind allerdings durch den gemeinsamen Zustand des Obejktes miteinander verbunden, den sie nach außen darstellen, oder von außen aufgerufen modifizieren können - und das kann man nicht durch Namens Konventionen abbilden.

Design heißt in diesem Sinne das äußere Verhalten eines Objektes vollständig zu beschreiben (in den Prototypen der Procedures/Methoden) und je vollständiger die Beschreibung, umso einfacher die Implementierung (keine rebinds).

D*B