Prüfen, ob ein Objekt existiert

[BenderD]

edit (nicht genau gelesen)
Anmerkung: ich würde das noch um DSPMOD *IMPORT und dspmod *EXPORT ergänzen, dann kriegt man noch die Prozedur Abhängigkeiten.

D*B

[dschroeder]

Vielen Dank an alle.
Wir machen das jetzt so, dass wir nur *PGM und *SRVPGM prüfen. Alle anderen Arten sind für uns nicht relevant, da uns nur wirkliche Programmreferenzen interessieren. Die Prozedurabhängigkeiten sind für uns nicht entscheidend, da wir pro Programmobjekt immer nur eine exportierte Prozedur haben.

Nochmals Danke,
Dieter

[BenderD]

... wie seid ihr denn auf diese abstruse Idee gekommen? Wenn man nur einen Entry Point hat, dann sind Hundsnormale Programme die bessere Wahl - da erspart man sich das ganze Gedöns mit binden und allem drum und dran.

D*B

[dschroeder]

Die Vorteile von Serviceprogrammen sind für uns:
- sprechende (lange) Namen
- Möglichkeit der Einbindung in Vergleichsanweisungen, z.B. if istBerechtigt(kun_nr);
- saubere Parametrierung (genau ein Rückgabewert)

Das andere "Gedöns" haben wir programmatisch gelöst. Für einen Entwickler bei uns ist es null Mehraufwand, ein Serviceprogramm zu schreiben. Unser Compileprogramm erkennt den Source als Serviceprogramm und setzt alle Wandlungsoptionen automatisch. Desweiteren wird automatisch eine Copy-Strecke für den Prototyp generiert und das Programm wird in einer Repository-Datenbanktabelle eingetragen. Wenn man das Serviceprogramm dann später in einem anderen Programm aufrufen will, schreibt man einfach den Aufrufcode hin. Man muss nichts weiter machen. Über ein selbstgeschriebenes Eclipse-Plugin im RDi wird aus dem Repository automatisch die benötigte Copy-Strecke für das Serviceprogramm ermittelt und oben im Code eingetragen.

Ich gebe dir aber natürlich Recht: Wenn wir das alles manuell machen müssten, hätten wir es sicherlich gelassen. Aber wir wollen keine Schwierigkeiten mit Änderungen in Programmsignaturen haben. Deshalb haben wir so viele kleine Programme.

Dieter

[BenderD]

- sprechende lange Namen geht mit Prototypen für Programme ebenso.
Das mit dem eine Procedure = 1 SRVPGM hat allerdings auch gravierende Nachteile:
- es muss Informnation redundant übergeben werden
- Parameterschnittstellen mit zu vielen Parametern
- die steuernden Programme werden mit dem gesamten Informationskontext überfrachtet
Der Hauptvorteil der SRVPGMs gegenüber den Programmen ist eben gerade, dass erstere mehrere Entry Points mit eigenen Schnittstellen haben und sich die Prozeduren Informationen teilen.
Das mit den Programmsignaturen ist ein reines Scheinproblem, das sich mit einem Repository basierten Compile Prozess (wandle alles Abhängige mit!) elementar lösen lässt. Die Schnittstellen getrennter Applikationen (shared Libraries) können ohnehin nur in einem Release Zyklus geändert werden.

D*B

[dschroeder]

OK, für einige Aufgabenstellungen sehe ich durchaus Vorteile. Wir denken mal darüber nach, unser Tooling entsprechend zu erweitern.

Vielen Dank.

[Fuerchau]

Bzgl. der Signaturen gibt es ja unterschiedliche Meinungen.
Meine persönliche ist eben, mit Bindery-Language zu arbeiten, eigene Signaturen zu erstellen und ebenso über Repository o.ä. sicherzustellen, dass nur das nötigste gewandelt wird.
Das OS/400 arbeitet ja ganz genauso denn sonst müsste mit jedem PTF/Release jede Anwendung neu gebunden werden da sich die System-Serviceprogramme (RPG/Cobol/C-Runtimes) ja nun mal ändern.
Dies verhindert eben, dass bei der Ergänzung eines zentralen Serviceprogrammes alle Programme + abhängige Serviceprogramme mit gewandelt werden müssen.
Um die Gesamtumwandlung (die ja durchaus richtig ins Kontor schlägt) zu vermeiden, führt dies eben zu obigen Lösungen die nur eine Prozedur je Serviceprogramm erlauben.

Um Massenumwandlungen zu vermeiden gibt es meiner ganz persönlichen Meinung nach eben nur diese 2 Möglichkeiten:
- obige Lösung mit 1 Prozedur je Serviceprogramm
- BNDDIR's mit eigenen Signaturen so wie es die IBM mit ihrem OS/400 macht

Da kann Dieter noch so dagegen reden .

[B.Hauser]

