Daten von mehreren Systemen abfragen

[msost]

Ich muß Daten eines Kunden von mehreren I-Systemen (V7R2) abfragen. Es sind derzeit noch einige wenige Dateien. Pro System gibt es diese Dateien mehrfach, jeweils in verschiedenen Bibliotheken.

Man kennt die Kundschaft, der Hunger kommt mit dem Essen. Es werden also verschiedene weitere Anfragen dieser Art auch zu anderen Dateien kommen.

Hat jemand eine gute Idee wie man an sowas rangeht? Es sollten nach Möglichkeit nur Standardwerkzeuge (SQL, JDBC etc.) genutzt werden.

Danke für Denkanstösse!

[Fuerchau]

Fremde iSeries kann man simpel unter WRKRDBDIRE registrieren. Voraussetzung ist natürlich, dass die Zielsysteme per IP erreichbar sind.
In SQL (STRSQL, embedded, JDBC, ODBC, .NET, ...) kann man sich mit diesen Datenbanken verbinden und Daten per SQL verarbeiten.
Man kann auch zwischen den Verbindungen hin- und herschalten. Es bedarf dazu keiner Fremdprodukte.

[Robi]

Schreib dir Datenzugriffsprogramme, die mit "connect to" und SQL Daten holen.
und zwar 1 Pgm je Datei, mit actgrp *caller.

zusätzlich Je ein Pgm, mit gleicher Parameterliste, das nur das System im Parameter ergänzt und das Lesepgm ruft, mit actgrp 'zielsystem'

Im RPG rufst du lies_s1, oder lies_s2 oder ...

So ist auch ein gemischter zugriff, möglich

Robi

[Pikachu]

Da gibt's zum Beispiel CRTDDMF vom DDM (Distributed data management).

Oder du kannst im IFS über QFilSvr.400 zu den anderen Systemen kommen.

[Fuerchau]

DDM unterstützt nur eingeschränkt SQL, QFilSvr.400 ist ein spezieller IFS-Zugriff der mit SQL gar nichts zu tun hat.
Von diesen "alten" Methoden sollte man gleich Abstand nehmen.

Mit der ACTGRP(*CALLER) mag es beim Lesen keine Probleme geben, aber spätestens bei der Verwendung von Journalen und Transaktionen empfielt sich eher eine ACTGRP je System, da es innerhalb einer ACTGRP nicht mehrere offene Commit-Definitionen geben kann.

[Pikachu]

Ok, hatte übersehen, daß es per SQL gehen soll ...

[Robi]

@Baldur.
ja !

Aber ich habe ja auch von einem Pgm je System geschrieben, das mit der Actgrp des Zielsystems laufen soll. Und das ruft dann das Lesepgm, das durch das *caller dann auch in der richtigen läuft.

Robi

[BenderD]

... wichtig ist:
- umwandeln mit RDBCNNMTH(*DUW) und COMMIT(*CHG) und RDB(*LOCAL), was default sein sollte - wenn da kein Dillletttant an Knöpfchen gespielt hat.
- der Commit Master (das steuernde Programm) kriegt eine benamte ACTGRP
- die Zugriffsprogramme alle *CALLER (damit alles in derselben ACTGRP läuft!!!)
- im Zugriffsprogramm beim ersten Aufruf connect machen, bei weiteren reicht set connection (nicht vergessen auf die locale zurück zu setzen, sonst passieren seltsame Dinge in anderen Programmen!)
- ich empfehle pro remote system eigene Module (ist immer blöd, wenn man mit einer falschen Connection liest oder schreibt)
- für die remote Systeme ist ein CRTSQLPKG erforderlich
- die Commit Operationen wirken dann auf alle Connections

D*B

[Fuerchau]

Ok, das habe ich überlesen. Ich halte das für zu aufwändig.
Wenn ich in einem Programm bereits aus 2 Systemen lesen muss, ist es besser die Lese-Programme bereits in eigenen ACTGRP's je System laufen zu lassen, dann brauche ich nicht noch eine Ebene dazwischen um die Leseproggramme letztendlich doch in getrennten ACTGRP's zu haben.

