Gem. Nutzung von Zugriffspfaden

[Zehetner]

Hallo,
ich habe hier 2 idente 400er. Auf der einen ist ein Join-File über mehrere Phy. Dateien.
Nach dem Save und Restore auf der 2. 400er finde ich im DSPFD für das Join-File folgenden Zeilen:
------------------------------------------------------------
Zugriffspfad gültig . . . . . . . . . . : Ja
Impl. gemeinsame Ben. des Zugriffspfads : Ja
Zugriffspfad aufgezeichnet . . . . . : Nein
Anzahl eindeutiger Teilschlüsselwerte . :
Schlüsselfeld 1 . . . . . . . . . . . : 6
Schlüsselfelder 1 - 2 . . . . . . . . : 691594
Datei, der der Zugriffspfad gehört . . : LIB2/JOINFILE
------------------------------------------------------------
Auf der 1. 400er sieht es so aus:
------------------------------------------------------------
Zugriffspfad gültig . . . . . . . . . . : Ja
Impl. gemeinsame Ben. des Zugriffspfads : Nein
Zugriffspfad aufgezeichnet . . . . . . : Nein
Datum/Uhrzeit der letzten Änderung. . . . : 28.05.08 17:48:02
------------------------------------------------------------

Das ist auch so, wenn ich das Joinfile auf der 2. 40er neu compiliere.
Das Problem dabei ist, daß das Joinfile den Index einer bestehenden Join-Datei verwendet, welche aber über phy. Dateien in anderen Bibliotheken gelegt ist.

Dieses Impl. gem. Ben. des Zugriffspfades dürfte auf einer maschinenspezifischen Einstellung beruhen und nicht auf einer dateispezifischen.

Hilfe!!!


Danke!!

[Fuerchau]

Dies liegt an der Reihenfolge der Erstellungen.
Prüfe mal das Gegenstück.

Wenn eine Join/LF gelöscht wird, die einen verwendeten Zugriffspfad hat, wird dieser an die andere LF gehängt.
Erstellt man nun die LF/Join neu, kann er nun diese mit verwenden. Es besteht kein Grund, den vorherigen Zustand wiederherzustellen (der ja auch nicht bekannt ist).

[Zehetner]

Tja, das Problem dabei ist aber, daß der verwendete Index über ander phy. Dateien (in anderen Bibliotheken) geht, als jener, welchen ich erstellen will.

[Pikachu]

Wird die Join-Datei über DDS oder per SQL erstellt? Sind die physischen Dateien darin qualifiziert angegeben? Falls nicht, wie steht denn die Bibliotheksliste? Auf welchen Dateien basiert denn die erstellte Join-Datei (DSPFD auf die Join-Datei), auf welchen die zurückgespeicherte?

[Zehetner]

Die Datei wird mittels DDS ohne dedizierte Bibliotheksangabe erstellt.
Ich habe 4 phy. Dateien in Lib A und die 4. Datei zusätzlich in Lib B.
Einmal erstelle ich die Join-Datei in Lib A mit LIB A in der LIBL.
dann erstelle ich die Joindatei in LIB B mit LIB B,A in der LIBL.

Die Join-Datei in LIB B verwendet den Index der Joindatei aus LIB A und somit auch nur die phy. aus LIB A.

Komischerweise ist das auf einer 2. identen AS400 (beide V5R4) nicht so.

[Pikachu]

Die Join-Datei in LIB B verwendet den Index der Joindatei aus LIB A und somit auch nur die phy. aus LIB A.

Ich habe das gerade hier ausprobiert: Wenn man mit SQL per SELECT auf die jeweilige Join-Datei zugreift, dann bestehen Sperren auf die entsprechend korrekten physischen Dateien. Außerdem werden in der physischen Datei in LIB B geänderte Daten nur über die zweite Join-Datei anzeigt, welche als einzige der beiden auf dieser physischen Datei beruht. Die Join-Datei über die physischen Dateien in LIB A zeigt den Inhalt der entsprechenden Datei in LIB A an.

Bei beiden Join-Dateien wird beim DSPF jedoch folgendes angezeigt: "Datei, der der Zugriffspfad gehört . . : LIB1/JOINFILE". Die Angaben unter "Basiert auf Datei" sind jedoch wie erwartet und auch korrekt teilweise unterschiedlich.

[Pikachu]

Nachtrag: Eine Join-Datei kann auf der AS/400 für die Schlüsselfelder anscheinend nur Datenfelder aus der ersten physischen Datei beinhalten (siehe DSPMSGD CPD7986). Somit besitzt eine Join-Datei, die dieselbe erste physische, jedoch andere weitere physischen Datei besitzt als eine andere Join-Datei natürlich die gleiche Sortierfolge über dieselbe erste physische Datei und kann deren Zugriffspfad mitbenützen.

[Zehetner]

Hat sich erledigt.

Danke für die prompten Ratschläge.

Es war folgendes:
Nach Aufruf und Beendigung des PGMs, das die Dateien verwendet, waren alle Dateien noch offen. Ich habe zwar ein RCLRSC durchgeführt, aber nicht mit *CALLER.
Also hat er nach einem erneuten Aufruf mit einer anderen LIBL die Dateien in LIB B nicht geöffnet, sondern die der LIB A verwendet.

lG
Otto