Windows Anwendungen mit SQL auf iSeries

[watchdogg]

Hallo Leute,

seit ungefäöhr einem Jahr arbeite ich mit einer iSeries Maschine.
Anfangs tat ich mich ziemlich schwer damit, weil mir diese Art von Maschinen bisher unbekannt waren.
So langsam freunden wir uns an und die hohe Ausfallsicherheit des schwarzen Kiste begeistert immer wieder.
Ein Bekannter sagte mal zu mir: "Eine iSeries Maschine stellst du einfach in die Ecke und sie läuft und läuft..." und genau so ist es.

Genug der Vorrede:

Da ich in verschiedenen Programmiersprachen im Windows Bereich entwickle und immer wieder per SQL auf Datenbanken zugreife
kam mir die Idee zukünftig die Datenbank der iSeries zu nutzen.
Ich nutze Client Access als ODBC Schnittstelle, die Performance ist völlig OK.
Wie ist das aber wenn eine neue iSeries gekauft wird. Mein Chef sagte mir: "Was auf der alten iSeries läuft, läuft auch auf der neuen Maschine." Ist das wirklich so, dass die Software unabhängig von der Hardware weiterläuft wenn man nur die Platteninhalte auf die neue Maschine kopiert? Wenn man das unter Windows macht, erlebt man ja sein "Blaues Wunder".
Ich habe mal eine Testtabelle erstellt, da kam ne Meldung, dass die Tabelle ordnungsgemäß erstellt wurde, aber nicht im Journal eingetragen wurde. Was hat das Journal für ne Funktion?

Ich bin der Meinung, wenn man eine iSeries dastehen hat, sollte man sie auch nutzen! Und aufgrund der hohen Ausfallsicherheit, dem
minimalen Virenrisiko und der Hardwareunabhängigkeit bietet sich die Maschine hervorragend für Datenbankanwendungen.

Was haltet ihr davon, die Datenbanken auf die iSeries auszulagern. Gibt es irgendwas was ich dabei nicht berücksichtige oder andere Nachteile?

MfG watchdogg

[AS400.lehrling]

Hallo Leute,

seit ungefäöhr einem Jahr arbeite ich mit einer iSeries Maschine.
Anfangs tat ich mich ziemlich schwer damit, weil mir diese Art von Maschinen bisher unbekannt waren.
So langsam freunden wir uns an und die hohe Ausfallsicherheit des schwarzen Kiste begeistert immer wieder.

Schön das ihr Freunde werdet

Da ich in verschiedenen Programmiersprachen im Windows Bereich entwickle und immer wieder per SQL auf Datenbanken zugreife
kam mir die Idee zukünftig die Datenbank der iSeries zu nutzen.
Ich nutze Client Access als ODBC Schnittstelle, die Performance ist völlig OK.
Wie ist das aber wenn eine neue iSeries gekauft wird. Mein Chef sagte mir: "Was auf der alten iSeries läuft, läuft auch auf der neuen Maschine." Ist das wirklich so, dass die Software unabhängig von der Hardware weiterläuft wenn man nur die Platteninhalte auf die neue Maschine kopiert?

Also Platteninhalte rüberkopieren würde ich nicht unbedingt - man macht eine Sicherung der Anwendungen auf der alten Maschine und auf der neuen Maschine dann eine Rücksicherung

Ich habe mal eine Testtabelle erstellt, da kam ne Meldung, dass die Tabelle ordnungsgemäß erstellt wurde, aber nicht im Journal eingetragen wurde. Was hat das Journal für ne Funktion?

Das mit den Journal kann ich dir nicht Beantworten habe mich noch nicht mit der DB/400 bzw DB2/400 beschäftigt

Ich bin der Meinung, wenn man eine iSeries dastehen hat, sollte man sie auch nutzen! Und aufgrund der hohen Ausfallsicherheit, dem
minimalen Virenrisiko und der Hardwareunabhängigkeit bietet sich die Maschine hervorragend für Datenbankanwendungen.

Dafür ist die AS/400 bzw e-Server i-Series ja auch entwickelt worden

Was haltet ihr davon, die Datenbanken auf die iSeries auszulagern. Gibt es irgendwas was ich dabei nicht berücksichtige oder andere Nachteile?

MfG watchdogg

Nachteile wüste ich jetzt keine, der Import von anderen Datenbanken SQL MySQL MsSQL Orakel geht glaube ich ohne Probleme.

Je nach dem wie die Datenbank genutzt wird - Zugriffs / Änderung Häufigkeit gibt es da wohl einen Unterschied zwischen den Modellen - genau weiß ich es aber nicht.

Gruß AS400.lehrling

[bussibaer]

@watchdog

1. Journale:
Sie dienen zum Wiederherstellen von Datenbanken im SQL-Bereich. Jede Transaktion wird in dem Journal aufgezeichnet. Nur mit dem Journal funktioniert der ROLLBACK bei SQL-Anweisungen z.B. Ich bin der Meinung, aber da müßte mich ggf. jemand korrigieren, dass das Journaling nicht funktioniert, wenn du die Datei, z.B. mit einem ILERPG änderst. Diese Änderungen werden meines Wissens nicht aufgezeichnet.

2. Du solltest immer darauf achten, das die Berechtigungen deiner Tabellen richtig gesetzt sind. Hört sich blöd an, ich weiß, aber einige Fehler, die ich gemacht habe, und wo ich mir einen Wolf gesucht habe, beruhen auf verkehrt gesetzten Berechtigungen. Das ist OS/400 Knallhart.

[BenderD]

@Journal: Journale zeichnen alle Änderungen an Tabellen auf Satzebene auf und werden für Transaktionssteuerung benötigt (SQL Anweisungen Commit, Rollback, Savepoint). Erstellt man sich seine Datenbank per SQL mit create schema, geht das alles (fast) von selber (man sollte sich noch ein wenig um die Reorganisation kümmern, damit das dann nicht vor sich hin wuchert). Am Rande sei hier vermerkt, dass ohne Transaktionssteuerung mit SQL kein echter Mehrbenutzrebetrieb ohne Dreckeffekte möglich ist.

@auslagern: wenn man schon eine AS/400 hat, macht das sicher Sinn, diese Datenbank ist einfacher zu fliegen als alles andere, egal ob MySQL, Oracle, MS SQL Server ...

D*B

[watchdogg]

Vielen Dank für eure kompetenten Antworten.
Da wir auch zukünftig auf IBM setzen werden (PPS), werde ich mich für diesen Weg entscheiden.

MfG watchdogg

[dabeda]

@watchdog

Ich bin der Meinung, aber da müßte mich ggf. jemand korrigieren, dass das Journaling nicht funktioniert, wenn du die Datei, z.B. mit einem ILERPG änderst. Diese Änderungen werden meines Wissens nicht aufgezeichnet.

Das journaling funktioniert von allen Seiten. Wenn die Bibliothek mit CREATE SCHEMA erstellt wurde, werden automatisch in dieser Bibliothek Journale erstellt und die Dateien darin aufgezeichnet, in einer mit CRTLIB erstellten, muß man sich selbst um die Journale und das journaling kümmern. Welches Journal man benutzt kann man sich aber selbst aussuchen.
Wichtig ist dass alle Dateien einer Anwendung auch im selben Journal aufgezeichnet werden.

mfg

[UFK]

Möglichst als aller Erstes CREATE SCHEMA oder CREATE COLLECTION eingeben, und dann genau dort die Tabellen definieren, denn dann läuft alles wie von selbst.

Wenn man aber ohne begonnen hat, und die Journalisierung erst danach aufsetzt, ok, dann muß man a) beachten, daß das Journal möglichst QSQJRN heißt, und b) alle bereits zuvor erstellten Tabellen mít dem AS400-Befehl STRJRNPF ins Journal aufgenommen werden. Bei weiteren Tabellen sollte dann die Automatik wieder greifen.

[B.Hauser]

Hallo,

ich würde Journal und vorallem den/die Journal Receiver nicht in der gleichen Bibliothek wie die Daten anlegen. Was passiert, wenn jemand die Bibliothek löscht oder aus einem anderen Grund nicht darauf zugegriffen werden kann? Dann ist auch das Journal bzw. die Journal Receiver auch weg ... und dann?

Das Journal und Receiver sollten in einer anderen Bibliothek (am besten in einem anderen ASP angelegt werden).

Um eine automatische Journalisierung zu erreichen benötigt man lediglich in der Daten-Bibliothek den Datenbereich QDFTJRN in den auf den ersten 20 Stellen das qualifizierte Journal und auf den nächsten Stellen welche Ojekt-Arten, wann registriert werden sollen. Ist dieser Datenbereich vorhanden, werden alle Dateien (sofern dies hinterlegt ist) beim Erstellen (unabhängig davon ob mit DDS bzw. CRTPF oder SQL) in dem angegebenen Journal aufgezeichnet. Weitere Informationen zum automatischen Journaling unter: Automatically starting journaling

Für das nachträgliche Registrieren gibt es ab Release 6.1 auch den CL-Befehl STRJRNLIB mit dem man all Objekte in einer Bibliothek auf einen Schlag in einem Journal registrien kann.

Birgitta

[BenderD]

... das Journal gehört in die Datenbibliothek (wg. Save Restore Abläufen) die Receiver am Besten in der Tat in einen anderen ASP.

D*B

Hallo,

ich würde Journal und vorallem den/die Journal Receiver nicht in der gleichen Bibliothek wie die Daten anlegen. Was passiert, wenn jemand die Bibliothek löscht oder aus einem anderen Grund nicht darauf zugegriffen werden kann? Dann ist auch das Journal bzw. die Journal Receiver auch weg ... und dann?

Das Journal und Receiver sollten in einer anderen Bibliothek (am besten in einem anderen ASP angelegt werden).

Um eine automatische Journalisierung zu erreichen benötigt man lediglich in der Daten-Bibliothek den Datenbereich QDFTJRN in den auf den ersten 20 Stellen das qualifizierte Journal und auf den nächsten Stellen welche Ojekt-Arten, wann registriert werden sollen. Ist dieser Datenbereich vorhanden, werden alle Dateien (sofern dies hinterlegt ist) beim Erstellen (unabhängig davon ob mit DDS bzw. CRTPF oder SQL) in dem angegebenen Journal aufgezeichnet. Weitere Informationen zum automatischen Journaling unter: Automatically starting journaling

Für das nachträgliche Registrieren gibt es ab Release 6.1 auch den CL-Befehl STRJRNLIB mit dem man all Objekte in einer Bibliothek auf einen Schlag in einem Journal registrien kann.

Birgitta

[B.Hauser]

... das Journal gehört in die Datenbibliothek (wg. Save Restore Abläufen)

Darüber kann man sich streiten! Wenn die Bibliothek, in der das Journal liegt zuerst zurückgespeichert wird und in dem Datenbereich QDFTJRN in der Datenbibliothek hinterlegt ist, dass die Dateien/Tabellen beim zurückspeichern registriert werden, ist das kein Problem.

Birgitta