Daten von mehreren Systemen abfragen

[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

[Fuerchau]

Lesen von A und Schreiben auf B kann man durchaus in einer ACTGRP machen, aber zusätzlich schreiben auf C könnte mit der offenen Commit-Definition problematisch werden.
Ausprobiert habe ich das noch nicht.

Ein Hauptproblem sind noch die internen SQLPKG's, die vor dem ersten Zugriff per CRTSQLPKG auf die Zielsysteme verteilt werden müssen. Hier muss man dann auch noch die Berechtigung des Zielpaketes anpassen, da per Default PUBLIC auf *EXCLUDE gestellt wird und somit nur der Ersteller auf die Zielsysteme zugreifen kann.

Mittels CLI entfällt dies komplett, da hier quasi mit ODBC-ähnlichen Zugriffen gearbeitet wird. Zusätzlcih gibt es da noch einen Server-Mode auf Connection-Ebene, mit dem der SQL-Zugriff noch mal in einen Hintergrundjob abgegeben wird und somit absolut unkritisch mit getrennten Transaktionen umgegangen werden kann.

[BenderD]

Lesen von A und Schreiben auf B kann man durchaus in einer ACTGRP machen, aber zusätzlich schreiben auf C könnte mit der offenen Commit-Definition problematisch werden.

... set connection geht in jedem Status der Commit Definition. disconnect geht nur außerhalb einer Transaktion, aber da ist release mit nachfolgendem commit eh besser.

D*B

[msost]

Hi zusammen,

danke für die vielen Tips und Gedanken. Hat schon geholfen!

Eine Frage hätte ich noch dazu:

Kann man eine Art View über eine Datei auf mehreren Maschinen abbilden?
Also Datei A ist auf 5 Systemen vorhanden. Man würde gern sehen was auf allen 5 Maschinen in der Datei ist, möglichst ohne diese sozusagen zusammen zu sammeln und zwischenzuspeichern.
Oder braucht das DRDA?

[Fuerchau]

Auch mittels DRDA ist dies nicht möglich.
Ob dies mit einer partitionierten Tabelle funktioniert kann ich nicht sagen.
Hier muss bereits beim CREATE TABLE jede Partition mit den Schlüsseltrennungen festgelegt werden. Ob und wie dies über Systemgrenzen funktionert sollte mal einer ausprobieren.
Nachträglich ist das nicht möglich und ob ich über "ALTER TABLE" Partitions hinzufügen oder auch entfernen kann gilt ebenso zu prüfen.

Der SQL-Server kann dies "im Prinzip".
Man richte entsprechende Verbindungsserver ein und erstelle eine gemeinsame View über alle Server.
Mache ich dann einen "select * from view" saugt sich der SQL-Server erst mal alle Daten in den Speicher (bis er platzt) um das Ergebnis dann zu präsentieren.
Interessant sind dann Queries mit Joins über Systemgrenzen, dann auch da wird erst mal alles geladen um anschließend unnötiges wieder wegzuschmeißen.

[BenderD]

DRDA (Client und Server) ist auf AS/400 (neudeutsch Ei) Bestandteil des Betriebssystems, kann das aber nicht - auch nicht mit threepart alias etc. Das Maximum der Gefühle ist, dass man das Ergebnis eines remote selects in eine lokale Tabelle ausgeben kann, ansonsten kann man innerhalb eines SQL Statements immer nur einen Connect ansprechen.
Zusätzlich gibt es ein Produkt, das öfter als die AS/400 umbenannt wird, einer der Namen war mal "Wepsphere Dederation Server", das sowas ermöglicht, braucht aber einen zusätzlichen p Server mit DB2, Wunder würde ich davon allerdings genausowenig, wie von SQL Server erwarten.

D*B

[Robi]

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

Stimmt m.E. nur, wenn nach dem lesen von A , in A auch gelöscht wird.
Reines 'kopieren von A nach B benötigt das nicht.

gibt beim Deployment Huddel, spätestens wenn man mit verschiedenen CCSIDs oder Änderungen zu tun hat

verschiedene CCSids sind nicht meine Baustelle, Kommt hier nicht vor. Das will ich nicht beurteilen.

Und ja klar, wenn Datei A auf System 1 irgendwann mal un= Datei A auf System 2 ist, brauche ich ein eigenes Pgm. Vorher nicht.

Robi