Binderverzeichnisse haben keine Signatur!

In Binder-Verzeichnissen sind Module oder Service-Programme hinterlegt.

Zur Kompilierungszeit bzw. während des Binder-Schritts werden die Binder-Verzeichnisse duchsucht, ob in den darin gelisteten Objekten die aufgerufenen Prozeduren hinterlegt sind. Wenn ja wird da entsprechende Modul oder die Signatur des Service-Programms in da zu bindende Objekt übernommen.

Mit Binder-Sprache ist es auch möglich mehrere Signaturen für das gleiche Service-Programm zu verwalten, in dem die zuvor exportierten Prozeduren als *PRV-Eintrag in der Binder-Quelle bleiben.
Da das Service-Programm damit sowohl die alte als auch die neue Signatur hat, gibt es auch beim Aufruf von Programmen und Service-Programmen in denen noch die alte Signatur gebunden ist, keine Signatur-Verletzung.

Birgitta

[BenderD]

... eine alte hessische Weisheit sagt:"an de knebscher spiele solle nur de exberrde". Was ich schon für einen Mist über Binder Language gelesen habe, und was ich für einen Unfug gesehen habe, bringt mich dazu Binder Language nur da einzusetzen, wo es erforderlich ist, nämlich bei der Entwicklung von shared Libries, die in fremdem Umgebungen eingesetzt werden - und das machen nur wenige. Für dei Masse von Halb-Experten ist der Recompile halt sicherer (BTW .Net und Java Werkzeuge kompilieren und deployen immer ein ganzes Projekt, da gibt es überhaupt keinen Einzelcompile) und bei Design lastigem Vorgehen - das ich dringendst empfehle - sind Signaturänderungen seltene Ausnahme. Wer ständig Signaturänderungen hat, der hat ernsthafte Mängel im Design!!!

D*B

[Fuerchau]

Das das BNDDIR keine Signatur hat, ist mir auch klar.
Beim Erstellen eines Serviceprogrammes mit Bindarylanguage zwingt mich niemand eine neue Signatur zu vergeben.
Bei vernünftiger Anwendung werden neue Prozeduren immer am Ende hinzugefügt.
Alte Programmaufrufe bleiben erhalten und erzwingen eben keinen Rebind.
Natürlich darf ich die Parameter einer Prozedur nie ändern, aber das galt ja schon immer für OPM-Schnittstellen, ist also überhaupt nichts neues.
Wenn ich mich daran halte, benötige ich nie eine neue Signatur. Auch der Schwachsinn mit *PRV gehört eigentlich verboten.
Die Beibehaltung der Reihenfolge ist zwingend erforderlich, da zur Laufzeit nicht mehr per Name sondern per relativer Nr. in der Liste aufgerufen wird. Eine Parameterprüfung erfolgt nicht!
Erweiterungen kann ich mit *OMMITED-Parametern (am Ende) ggf. durchführen was ich aber besser unterlasse. In .NET/Java/C++ definiere ich überladene Prozeduren mit diversen Parametern, ähnlich wie es ja SQL nun auch kann.
Dies kann ich dann sogar verwenden um eine bestehende Prozedur mit den alten Aufrufen zu belassen und im Inhalt nun die neue Prozedur mit dem/den zusätzlichen Parametern und den Defaults aufzurufen.
Bei der OPM-Programmierung hat man ja eigentlich das selbe getan, warum also nicht auch bei Serviceprogrammen?
Was anderes mache ich mit Überladungen ja nun in anderen Sprachen auch nicht.

Bei .NET wird natürlich ein Projekt kompiliert, aber ein Projekt besteht aus einer Anwendung oder einer DLL.
Zur Laufzeit wird die Version der DLL gebunden, was ich aber durch Manifeste vereinfachen kann.
So kann ich die DLL's separat entwickeln und testen, Versions-Nr'n hochzählen usw.
Allerdings führt .NET und Java eben zur Laufzeit Prüfungen über Aufrufschnittstellen (Namen und Parametertypisierungen) durch um Fehler zu minimieren.

Schlechtes Design gibt es eben überall, so dass es auch dabei knallen kann.

[AG1965_2]

Es hat jeder irgendwo recht. Es kommt auf die (eigene?) Umgebung an.
Wenn man ein riesiges System zu betreuen hat, das nahezu keine Wartungsfenster hat, tue ich mir mit riesigen Deployments schwer, schlicht, weil die Zeit fehlt. Da kommt einem - im designtechnischen Notfall - *PRV durchaus zupass und selbst vergebene Kennungen sind sowieso normal.
Wer damit kein Problem hat, eine kleine Applikation hat, oder es ganz einfach haben will, kann genauso wie in anderen Welten vorgehen und einfach immer alles erstellen, egal, ob es nun notwendig ist oder nicht.
Das Schöne ist, dass uns das System i Beides bietet.