Aufbau des Zugriffspfads beim CRTLF unterdrücken

[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