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.

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

[BenderD]

dann mach doch mal ein
create table hugo like myTable
und auch mal ein
create table qtemp.otto as (select * from mytable) with no data
oder ändere mal ein SQL Skript ab (sagne wir mal ein Feldname
und vielleicht auch mal ein
create view ddd as select * from mytable

und dann bin ich mal gespannt, ob du das bekommst, was du erwartest?!

Dieter Bender,

der das auch mal geglaubt hat (obwohl sein Urgroßvater bereits aus der Kirche ausgetreten ist)
Ob das ein Bug, oder ein Feature ist und ob das nur zuschlägt wenn man die SQL Möglichkeiten wirklich nutzt, das weiß ich nicht, aber seitdem mir das mal zufällig (stört nicht, weil ich durchgängig mit SQL arbeite) aufgefallen ist, ist das durchgängig so (mit mehr als 10 Group PTF Ständen unter mehreren Releases)

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.