Load utility mit IXF versorgen

Ansicht von 5 Beiträgen - 1 bis 5 (von insgesamt 5)
  • Author
    Posts
  • 18. November 2009 um 8:31 Uhr #4058

    Anonym
    Inaktiv

    Hallo zusammen,

    wir bekommen demnächst Daten von einem anderen Unternehmen. Hier sind unter anderem Unterschriftsdaten enthalten (vermutlich BLOBs). Man hat uns jetzt uns jetzt das IXF-Format angeboten. Ich habe mal ein wenig gegoogelt und die Doku gelesen. 

    Folgenden Stand habe ich:

    – IXF enthält DDL + Dateninhalte der Tabellen
    – IXF läßt sich nicht mit Z/OS Utilities alleine laden
       (nur mit einem Client der IXF versteht und der an z/OS angebunden ist)

    – getrennte DDL-Files und Ladebestände sind
      vermutlicher einfacher für eine z/OS-Umgebung handhabbar

    Welche Meinung habt ihr?
    Welches Format würdet ihr euch wünschen?
    Andere Hinweise?

    Gruss Klaus

    18. November 2009 um 18:10 Uhr #4222

    Anonym
    Inaktiv

    Hi,

    DDL-Files und Ladebestände sind vor allem bei großen Datenmengen spürbar schneller. Außerdem können sie ja lokal geladen werden.

    MfG

    AxelP

    18. November 2009 um 19:58 Uhr #4343

    Anonym
    Inaktiv

    Hallo Klaus,

    auch QMF (z/OS) kann IXF-Dateien erzeugen. Die sind aber nicht kompatibel zu den IXF-Dateien, die man auf DB2 for Linux/Unix/Windows kennt.

    Nehmen wir mal an, dass die Daten ursprünglich mit Hilfe eines DB2 for Linux/Unix/Windows erzeugt wurden:

    • diese IXF-Files sind m.E. wirtschaftlich direkt auf z/OS nicht verarbeitbar
    • auf einer Workstation sehe ich technisch absolut kein Problem mit der Weiterverarbeitung. Die DDL-Komponente kommt nicht zum Tragen: Die Objekte sollten ja bereits vorhanden sein. Wenn nicht: Klasse, dann kann ich auf DB2 L/U/W die Struktur anlegen lassen. Aber: Man benötigt DB2 Connect für die Verbindung von der Workstation zu DB2 for z/OS – kostet ca. 550,- netto lt. IBM Preisliste. Viel eher sehe ich hier das Problem der Automation: Welcher Prozess steuert den Empfang und den LOAD/IMPORT?
    • sollten die Daten tatsächlich ursprünglich von einem DB2 for z/OS stammen, würden ich einen DB2 for z/OS UNLOAD (auch im DEL-Format) vorziehen, schon alleine wegen der Möglichkeiten der Automation. TWS ETT kann z.B. das Eintreffen einer File erkennen und den DB2 for z/OS LOAD auslösen. Diese Dinge sind auf einer Workstation (FTP, Firewall, DB2 Connect, autorisierten Funktions-User etc pp) organisatorisch viel schwerer zu lösen.
    • Dazu kommt die Codepage Problematik: An der Quelle hat eine Workstation Daten aus DB2 for z/OS extrahiert. Dann sind die Daten zu Euch geschickt worden. Dann steht bei Euch mit Netzwerk irgendwo eine wie auch immer konfigurierte "Kiste", mit der man die Daten auf den Host schieben will. Vorsicht: Auf jeder Plattform auf die richtigen  Codepage- Einstellungen achten!

    Das alles ist müssig zu diskuttieren, wenn die geplante Architektur zu einer "großen Strategie" gehört.

    Erzähl‘ uns, wie es weitergeht!

    Viele Grüße
    Gernot

    19. November 2009 um 7:49 Uhr #4427

    Anonym
    Inaktiv

    Vielen Dank erst mal für eure Anmerkungen und Informationen.

    Wir stehen momentan am Anfang eines Migrationsprojektes.
    Momentan geht es darum Empfehlungen zu geben, mit welchen Verfahren die zukünftige Migration ablaufen soll.

    Resultierend aus euren Antworten und meinen Recherchen werden wir jetzt die Empfehlung gegen IXF-Dateien und für separate UNLOAD-Bestände (im DEL-Format) + DDL-Beschreibung geben.

    Wenn es etwas Neues gibt, melde ich mich wieder.

    Gruss Klaus

    19. November 2009 um 9:03 Uhr #4481

    Anonym
    Inaktiv

    Hi Klaus,

    die vom UNLOAD generierten LOAD Statements sind ja auch nicht schlecht.

    Bleibt zu erwähnen: Auf den Header und Art und Weise der Ausgabe von VARYING CHAR Spalten achten!

    Gruß
    Gernot

  • Author
    Posts
Ansicht von 5 Beiträgen - 1 bis 5 (von insgesamt 5)

You must be logged in to reply to this topic.