Objektverifizierung nach Erzeugung / Installation

[Pikachu]

Du kannst die Datei in einem CL-Programm mittels DCLF festlegen und dann die einzelnen Datensätze mit RCVF lesen. Informationen zu den einzelnen Objekten kannst du dann mit RTVOBJD auffinden. Eine Möglichkeit für einen direkten Objektvergleich ist mir jedoch leider nicht bekannt.

[Matthias182]

Hallo,

ja an eine ähnliche Lösung hatte ich auch schon gedacht, aber welcher Wert definiert ein Objekt unabhängig von der Objektart als eindeutig?

[Fuerchau]

Ein Objekt kann nur incl. der Objektart eindeutig sein.
Du kannst eben ein Programm, eine Datei oder Datenbereich gleich benennen.
Einzig die Objektart macht sie dann eindeutig.

[Pikachu]

Ein Objekt ist durch seinen Namen und seine Objektart innerhalb einer Bibliothek eindeutig erreichbar. Dies gilt auch für Objekte in der Bibliothek QTEMP, von der es für jeden Job eine eigene gibt, und die intern unterschiedlich heißen.

[Matthias182]

Das mit der Eindeutigkeit des Objekts ist mir klar, aber wenn ich zwei Objekte habe, gleicher Name und gleiche Objektart.

Wie kann dann verlässlich herausfinden, ob diese Objekte identisch sind oder nicht? Und genau das dann unabhängig davon, ob es ein Program, eine Datei oder eine Datenbereich ist?

[Fuerchau]

Da gibts leider keine Standardmöglichkeit.
Da man z.B. an die Daten eines PGM-Objektes mit keinem API herankommt, hilft hier nur ggf. die Sourceinformation auszulesen (bei ILE je Modul) und das Quelldatum zu prüfen. Eine Garantie ist das sicherlich nicht.

[Matthias182]

nein, das ist wirklich nicht zu 100% verlässlich.

Bei Dateien könnte man aber doch sicher den Format Level Indentifier nutzen, oder? Bei Programmen gibt keine solche ID, oder?

Es gibt doch aber heute schon Programme, welche die Releaseverteilung steuern. Weiß jemand von euch, wie diese Programme sicherstellen, dass sie das richtige Objekt installiert haben?

[BenderD]

Vorsicht mit den FormatLevel IDs, die sind mit DDS fast verlässlich und bei SQL erstellten Dateien kompletter Schlunz!

Bei Servicprogrammen gibt es noch sogenannte Signatures, die aber keine sind und auch zur Kategorie Schlunz gehören.

Entsprechende Tools setzen an den Erstellungsquellen an und stellen sicher, dass Anwendungen und Installationen in Bezug auf ein Regelwerk mit den Quellen konsistent sind. Das lässt sich im wesentlichen auch mit Homegrown Tools sicher stellen und prüfen. (Compiles müssen reproduzierbar sein, Abhängigkeiten müssen mit compiliert werden und die Timestamps der Erstellung müssen größer als die Änderungstimestamps der Quellen sein).

D*B


D*B

nein, das ist wirklich nicht zu 100% verlässlich.

Bei Dateien könnte man aber doch sicher den Format Level Indentifier nutzen, oder? Bei Programmen gibt keine solche ID, oder?

Es gibt doch aber heute schon Programme, welche die Releaseverteilung steuern. Weiß jemand von euch, wie diese Programme sicherstellen, dass sie das richtige Objekt installiert haben?

[Matthias182]

Hallo,

das leuchtet mir nun ein. Allerdings brauche ich noch ein paar mehr Infos.

Wie sieht es aus mit der FormatLevel ID, wenn ich eine DDS Datei nachträglich per SQL ändere? Was passiert mit der ID?

Rein SQL erstellte Dateien sind derzeit nicht betroffen.

Wie sieht es aus, wenn ich auf die Quelle ganz verzichten möchte / muss? Gibt es dann einen Weg für einen sinnvollen Abgleich?

[BenderD]

vielleicht beschreibst du mal ein wenig genauer, was du da treibst und was du erreichen willst???

Hallo,

das leuchtet mir nun ein. Allerdings brauche ich noch ein paar mehr Infos.

Wie sieht es aus mit der FormatLevel ID, wenn ich eine DDS Datei nachträglich per SQL ändere? Was passiert mit der ID?

Rein SQL erstellte Dateien sind derzeit nicht betroffen.

Wie sieht es aus, wenn ich auf die Quelle ganz verzichten möchte / muss? Gibt es dann einen Weg für einen sinnvollen Abgleich?

[Matthias182]

Also, wir lassen extern von einem Unternehmen eine Applikation entwickeln. Diese wird über ein Tool, das von der Firma entwickelt wurde, den gesamten Installationsprozess abdecken.

Allerdings liegt die Verantwortung dafür bei mir. Jetzt gab es immer wieder Probleme mit Installationen, die aber zu keinem Fehler geführt haben.

Daher haben wir entschieden, selbst eine Lösung zu suchen, mit der wir die korrekte Installation prüfen können.

Ich hoffe, das beschreibt mein Problem ein wenig besser.

[Fuerchau]

Bei einer Installation wird immer das aktuelle Objekt kopiert.
Wenn die Kopie fehlschlägt (RSTxxx, CRTDUPOBJ) gibts eine CPF-Nachricht.
Gibts keine Fehler, ist die Installation korrekt (eine Delta-Installation empfiehlt sich nur bei PTFs und auch da wird das alte durch das Neue ersetzt).

Bei Dateien muss man ggf. die Quelle mitliefern und kann per CHGPF mit Quelle das Objekt neu erstellen.

Es gibt viele Methoden, daher gibts auch meist Installationsanleitungen.