View Full Version : Member reihenfolge
Moin zusammen
Wir haben einige wenige Dateien (PF), bei dehnen es Sinn macht temporär mit mehreren Membern zu arbeiten.
Nun ist 'plötzlich und unerwartet' seid über 12 Jahren das erste mal, ein zugriff falsch.
Das 1. Member heisst ja wie die Datei.
Irgendwie hat es ein Kunde geschafft, in einer Datei sein normalerweise temporäres Member als *First rein zu bekommen.
Normale Zugriffe gehen über ILE-RPG, setll, read, Chain, reade, ...
im Sonderfall entsteht ein Member, ein ovrdbf läuft, und wir greifen mit SQL zu.
Diese Member werden nach der Aktion gelöscht, es sei denn der Anwender macht die Kiste einfach aus.
Normal und Sonderfall sind IMMER getrennte Jobs's eine Mischung ist definitiv nicht möglich.
Vermutlich durch das Sichern auf iSeries 1 und zurückspielen auf iSeries 2 hat sich die Member Reihenfolge verschoben und so ein temporäres member ist *first und wird von der ILERPG zugriffen gelesen.
Tests bei uns zeigen aber, sichern und zurückspielen (bei V7.R1) GLEICHE iSeries, verändern NICHT die Member Reihenfolge.
Ist das bei V7R3 oder bei 2 verschiedenen iSeries anders?
Danke
Auch wenn der Zug abgefahren scheint:
"Wir haben einige wenige Dateien (PF), bei dehnen es Sinn macht temporär mit mehreren Membern zu arbeiten."
Dies macht überhaupt keinen Sinn (mehr).
Wenn man sowieso mit OVRDBF arbeitet kann man auch per CRTDUPOBJ identische Kopien schaffen, die per OVRDBF genauso funktionieren.
Was den Restore angeht, so hat es da nie eine Garantie der Reihenfolge gegeben.
nur das ein ADDLFM funktioniert,
ein CRTDUPOBJ des LF aber auf dem falschen PF liegt.
CRTLF scheidet auch aus, da ich ja ggf mehr als 1 Kopie habe und ich nicht n Sourcen pflegen will.
Und per Pgm immer ne passene Source für den CRTLF schreiben bläht das ganze unheimlich auf.
Bliebe die Umstellung des AnwendungsTeils auf ein zusätzliches Feld, das die Sätze als Temp/Echt kennzeichnet.
Ein nicht wirklich lustiger Aufwand.
Oder hast du da auch ne Idee?
Robi
CRTDUPOBJ auf die falsche PF?
Dann stimmt was nicht mit deiner LF oder deiner aktuellen LIBL.
Mal ne dumme Frage:
Besteht die Möglichkeit, dass das Original Member gelöscht worden ist, und dann im Nachgang neu zugefügt wurde?
Denn dann ist es auch nicht mehr das erste Member.
Gruß
Ronald
@Ronald
nein, dann wären die Daten des Members auch weg, dann liefe gar nix mehr.
@Baldur
Datei
PF = A
LF = AL01
LF = AL02
crtdupobj A #A
crtdupobj AL01 #AL01
auf #A liegt #AL01 jedenfals nicht ...
beim ADDLFM kannst dich auf MBR #A beziehen
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.
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
28-02-19, 15:23
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
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:confused: