Aufbau des Zugriffspfads beim CRTLF unterdrücken

[Pikachu]

Falls sich die logische Datei nur auf Dateien in einer einzigen Bibliothek beziehen, könntet ihr Kopien der entsprechenden physischen Dateien ohne Inhalt in eine andere Bibliothek legen und die logischen Dateien zuerst dort anlegen. Später könntet ihr sie dann (mit der richtigen Bibliotheksliste!) in die gewünschte Bibliothek kopieren.

Nachtrag:
Eventuell hilft euch auch der Befehl EDTRBDAP (Zugriffspfade wiederherstellen).

[Matthias182]

Ok, verstanden.

Also gibt es keine Möglichkeit das über den CRTLF command zu steuern.

Danke.


Gruß
Matthias

[Matthias182]

Ich glaube das kopieren ist auch noch nicht ganz der richtige Schritt.

Meine Situation ist wie folgt:

Ich habe eine physische mit Daten in eine Worklib gestellt.

Nun erstelle ich die Physische (mit Änderungen) neu.

Nun muss ich sowohl die Logischen erzeugen, als auch die Daten in die neue Physische kopieren.

Egal in welcher Reihenfolge ich das tue, der Pfad wird immer aufgebaut, sowohl beim CRTLF als auch beim CPYF.

Wie kann ich den Aufbau des Pfads komplett unterdrücken und später separat anstossen.


Gruß
Matthias

[Fuerchau]

Nunja, wozu soll das gut sein ?

Tipp:
Wenn du einen CHGPF mit Source machst, erledigt die Kopiererei das System für dich. Die LF's werden automatisch mit geändert.

[UFK]

Der richtige Parameter wäre auch nicht *DLY sondern eher *REBLD oder *NONE oder so. Man kann von *REBLD aber (glaube ich) nicht mehr zurück auf *DLY.

Ich glaube, ich habe diese Klippe schon mal umschifft, indem ich eine LF ohne LFM's (logische Teildateien) erstellt habe, und später nur ADDLFM ausgeführt habe. Das war aber lange vor Relase 5. Vieleicht geht es heute auch anders, oder nicht mehr, probiert doch mal RMVM und ADDLFM bei einer LF aus ...

[UFK]

Der richtige Parameter wäre auch nicht *DLY sondern eher *REBLD oder *NONE oder so. Man kann von *REBLD aber (glaube ich) nicht mehr zurück auf *DLY.

Ich glaube, ich habe diese Klippe schon mal umschifft, indem ich eine LF ohne LFM's (logische Teildateien) erstellt habe, und später nur ADDLFM ausgeführt habe. Das war aber lange vor Relase 5. Vielleicht geht es heute auch anders, oder nicht mehr, probiert doch mal RMVM und ADDLFM bei einer LF aus ...

[Fuerchau]

Wichtig ist die Abhängigkeit vom UNIQUE-Schlüsselwort.
*DLY verzögert zwar die Wartung, wenn die LF aber UNIQUE ist, muss natürlich bei jedem Insert/Update der Schlüssel geprüft werden.
Ist die LF nicht UNIQUE, wird die Wartung bei jedem Open für die neu hinzugekommenen/geänderten Schlüssel durchgeführt.

*REBLD ist bei UNIQUE nicht erlaubt, führt aber dazu, dass beim Open der Pfad aufgebaut und beim letzten Close sofort wieder gelöscht wird.

*NONE gibt's gar nicht.

Die Teildatei später hinzuzufügen geht, wenn man sich sicher ist, dass bei UNIQUE auch tatsächlich nur eindeutige Schlüssel vorhanden sind.
Ist dies nicht der Fall, wird ADDLFM mit MONMSG abgelehnt.

Wenn es nur darum geht, die PF zu modifizieren, kann man mittels CHGPF ... SRCFILE(MYLIB/QDDSRC) SRCMBR(MYFILE) automatisch alle abhängigen LF's neu aufbauen lassen (Ausnahme Join's, da hier explizit Felder genannt werden).

[Matthias182]

Hallo Leute,

ja, den Grund, warum wir das im Moment so machen, versteht wohl keiner mehr. Ist wohl eher historisch bedingt.

Der Typ den MAINT Type auf *REBLD zu stellen ist schon mal gut. Damit wird zumindest der Pfad nicht aufgebaut.

Leider kommen dann aber relativ schnell die Datenbank Server (QDBSRV04 bzw. QDBSRV05) und bauen den Pfad selbstständig auf. Bei der Anzahl an Logischen, die da betroffen sind, dauert das ewig, bis wir wieder produktiv sein können.

