Member reihenfolge

[Fuerchau]

In dieser Folge klappt dies nicht, da dem CRTDUPOBJ der Kontext fehlt.
Aber mach mal CRTDUPOBJ AL* in eine andere Lib, z.B. QTEMP.
In diesem Fall wandert der Bezug von AL01 zu AL in die QTEMP mit, also QTEMP/AL01 => QTEMP/AL.
Der Bezug zur PF wird immer über
1. die PF gleichen Namens in der Ziellib
2. die ursprüngliche Lib
hergestellt.

Ich weiß, das Ganze mag etwas umständlich erscheinen, aber wenn du identische Objekte mit neuen Namen benötigst kannst du
a) das in eine neue Lib (QTEMP) tun und den OVRDBF in QTEMP machen
b) ein Kommando schreiben, dass CRTDUPOBJ XX* in QTEMP macht, per API DSPDBR dann für jedes Objekt einem RNMOBJ mit anschließendem MOVOBJ in die Ursprungslib macht.
c) das Ganze als SQL-Table implementierts, dann geht das per CREATE TABLE xxx as select * from yyy mit folgenden Create Index ...

"State of the Art" wäre Variante c) oder wenn es denn wirklich nur Job-Temporär ist Variante a).
Problematisch wird dies ja immer dann, wenn diese Art von Job parallel mehrfach läuft.

[Robi]

Ich weiß, das Ganze mag etwas umständlich erscheinen,

deswegen die Member Lösung

Variante a fällt aus, das verschiedene Jobs die Daten brauchen (besondere Form der Schnittstelle)

Variante b und c sind heute, auf der grüne Wiese ggf gut aber kommen von der Eleganz und der Geschwindigkeit nicht an die MBR heran.


Meine 'beste' Variante wäre ein zusätzliches Keyfeld, so das ich die Daten duplizieren kann ohne das die 'Echt' Daten betroffen sind und alle OVRDBF wegfallen
Aber alles neu ...

Bleibt die Frage, wodurch sich die Reihenfolge geändert hat!

[Dschainers]

Daten sichern
Datei neu erstellen (mit nur 1 Member, das das auch das *first sein soll)
evtl. zusätzliche Member hinzufügen
alle LF's wieder erstellen
Daten zurückkopieren

Gruß
Dschainers

[Robi]

Moin,
es geht nicht darum den *first wieder richtig zu setzen. Dafür haben wir Programme die die Schnittstelle stoppen, alle falschen member löschen und alles wieder starten.

Ich wüsst nur gerne, was der Kunde gemacht hat um die 'Ordnung' durcheinander zu bekommen.
Uns ist das nicht gelungen. Und der Kunde hat natürlich nix gemacht

[Fuerchau]

QTEMP war ja nur 1 Lösungsvorschlag.
Wie wäre es einfach mit diversen Lib's je Jobtyp?
So viele werden es doch wohl nicht sein.

Ansonsten:
Da das Default-Member einer PF/LF ja eigentlich wie die Datei heißt, kannst du statt *FIRST den Namen der Datei nehmen.

[Pikachu]

Wenn *FIRST beim OVRDBF dasselbe bedeutet wie beim RTVMBRD, dann ist das "Die erste Teildatei in einer nach Datum geordneten Liste".

[Robi]

Die Dateien werden, im 'Normalfall' ohne ovrdbf von ILERPG Pgmmen gelesen.

Da gilt m.E. 'automatisch' lies das Member *first
Lies das Member, das so heist, wie die Datei kann es nicht sein, dann wäre der Fehler nicht aufgetreten.

Das Member, das gelesen wurde war älter als das 'richtige'
Es hatte nur einen Namen der, nach normalem Sort, < als der Orginal Name war.

Das ist aber bei anderen betroffenen Dateien auch so und führte noch nie zu Problemen

Bsp:

Datei ZZ_Datei
Member ZZ_Datei

Per Pgm: ADDPFM AA_Datei
zugriff mit ovr und sql auf das member AA_Datei

Ausschalten des Dialog Pgm = Abbruch des jobs

Nun hat die Datei ZZ_Datei 2 Member
ZZ_Datei und AA_Datei

Jeder Lesevorgang der ILE Rpg Pgmme verwendet ZZ_Datei
(mehrere Monate)

Dann geschied 'irgendwas'

Nun liest der Lesevorgang der ILE Rpg Pgmme plötzlich das alte, hängengebliebene AA_Datei Member.

Gesucht wird das 'irgentwas'


Wie gesagt, > 12 Jahre ohne Probleme.
Natürlich kann mann das anders lösen aber manchmal macht es Sinn!