Erst im Laufe von Tests stellt man bisweilen verwundert fest, dass die Zugriffe über die logischen Dateien merkwürdigerweise nicht auf die Datensätze treffen, die man nach einem Blick in die physische Datei erwarten würde. Besonders irritierend ist es, wenn ein Debug auf den Lesezugriffen des zu testenden Programms gänzlich andere Daten liefert, als die in der physischen Datei zu sehenden Schlüsselfelder vorgegeben.
Spätestens jetzt sollte man sich den Zugriffspfad der verwendeten logischen Datei genauer ansehen. In der Regel wird man dann feststellen, dass die basierende physische Datei nicht in der Testbibliothek liegt, sondern sich die logische Datei auf die physische in der Originaldatenbibliothek bezieht. Dumm gelaufen …
Auf den ersten Blick überrascht dies, aber eine genauere Betrachtung der Funktionsweise des Befehls CRTDUPOBJ zeigt, dass zumindest hier kein Bug im Betriebssystem vorliegt.
Das Problem tritt in der Regel dann auf, wenn physische und zugehörige logische Dateien mit einer identischen Zeichenkette anfangen, aber die physische Datei bei alphabetisch aufsteigender Sortierung nach den logischen Dateien aufgelistet wird.
Der CRTDUPOBJ-Befehl arbeitet für logische Dateien grundsätzlich so, dass der Zugriffspfad nur dann über die physische Datei der Testbibliothek aufgebaut wird, wenn diese zum Zeitpunkt der Objektduplizierung dort bereits existiert. Ist dies nicht der Fall, wird der Zugriffspfad immer über die physische Datei der Bibliothek erstellt, auf die sich auch die logische Datei der Quell-Bibliothek bezieht.
Damit unterscheidet sich die Erstellung der logischen Datei per CRTDUPOBJ von der Erstellung aus DDS-Anweisungen insofern, als dass die Bibliotheksliste des erstellenden Jobs keine Rolle spielt.
Beim Erstellen von Testbibliotheken ist es deshalb grundsätzlich ein gute Idee, erst alle physischen Dateien zu erstellen und dann die logischen.
Ähnliche Artikel:
