Prüfen, ob ein Objekt existiert

[dschroeder]

Klar, das Feld WHOTYP gibt es bei mir auch. Aber das ist der Typ der verwendeten Objekte. Es geht mir um den Typ der verwendenden Objekte. Es geht mir um die "linke" Seite der Datei. Also um die Typen von WHLIB und WHPNAM.
Wir haben da eine Anwendung, mit der wir Programmreferenzen suchen können. Die Outfile von DSPPGMREF ist bei uns eine permanente Datei, die automatisch vom Wandlungsprogramm aktualisiert wid. So haben wir immer eine aktuelle Programmreferenzdatei, ohne jedesmal einen DSPPGMREF ausführen zu müssen. Aber wenn ein Programmierer ein Objekt einfach per CMD löscht, wird die Programmreferenzdatei natürlich nicht aktualisiert.
Deshalb der Aufräumjob.

Dieter

[Pikachu]

Wie wärs mit dem Feld WHSPKG?

[Fuerchau]

Dann ist die Liste der betroffenen Objekte genau 2 Einträge lang *PGM, *SRVPGM, da DSPPGMREF eben nur Programme bearbeitet.

Dann kannst du ja doch einen DSPOBJD der PGMLIB's machen und per SQL einen
delete from mypgmref where not exists (select * from myobjlst where fromnameundlib = tonameundlib)

[Pikachu]

Es könnte (je nach Release) auch ein SQL-Paket, ein Modul oder eine Query-Definition sein.

DSPPGMREF Objektart

[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