Ich würde gerne mehr als zwei Jobs in einer separaten JOBQ/SBS nutzen, um die Pfade aufzubauen. Parallel natürlich. Ich denke dies sollte schneller sein, als wenn ich auf die Server warte.

Gibt es eine Möglichkeit zu steuern, dass die Server die Dateien nicht greifen? Und wie kann ich das Aufbauen des Pfads manuell anstoßen, ohne ein Open auf die Datei zu machen?


Gruß
Matthias

[Pikachu]

Mit dem Befehl EDTRBDAP (Zugriffspfade wiederherstellen) läßt sich steuern, was diese beiden Jobs machen.

Eventuell hilft euch auch der Befehl EDTRBDAP (Zugriffspfade wiederherstellen).

[Fuerchau]

Soweit ich das sehe (laut Doku), hilft dieser Befehl nur bei kaputten Zugriffspfaden:

Zugriffspfade wiederherstellen - Hilfetext

Die Anzeige "Zugriffspfade wiederherstellen" zeigt den Namen der
Teildateien an, die über ungültige Wartungszugriffspfade mit
direktem oder verzögerten Zugriff verfügen:

In dieser Anzeige kann der Zugriffspfad für eine bestimmte Teildatei
wiederhergestellt werden. Der Zugriffspfad für eine Teildatei wird
als ungültig markiert, wenn das System abnormal beendet wird,
während die Teildatei benutzt wird.

Dateien mit aufgezeichneten Zugriffspfaden und Dateien mit
Wiederherstellung des Zugriffspfads werden in der Anzeige
"Zugriffspfade wiederherstellen" nicht aufgeführt.

Wahrscheinlich hilft tatsächlich nur die Lösung, die LF's einfach später wieder zu erstellen.
Allerdings ist die parallele Zugriffspfadwartung beim CPYF meist effektiver.

Prüf doch einfach mal, ob da ggf. FRCRATIO(1) bei den Dateien eingestellt ist. Ggf. ist das eher die Ursache.

Ich helfe mir da meist mit:
chgpf ... frcratio(*none)
cpyf
chgpf ... frcratio(Ursprungswert)

Der CPYF läuft dann u.U. um Faktoren schneller.

[Matthias182]

Der Wert für FRCRATIO ist bei uns standardmäßig auf *NONE gesetzt, da wir Journale auf den Dateien aufgesetzt haben.

Sehe ich das richtig, dass es keine Möglichkeit gibt, den Zugriffspfad kontrolliert zu erstellen?

[UFK]

Der Wert für FRCRATIO ist bei uns standardmäßig auf *NONE gesetzt, da wir Journale auf den Dateien aufgesetzt haben.

Sehe ich das richtig, dass es keine Möglichkeit gibt, den Zugriffspfad kontrolliert zu erstellen?

Ich hab hier keine AS400, aber ich glaube, es gibt da einen Parameter der das Recovery-Verhalten beschreibt, und der kann auf NONE oder so gesetzt werden.

Wenn man öfters riesengroße Dateien mit Zig-Mio Satensätzen bekommt, und indexieren muß, merkt man schnell, daß CPYF und ein mit IMMED geführter Index, besonders natürlich ein UNIQUE-Index, ein arges Hinderniss darstellt.

Deswegen mein Tip: Die LF's ohne Member erstellen, und das Member erst nach Abschluß in einer eigenen CL-Routine hinzufügen. Wenn sich viele Sätze (> 50 % der Daten) ändern, würde ich die LF-MBR's per CL entfernen, und sie zu passender Zeit wieder hinzufügen. Ein Vorteil ist, daß dies ohne DDS geht, und die Datenbankstruktur im Prinzip bestehen bleibt. Ein anderer Vorteil ist, daß man selber kontrollieren kann, welcher Index zuerst erstellt werden sollte, weil er von den anderen am besten geshared werden kann, denn wenn man es der Recovery-Automatik überläßt, werden u.U. Indizes auch redundant gebildet (es können z.B. mehrere auf parallel gebildet werden, die entbehrlich sind, wenn man den Prozeß besser kontrolliert)

Ich hatte mir auch ein Verfahren gebildet, um die ungewollte "Wiederherstellung" gesicherter und zurückgeladener Indizes zu verhindern, was ja überflüssig ist, wenn sie sowieso mitgesichert wurden. Man kann das alles per Programm kontrollieren, es ist nur mühesam dahin zu kommen. Also Jungs und Mädels, ich sage Euch, es geht (irgendwie), nur nicht aufgeben ...