Objektverifizierung nach Erzeugung / Installation

[Matthias182]

Hallo,

ich bin auf der Suche nach einer einfachen (CL) Lösung, um Objekte, die mit einem Software-Release auf der iseries erstellt / kopiert / kompiliert
wurden nach der Installation zu verifizieren.

Soll heißen, die Objekte kommen aus einer Bibliothek, liegen dort aber unter einem anderen Objektnamen vor. Dieser besteht aus einer
fortlaufenden Zeichenfolge.

Als Verknüpfung gibt es lediglich eine physische Datei, die u.a. die Spalten 'Objektname' und 'installiertes Objekt' enthält.

Gibt es eine Möglichkeit anhand dieser Daten nach der Installation zu prüfen, ob jedes Objekt auch dem gelieferten Objekt entspricht?


Gruß

Matthias

[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?

[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.

[BenderD]

als erstes bräuchtest du eine Definition, was denn identisch in diesem Kontext sein soll!!!
- dasselbe Objekt?
- einer ist Clon des anderen?
- aus derselben Quelle mit demselben Command erstellt?
- aus derselben Quelle erstellt?
D*B

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?