Blöd ist halt nur, wenn die Zielsysteme ja dieselben Tabellen haben, wieso dann je System eine eigene ACTGRP da doch nur der DBName sich unterscheidet? Solange ich nur lese, habe ich keine Probleme alles in einer ACTGRP abzufahren. Spätestens bei Transaktionen kann ich mit Filehändlern hier nichts mehr anfangen (außer Lesen).
Dann brauche ich tatsächlich je System eine neue ACTGRP, was durchaus mit ACTGRP(*NEW) geht.
Allerdings darf ich diese ACTGRP nicht verlassen (da hilft auch kein LR) bevor meine Transaktionen abgeschlossen sind. Dann ginge auch wieder ACTGRP(*CALLER) für die SQL-Filehändler.

[BenderD]

Ok, das habe ich überlesen. Ich halte das für zu aufwändig.
Wenn ich in einem Programm bereits aus 2 Systemen lesen muss, ist es besser die Lese-Programme bereits in eigenen ACTGRP's je System laufen zu lassen, dann brauche ich nicht noch eine Ebene dazwischen um die Leseproggramme letztendlich doch in getrennten ACTGRP's zu haben.

Blöd ist halt nur, wenn die Zielsysteme ja dieselben Tabellen haben, wieso dann je System eine eigene ACTGRP da doch nur der DBName sich unterscheidet? Solange ich nur lese, habe ich keine Probleme alles in einer ACTGRP abzufahren. Spätestens bei Transaktionen kann ich mit Filehändlern hier nichts mehr anfangen (außer Lesen).
Dann brauche ich tatsächlich je System eine neue ACTGRP, was durchaus mit ACTGRP(*NEW) geht.
Allerdings darf ich diese ACTGRP nicht verlassen (da hilft auch kein LR) bevor meine Transaktionen abgeschlossen sind. Dann ginge auch wieder ACTGRP(*CALLER) für die SQL-Filehändler.

... pro Connect eine eigene ACTGRP ist nicht erforderlich und macht auch keinen Sinn!!!

D*B

[Robi]

also pro connect ne eigene find ich schon hilfreich ...

und ich gehe in meinem Szenario davon aus, das Datei A auf allen Systemen gleich ist.
Und alle Dateien B sind auch gleich.

Dann habe ich 1 ZugriffPgm für Datei A, eins für B und ...

Und um o.g. Trennung hin zu bekommen (warum bist du dagegen Dieter?) habe ich eine Ebene ohne viel logik dazwischen. Die Hilfspgmme sind NUR für 1 System und übergeben den Wert mit dem zu connecten ist. Da läuft nix schief, es sei denn ich rufe 'lies_A_in System_5' und will eigendlich 'lies_A_in_System_3'. Aber sowas hat schon immer zu kleineren Problemen geführt

Robi

[BenderD]

also pro connect ne eigene find ich schon hilfreich ...

und ich gehe in meinem Szenario davon aus, das Datei A auf allen Systemen gleich ist.
Und alle Dateien B sind auch gleich.

Dann habe ich 1 ZugriffPgm für Datei A, eins für B und ...

Und um o.g. Trennung hin zu bekommen (warum bist du dagegen Dieter?) habe ich eine Ebene ohne viel logik dazwischen. Die Hilfspgmme sind NUR für 1 System und übergeben den Wert mit dem zu connecten ist. Da läuft nix schief, es sei denn ich rufe 'lies_A_in System_5' und will eigendlich 'lies_A_in_System_3'. Aber sowas hat schon immer zu kleineren Problemen geführt

Robi

@verschiedene ACTGRPS:
- lesen auf A und schreiben auf B gehört in eine Transaktion (sprich ACTGRP)

@ein Programm für mehrere Maschinen:
- gibt beim Deployment Huddel, spätestens wenn man mit verschiedenen CCSIDs oder Änderungen zu tun hat (deswegen mussten wir schonmal von embedded SQL auf CLI wechseln)
- ohne getrennte ACTGRP wird das kritisch, wenn man sich mit den Connections vertüddelt

- die zusätzliche Ebene stört mich nicht.

D*B