DB2 Connect unter Linux - Probleme

[Olli1]

Also, ich will jetzt nicht unbedingt den Systemwert QCCSID ändern, da es sich hier um ein produktives System handelt...

QCCSID ist 65535
In der QADBXREF ist die CCSID 273
QCHRID: Zeichensatz-ID: 697, CCSID: 273

Im USRPRF kann man ja die CCSID auch vorgeben. Standardmässig ist dort *SYSVAL vorgegeben. Das habe ich ja bereits auf 273 geändert. Was ja im Prinzip den gleichen Effekt haben sollte, als wenn ich *SYSVAL stehen lassen würde und den Systemwert ändere...

[Fuerchau]

Dem ist leider nicht ganz so, da einige Job's unter QUSER laufen.
Ändere doch zusätzlich auch mal QUSER auf 273.

Unter Google bin ich auf folgende Links gestossen:
http://www-1.ibm.com/servers/eserver...2/db22drda.htm

Alternativ probiere doch mal iSeriesAccess for Linux aus

Ansonsten kommst du wohl nicht darum herum, QCCSID auf 273 zu setzen (für die laufende Anwendung keine Auswirkung!!!).

[Fuerchau]

PS:
http://www.phptutorials.de/index.php?article=12&tpl=2

[Olli1]

Danke. Das Tutorial ist mir aber schon bekannt... (s.o.)

Auf der IBM Seite steht übrigens: Furthermore, to successfully connect, you may need to change one of the following: the CCSID of the job, the CCSID of the user profile used, or the system CCSID value (QCCSID) if it's the default 65535.

Das heisst für mich, dass der Systemwert nicht unbedingt geändert werden muss... Womit ich also wieder genauso weit wäre, wie am Anfang...

Gruß,
Olli

[Olli1]

Übrigens brachte auch die Änderung der CCSID im USRPRF QUSER nichts... Fehlermeldung ist weiterhin die gleiche !

[Fuerchau]

Dann probier doch wenigstens mal die Änderung des Systemwertes auf 273 aus !
Du vertust dir dabei nix.

[Fuerchau]

Wo kommt die CCSID 923 denn her ???
Von 273 nach 923 geht tatsächlich nicht !

[Olli1]

das Problem ist übrigens kein Problem aus AS/400 Seite... wir haben auf nem Windows Rechner das DB2 Connect installiert und da läuft es ohne Probleme...

Davon abgesehen ist der Zugriff über DB2 Connect aber ein ziemliches Sicherheitsrisiko, wie wir feststellen mussten...
Wir setzen das Security Tool PCSACC/400 von Busch & Partner ein.
DB2 Connect verwendet DRDA/ODBC Treiber und da kann man lediglich den generellen Zugriff auf die AS/400 Daten zulassen oder generell blocken... eine Prüfung auf Dateiebene ist nicht möglich. Eine Prüfung erfolgt lediglich beim Connect...
Nicht so dolle. Bei "normalen" ODBC Treibern kann man derartige Zugriffe blocken...

Frage: Gibt es eigentlich einen ODBC Treiber für die iSeries unter Linux ???

[Fuerchau]

Es gibt den iSeriesAccess für Linux. Ob der aber nicht über DRDA geht, weiß ich nicht.
Das gleiche gilt übrigens auch für die JAVA-Treiber. Die gehen alle über DRDA.

Ich habe mit Herrn Busch schon gesprochen, IBM will die Schnittstelle wohl nicht erweitern (Access-Point).
Bleibt nur, das "Sicherheitsrisiko" zu schließen. Und zwar mit normalen Bordmitteln, was durchaus geht (siehe Beitrag Kennwort knacken).

Wenn du diesbezüglich Hilfe benötigst, wende dich vertrauensvoll an mich

Zurück zu deinem Problem:
Wo kommt die Source-Code-Page 923 her ?
Ist euer Linux vielleicht Polnisch/Tschechisch o.ä. ?

[Olli1]

Wo die Source Code Page 923 herkommt wissen wir im Mom. auch noch nicht so ganz...
Unser Linux-Admin hat auch noch nicht die entsprechende Einstellung gefunden, wo sich die Codepage für das DB2 Connect verändern lässt.

Unter
http://webdocs.caspur.it/ibm/web/udb...c4/db2c452.htm
haben wir eine Übersicht gefunden, die zeigt, welche Codepages auf Linux-Client-Seite zu welchen CCSID's auf Hostseite kompatibel sind...

Tja, was die Berechtigungen auf der AS/400 angeht, kann man das ganze sicherlich wasserdicht machen. Da geb ich Dir Recht. Nur ist es so, dass bei uns die Daten-Bibl. nicht unbedingt auf *PUBLIC *EXCLUDE stehen...
Wenn ich das nun mache, und bei den entsprechenden LIB's den LINUXUSER eintrage, hätte ich dann sicherlich erreicht, dass die DRDA Zugriffe nur auf Dateien stattfinden, für die der User berechtigt ist.
Aber so ohne weiteres kann ich das sicher auch nicht machen, denn ich muss ja auch an unsere anderen Anwendungen denken, die hier laufen. Ich stell mir nur mal nen einfachen Fall vor, dass irgendwo ein Programm läuft, was nen clear auf eine Datei macht, und auf einmal fehlen die Objektberechtigungen...

Ich meine, man hat sich das PCSACC/400 ja auch nicht umsonst angeschafft !

Gruß und schönes Wochenende,
Olli

[Fuerchau]

Meine Meinung dazu dürfte inzwischen ja auch fast überall bekannt sein.

Nichts gegen das Tool an sich, mit Herrn Busch komme ich super klar (schon stundenlang Probleme ausdiskutiert).
Aber im Endeffekt ist das Tool nicht erforderlich, wenn man Sicherheitskonzepte von vorne herein richtig eingesetzt bzw. überhaupt erst berücksichtigt hätte.

Im Nachhinein ist das immer etwas schwierig, aber nicht unlösbar.

Ich denke auch in Zukunft wird DRDA (durch JAVA, ADO.NET) stärker genutzt werden so dass man um Sicherheitskonzepte sowieso nicht herum kann, was langfristig wiederum PCSACC überflüssig macht.