Aktualitätsprüfung TEMP-Datei

[Mr.iSeries]

Habe mal eine Frage zu Dateien die vor Programmaufruf in der QTEMP erstellt werden. Wie ist das mit der Aktualitätsprüfung oder fällt die komplett weg? Wenn ich nur im Sourcecode der physischen Datei etwas abändere stürzt dann das Programm ab wenn es aufgerufen wird ohne es vorher nochmals kompiliert zu haben? Wird evtl. auf das Änderungsdatum der Source abgefragt?

[BenderD]

it depends, per DDS erstellte bilden die zur Prüfung verwendete Signatur anhand der Struktur des Transfer Buffers (= record Format); bei SQL wirds crude, da wird das SQL Statement als Text genommen.

D*B

Habe mal eine Frage zu Dateien die vor Programmaufruf in der QTEMP erstellt werden. Wie ist das mit der Aktualitätsprüfung oder fällt die komplett weg? Wenn ich nur im Sourcecode der physischen Datei etwas abändere stürzt dann das Programm ab wenn es aufgerufen wird ohne es vorher nochmals kompiliert zu haben? Wird evtl. auf das Änderungsdatum der Source abgefragt?

[Alexander]

das Änderungsdatum der Source des Program kann man so bekommen:
DSPPGM PGM(CRSSFUR) DETAIL(*MODULE)

[Pikachu]

Ob eine Aktualitätsprüfung erfolgen soll oder nicht, ist eine Eigenschaft der Datei, die man beim Erstellen der Datei (mittels CRTPF) angibt und die man nachträglich ändern (mittels CHGPF) oder überschreiben (mittels OVRDBF) kann.

[Fuerchau]

Ausserdem ist für die Aktualitätsprüfung die Quelle vollkommen unerheblich.

Beim compilieren wird die "Fmt.EbenenID" des verwendeten Satzformates in das Programm kopiert und beim Öffnen geprüft.
Bei Abweichung wird der Open eben abgelehnt.

Natürlich kann man per CHGPF den LVLCHK abschalten.
Werden Felder nur am Ende angehängt, gibts beim Lesen und Ändern keine Schwierigkeiten.
Das Hinzufügen wird dann abgelehnt, wenn die unbekannten Felder ungültige Daten enthalten, was bei Dezimalfeldern immer der Fall sein wird.

Bei SQL stellen sich diese Probleme gar nicht, da hier dieses Konzept unbekannt ist.
Der Open wird dann eben abgelehnt, wenn Felder verschwunden sind, neue Felder sind dem SQL egal.
Beim Insert müssen für die Tabelle nur gültige Defaultwerte definiert sein oder per Trigger korrekt gefüllt werden.

[Mr.iSeries]

Zitat:
Ob eine Aktualitätsprüfung erfolgen soll oder nicht, ist eine Eigenschaft der Datei, die man beim Erstellen der Datei (mittels CRTPF) angibt und die man nachträglich ändern (mittels CHGPF) oder überschreiben (mittels OVRDBF) kann.


Das ist mir schon klar... Die Frage war jedoch wie das bei Dateien abläuft die in der QTEMP vor PGM-Aufruf immer neu erstellt bzw. kompiliert werden... Dann ist das Objekt der PF eigentlich ja immer neuer als das des PGM's... Die Aktualitätsprüfung müsst ja trotzdem greifen oder? Wenn ich z.B. in die Source der PF ein neues Feld einfüge, jedoch die PF nicht erstelle und das PGM auch nicht neu kompiliere was ist dann? Ich dachte eben vor PGM-Aufruf wird die Quellendatei hergeholt und dann in die QTEMP kompiliert aber anscheinend holt er sich die Daten wo anders her.

[Pikachu]

Bei der Aktualitätsprüfung wird die Formatebene der Datei mit der im Programm eingebundenen Formatebene der Datei (zum Zeitpunkt der Programmerstellung) verglichen. Das Erstellungsdatum der Datei ist dabei egal.

[BenderD]

aufs Erstellungsdatum kommt es nicht an, nur auf die Formatebenen ID und die leitet sich bei DDS aus der Struktur des Buffers ab (Folge: gleiche Quelle führt immer zur gleichen Format Ebenen ID, selbst unterschiedliche Dateien können dieselbe Formatebenen Id haben). Programme merken sich beim Compile die Format Ebenen ID der vorgefundenen Datei und solange die zur Laufzeit passt, stimmts.
Bei SQL erstellten Dateien ist das ein wenig anders, da wird der T e x t des SQL Statements in die Formatebenen Id verschlüsselt, was bei Rekord Löffel Ekzem dann zu Problemen führt.
SQL Verwendung in Programmen interessiert sich nicht für Format Ebenen Ids, da wird zur L a u f z e i t Feldweise geprüft, ob die Felder miteinander Typ verträglich sind und gegebenen Falls auch entsprechend gecastet und widrigenfalls nicht ausgeführt!!!

D*B

Zitat:
Ob eine Aktualitätsprüfung erfolgen soll oder nicht, ist eine Eigenschaft der Datei, die man beim Erstellen der Datei (mittels CRTPF) angibt und die man nachträglich ändern (mittels CHGPF) oder überschreiben (mittels OVRDBF) kann.


Das ist mir schon klar... Die Frage war jedoch wie das bei Dateien abläuft die in der QTEMP vor PGM-Aufruf immer neu erstellt bzw. kompiliert werden... Dann ist das Objekt der PF eigentlich ja immer neuer als das des PGM's... Die Aktualitätsprüfung müsst ja trotzdem greifen oder?

[Fuerchau]

Quellen müssen ja zur Laufzeit nicht zur Verfügung stehen.

An Stelle per Quelle und CRT-Befehl ein Objekt ständig neu zu erstellen, würde ich eher CRTDUPOBJ empfehlen.

Ausserdem generiert sich die FMT-Id aus einer Checksumme, die von der Anzahl Felder, Typ und Ausprägung sowie Reihenfolge ergibt.

Solange man also in der Quelle ausser Kommentaren nichts ändert, ändert sich auch an der FMT-ID nichts.

Ein kleiner Fehler ist da allerdings schon dabei.
Der Key einer PF/LF unterliegt nicht der FMT-ID. Ändert man also den Key, fliegt einem das Programm leider erst beim Zugriff und nicht bereits beim Open um die Ohren.

[BenderD]

@Baldur: gilt nur für DDS erstellte Dateien!!!

Ausserdem generiert sich die FMT-Id aus einer Checksumme, die von der Anzahl Felder, Typ und Ausprägung sowie Reihenfolge ergibt.

[Fuerchau]

Auch bei TABLE's habe ich eine FMT-Id, die nach gleichen Kriterien erstellt und bei Native-Open auch geprüft wird.
Natürlich kann ich den LVLCHK auch dort abschalten.

PS:
Übrigens nicht zu verwechseln mit der "Dateiebenen-ID", die nur einen Timestamp in der Form CYYMMDDHHMMSS darstellt und nur informatorischen Wert darstellt.

[Pikachu]

Für SQL gibt's da wohl ein paar PTFs.