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.  

Ähnliche Artikel:

Objektsperre – wer war es?

Bei Stapelverarbeitungen läuft bisweilen ein Batchjob auf eine Objektsperre, meistens bei Dateien. Geschieht dies unter Tage, lässt sich mit dem Befehl WRKOBJLCK und ein paar weiteren Tastendrücken feststellen, welcher andere…

WRKLNK und unsichtbare Verzeichnisse

Gelegentlich kann man sich an einen konkreten Verzeichnispfad im IFS nicht genau erinnern und greift deshalb zu dem Befehl WRKLNK, um sein Gedächtnis mit Auswahl 5 schrittweise auf den richtigen…

FlashCopy und IBM i

In immer mehr Kundenumfeldern wird das Thema Offline-Backup zunehmend schwieriger, weil entsprechende Zeitfenster nicht zur Verfügung stehen. Bei immer größeren Datenmengen ist auch ein traditioneller Restore von einem Band in…