View Full Version : Objektverifizierung nach Erzeugung / Installation
Matthias182
06-05-08, 14:16
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?
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.
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
06-05-08, 16:12
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.
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
06-05-08, 16:27
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.
Das musst du je nach Objektart entscheiden, eine generelle Lösung gibt es nicht.
holgerscherer
06-05-08, 20:09
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
Matthias182
07-05-08, 08:48
Hallo,
ich habe noch eine weitere Frage.
Ich habe beim recherchieren gelesen, dass die iseries für jedes Ojbekt eine eindeutige ID im Dateisystem vergibt. Zunächst, stimmt das?
Und dann, kann man diese ID als Referenz nutzen?
wenn man denn die Adresse im single level store als ID bezeichnen will, dann stimmt das - als Referenz benutzen kann man die schon, aber weiterbringen tut einen das in diesem Kontext auch nicht.
D*B
Hallo,
ich habe noch eine weitere Frage.
Ich habe beim recherchieren gelesen, dass die iseries für jedes Ojbekt eine eindeutige ID im Dateisystem vergibt. Zunächst, stimmt das?
Und dann, kann man diese ID als Referenz nutzen?