Übersicht über logische Dateien

[K.Schuricht]

ohne Werbung zu machen, aber kann das Tool FileAccess auch nur empfehlen !!

Es wird Dir beim Arbeiten eine sehr große Hilfe sein.
Eine Testinstallation ist glaub ich möglich.


Gruss Kai

[mwithake]

Warum schreibst Du Deine Programme nicht sofort mit SQL, dann brauchst Du Dir bei einer Datei mit über 100 LF überhaupt keine Gedanken über logische Dateien machen! Läuft sowies wesentlich besser als Lesen per LF.

[loeweadolf]

Warum schreibst Du Deine Programme nicht sofort mit SQL, dann brauchst Du Dir bei einer Datei mit über 100 LF überhaupt keine Gedanken über logische Dateien machen! Läuft sowies wesentlich besser als Lesen per LF.

Gerade auch bei SQL ist der Zugriffspfad sehr wichtig. Auch hier muss man sich Gedanken machen bzgl. log. Dateien bzw. Indizes.

[Fuerchau]

Ja schon, aber gerade das ist ja wesentlich einfacher.
Einfach im Debugmodus testen, Joblog analysieren und erst dann ggf. Index anlegen (obwohl er den dann auch nicht immer nimmt).

Bei nativen Zugriffen muss ich mir leider VORHER über LF's Gedanken machen.
Bei SQL's meistens HINTERHER oder sogar erst, wenn's beim Kunden nicht so performant ist (weil der ja mehr Daten hat).
Dann kann man immer noch optimieren ohne die Programme anpassen zu müssen.

[loeweadolf]

Ja schon, aber gerade das ist ja wesentlich einfacher.
Einfach im Debugmodus testen, Joblog analysieren und erst dann ggf. Index anlegen (obwohl er den dann auch nicht immer nimmt).

Bei nativen Zugriffen muss ich mir leider VORHER über LF's Gedanken machen.
Bei SQL's meistens HINTERHER oder sogar erst, wenn's beim Kunden nicht so performant ist (weil der ja mehr Daten hat).
Dann kann man immer noch optimieren ohne die Programme anpassen zu müssen.

Dann gehöre ich wohl zu der austerbenden Art von Spezies, die sich vor dem Einsatz beim Kunden Gedanken machen, um nach Möglichkeit Reklamationen zu vermeiden.
:-)

[B.Hauser]

Hallo,

Bei nativen Zugriffen muss ich mir leider VORHER über LF's Gedanken machen.
Bei SQL's meistens HINTERHER oder sogar erst, wenn's beim Kunden nicht so performant ist (weil der ja mehr Daten hat).

Auch bei SQL sollte man sich vorher (und nicht erst hinterher) Gedanken über die Zugriffswege machen, um von vornherein Performance-Problemen soweit wie möglich aus dem Weg zugehen.
(Proaktive Indexing Strategie)

Es kann natürlich vorkommen, dass aufgrund der unterschiedlichen Datenkonstellationen oder unterschiedlichen Release-Ständen auf Echt- und Test-Maschinen verschiedene Zugriffswege verwendet werden. Im Extremfall kann das sogar dazu führen, dass auf der Test-Maschine ein Zugriffsweg gefunden wurde, während der Optimizer sich auf der Echt-Maschine für einen Table-Scan entscheidet.
(Reaktive Indexing Strategie)

Beim Einsatz von SQL sollte man halbwegs verstehen, wie die Query Engines arbeiten und wann welche Query Engine eingesetzt wird. Viele Performance-Probleme kommen außerdem daher, dass SQL-Statements so gestaltet werden, dass der Optimizer überhaupt keine Chance hat einen Index zu verwenden. (z.B. Zugriff über relative Record-Nr. oder die Verwendung von skalaren Funktionen auf der linken Seite der Vergleichsoperatoren in den Where-Bedingungen)

