[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Jun 2001
    Beiträge
    1.973

    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
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    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
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    CRTDUPOBJ auf die falsche PF?
    Dann stimmt was nicht mit deiner LF oder deiner aktuellen LIBL.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    May 2002
    Beiträge
    1.121
    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

  6. #6
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    @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
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #8
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    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!
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  9. #9
    Registriert seit
    Jun 2009
    Beiträge
    316
    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

  10. #10
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    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
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  12. #12
    Registriert seit
    Nov 2003
    Beiträge
    2.304
    Wenn *FIRST beim OVRDBF dasselbe bedeutet wie beim RTVMBRD, dann ist das "Die erste Teildatei in einer nach Datum geordneten Liste".

Similar Threads

  1. Reihenfolge der Datensatzverarbeitung beim SQL-Update
    By KM in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 06-04-18, 12:09
  2. Cursor-Reihenfolge in Subdateien mit SFLLIN
    By fpxx in forum NEWSboard Programmierung
    Antworten: 1
    Letzter Beitrag: 26-07-17, 15:38
  3. Datensatzfortschreibung in falscher Reihenfolge
    By M.Heger in forum NEWSboard Programmierung
    Antworten: 8
    Letzter Beitrag: 16-09-16, 10:43
  4. Reihenfolge Abarbeitung JOBQ
    By Starocotes in forum IBM i Hauptforum
    Antworten: 23
    Letzter Beitrag: 19-05-15, 14:04
  5. SQL und Reihenfolge der angezeigten Sätze
    By KingofKning in forum NEWSboard Programmierung
    Antworten: 8
    Letzter Beitrag: 30-12-14, 20:53

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •