Objektverifizierung nach Erzeugung / Installation

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

[BenderD]

da kann nur folgendes tun:
- beten (wenn man gläubig ist)
- glauben (wenn man leichtsinnig ist)
- die Verantwortung an das externe Unternehmen geben (wenn man einen guten Vertrag hat)

da kann doch von falscher Erstellung, über inkonsistente Beziehungen bis hin zu Berechtigungen und zweitbesten Änderungen alles krumm sein - oder eben auch nicht.

D*B

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.

[Matthias182]

ja, schon, aber ich will ja auch nur eine generelle Prüfung.

Wir haben in der Regel pro Installation zwei, drei Objekte, die betroffen sind, also nicht so schlimm.

Ich brauche hier nur eine Möglichkeit diese einfach zu filtern.

[holgerscherer]

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.

Unabhängig was da wo installiert wird, sollte sich auch die externe Firma an den SAV/RST-Befehlen orientieren. Denn durch die Verwendung dieser ist sichergestellt, dass
- das Objekt integer ist
- und zum Release passt

Nimm Dir als Beispiel unterschiedliche Releasestände auf den Zielsystemen an. Die Firma kompiliert für V5R3 auf einer 270er, Du holst die Objekte unter V5R4 auf einer 800 zurück, die als Verteilsystem dient. Und dann wird wieder ein Savefile erstellt, dass dann auf einer Power520 unter V6R1 zurückgeladen wird. Glaub mir - die Objekte auf der Power520 haben auf den ersten Blick nicht unbedingt viel mit den Objekten auf der 270er gemeinsam. Drücken wir es mal salopp aus: "Der Weg kann anders sein, das Ziel ist das gleiche".
Somit kannst Du es vergessen, nach irgendwelchen Quersummen zu arbeiten, oder Objektgrössen.

Meines Erachtens ist (wie bereits angesprochen) der einzig interessante Weg:
- in ein File werden von den compilierten Originalobjekten die Erstellungsdaten gespeichert
- auf dem Zielsystem wird nach der Installation geprüft, ob das Objekt das gleiche Erstellungsdatum/Zeit hat. Wenn nicht: dann ists ein altes

-h