Mit zunehmendem Einsatz von SQL, sind die Zeiten, in denen kein Datenbanken-Administrator notwendig war vorbei. Selbst IBM empfiehlt inzwischen, dass jemand regelmäßig ein Auge auf die (SQL-)Performance hat, der gegebenenfalls neue Zugriffswege (geschlüsselte logische Dateien oder SQL Indices) anlegt, bzw. nicht mehr benötigte Zugriffswege löscht. Es gilt zu bedenken, dass jeder zusätzliche Zugriffsweg Performance kostet, d.h. bei jedem Insert, Update oder Delete eines Datensatzes in der zugrundeliegenden physischen Datei (oder SQL Tabelle) müssen alle Zugriffswege aktualisiert werden.


Birgitta

[BenderD]

Hallo,

das ist ja nicht verkehrt, denn gerade hier gilt, dass gutes Design durch einfache Programmierung belohnt wird und Probleme (z.B. Performance) ihre Ursachen in Huddel Design haben. Konsequente Normalisierung der Datenbank und anlegen aller daraus resultierenden Constraints und der fachlich begründeten (unique) Constraints führen dazu, dass die allermeisten Zugriffspfade damit bereits angelegt sind. Wenn man jetzt noch die Datenbankzugriffe in eine eigene Zugriffsschicht zusammen fasst, dann hat man sehr überschaubare Verhältnisse, die schnell und effektiv verifiziert werden können, meist reicht dann zur Verifikation schon ein PRTSQLINF für die Serviceprogramme der Zugriffsschicht.
Bei variablen order by Kriterien und Filtern (was mit Rekord Löffel Ekzem garnicht geht!), brauchts dann schon ein wenig mehr, aber auch hier gilt, gutes Datenbank Design hilft immens, normalisierte Tabellen haben selten mehr als 10 oder 15 sinnvolle Zugriffspfade und eine vernünftige Teststrategie (Stichwort QS) mit hinreichender Abdeckung und Produktions nahen Datenbeständen (auch vom Volumen!) sollte da Lücken in den meisten Fällen aufdecken.

mfg

Dieter Bender

Dann gehöre ich wohl zu der austerbenden Art von Spezies, die sich vor dem Einsatz beim Kunden Gedanken machen, um nach Möglichkeit Reklamationen zu vermeiden.
:-)

[mahones]

Jetzt möchte ich in einem Dialog eben diese Datei nach verschiedenen Kriterien / Bedingungen, etc anzeigen.

Aber beim Zugriff auf eine logische Datei (über die QADBKFLD) kommt der Fehler:

E/A-Fehler CPF5029 in KEYSLF1 erkannt (C G S D F).
(wobei KEYSLF1 die logische Datei ist).

Als Nachrichtentext kommt dann im QPPGMDMP:

Datenzuordnungsfehler in Teildatei KEYSLF1.

Woran kann das liegen, bzw. wie kann ich das vermeiden?
IRgendwo habe ich etwas gefunden, dass diese Meldung bedeutet, dass NULL-Werte vorhanden sind!?

€dith hat herausgefunden, dass ich beim Umwandeln die Option "ALWNULL" auf *YES setzen kann...und schon läuft es ^^

[mahones]

Jetzt hole ich mir mit DSPFD die Information dazu, ob die logische Datei auch zu der vorgegebenen physischen gehört.

Beim Aufruf des folgenden CL-Programms erhalte ich nun die Meldung:

Nachricht . . . : (C D I R) CPF3084 von TOOLPF2 bei 600 empfangen.

---
TOOLPF2:
PGM PARM(&LIB &DATEI)
DCL VAR(&LIB) TYPE(*CHAR) LEN(10)
DCL VAR(&DATEI) TYPE(*CHAR) LEN(10)

CLRPFM FILE(LIB01/OUTFILE)
DSPFD FILE(&LIB/&DATEI) TYPE(*ACCPTH) +
OUTPUT(*OUTFILE) OUTFILE(LIB01/OUTFILE)
---

Woran liegt das nun wieder? Dazu finde ich leider keine sinnvolle Beschreibung / Lösung...

[kuempi von stein]

Wird wohl so sein, dass LIB01/OUTFILE beim ersten Aufruf noch nicht existiert?

Setz nen MONMSG hinter dem CLRPFM und gut ists.

k.