Änderungsstand von Queries automatisch updaten

[Michael Steibert]

Was ist schlimm an meinem Vorschlag ?

Holprige, alte Lösung, aber nicht so schlimm wie der letzte Vorschlag

[Spateneder]

Das war schon augenzwinkernd gemeint. Aber die Antwort gibst Du ja selbst schon, indem Du die Einschränkungen auflistest.
Letztendlich tüftelt man auf diese Weise mit viel Aufwand ein Programm zusammen, das dieselbe Problematik erzeugt wie LVLCHK(*NO).
Ergebnis: Alle Queries funktionieren, außer denen, die nicht funktionieren.
Das ist sicher irgendwie pragmatisch, wenns mals brennt, aber eine Problemlösung sieht eigentlich anders aus.
Ich finde die VT-Lösung ja auch nicht optimal, aber immerhin kann man bei dieser Lösung aus dem Joblog die Queries herausfinden, bei denen man etwas tun muß.
Also nix für ungut.
Gruß
M. Spateneder

[Michael Steibert]

OK. Es kommt wie immer auf die konkrete Anforderung an. Meistens kommen Felder hinzu.
Die LevelCheck-Problematik bei Querys kann für unkritische Dateiänderungen voll,
für kritische halb automatisiert werden.

Eine Tabelle "MACHTNIX" mit unkritischen Dateien kann man über DSPFFD FILE(MYLIB/*ALL) OUTPUT(*OUTFILE) vor und nach Release-Wechsel leicht erstellen.

Das Programm "UPDQRYDFN" testet also auf FMT-Übereinstimmung Query/DATEI.
Bei Nichtübereinstimung wird upgedatet, wenn die Datei in Tabelle "MACHTNIX" steht,
ansonsten Printout Query-Name.

Von den 500 Querys sind dann i.d.R. die meisten mit Änderungsbedarf komplett erledigt,
die restlichen stehen auf einer Liste, nicht nur für dieses Mal.
Der Entwicklungsaufwand für ein Programm "UPDQRYDFN" ist vergleichsweise gering.
Der Aufwand liegt in der Analyse der Ablagestrukturen in *QRYDFN, aber die sind hier gegeben.

[Pikachu]

Etwa 500 Querys jeweils öffnen und gleich wieder zu schließen ist in 30er Stößen (so viele kann man im WRKQRY gleichzeitig auswählen) manuell doch eingermaßen schnell (in 17 Durchgängen) zu schaffen. Wer benötigt da ein Programm?