In Anhang B, Arbeitsblatt für die Verzeichnisanpassung sind die Informationen aufgeführt, die zusammengetragen werden müssen. Es ist sinnvoll, das Arbeitsblatt zu kopieren und die eigenen Systemwerte einzugeben.
Im Knotenverzeichnis können folgende Informationen angegeben werden:
Format: 1 bis 8 alphanumerische Einzelbytezeichen, einschließlich des Nummernzeichens (#), des kommerziellen A (@), des Dollarzeichens ($) und des Unterstreichungszeichens (_). Der Wert darf nicht mit einem Unterstreichungszeichen oder einer Zahl beginnen.
Bei fernen Hosts mit DB2 für OS/390 wird der Host-Name in der Nachricht DSNL004I angezeigt (DOMAIN=host-name), wenn DDF (Distributed Data Facility) gestartet wird.
Bei fernen Hosts mit DB2 für OS/390 ist die Anschlußnummer im BSDS (Boot Strap Data Set) als PORT definiert und wird auch in der Nachricht DSNL004I (TCPPORT=anschlußnummer) angegeben, wenn DDF (Distributed Data Facility) gestartet wird.
Anmerkung: | Ein zweiter Anschluß für zweiphasige Festschreibungs-Resynchronisationsoperationen über TCP/IP-Verbindungen wird vom Server zugeordnet. Zum Beispiel ordnet das BSDS von DB2 Universal Database für OS/390 eine Anschlußnummer (RESPORT) für die Resynchronisation von eingehenden Verbindungen nur DB2 Universal Database für OS/390 zu. Dafür muß kein Servicename definiert werden. |
Im DCS-Verzeichnis können folgende Informationen angegeben werden:
Format: 1 bis 8 alphanumerische Einzelbytezeichen, einschließlich des Nummernzeichens (#), des kommerziellen A (@), des Dollarzeichens ($) und des Unterstreichungszeichens (_). Der Wert darf nicht mit einem Unterstreichungszeichen oder einer Zahl beginnen.
Der LOCATION NAME kann durch Anmeldung bei TSO und Ausgabe der folgenden SQL-Abfrage über eines der verfügbaren Abfrage-Tools ermittelt werden:
select current server from sysibm.sysdummy1
Der LOCATION NAME ist auch im BSDS (Boot Strap Data Set) von MVS/ESA definiert und wird in der Nachricht DSNL004I (LOCATION=standort) angegeben, die geschrieben wird, wenn DDF (Distributed Data Facility) gestartet wird.
Der LOCATION NAME kann durch Anmeldung bei TSO und Ausgabe der folgenden SQL-Abfrage über eines der verfügbaren Abfrage-Tools ermittelt werden:
select current server from sysibm.sysdummy1
Der LOCATION NAME ist auch im BSDS (Boot Strap Data Set) definiert und wird in der Nachricht DSNL004I (LOCATION=standort) angegeben, die geschrieben wird, wenn DDF (Distributed Data Facility) gestartet wird.
Format: AR <anwendungs-requester-name>
Standardmäßig wird der Anwendungs-Requester von DB2 Connect verwendet.
SQL30000N SQL30040N SQL30050N SQL30051N SQL30053N SQL30060N SQL30070N SQL30071N SQL30072N SQL30073N SQL30074N SQL30090N
Wenn der Trennungsparameter ,D nicht angegeben ist, wird die Verbindung nur getrennt, wenn die folgenden SQLCODE-Werte zurückgegeben werden:
SQL30020N SQL30021N SQL30041N SQL30061N SQL30081N
Das Handbuch Fehlernachrichten enthält Erläuterungen dieser Codes.
Anmerkung: | Wenn DB2 Connect aufgrund eines Fehlers getrennt wird, wird automatisch eine ROLLBACK-Operation ausgeführt. |
Die Anwendung empfängt den SQLCODE -30081, der darauf hinweist, daß die Verbindung zum Server getrennt wurde. Die Anwendung muß anschließend eine neue Verbindung zum Host- oder AS/400-Datenbank-Server herstellen, damit weitere Datenbankanforderungen verarbeitet werden können. Auf anderen Plattformen als AIX Version 4.1 und höher, SNA Server Version 3.1 und höher, OS/2, Windows NT und Windows 2000 unterstützt DB2 Connect die Option der automatischen Unterbrechung nicht, wenn eine Anwendung, die DB2 Connect verwendet, eine Unterbrechungsanforderung empfängt.
Anmerkung: | Diese Unterstützung funktioniert für TCP/IP-Verbindungen auf allen Plattformen. Der Client kann u. U. den Socket mit KILL abbrechen, aber je nach Server-Implementierung können noch Daten zum Empfang bereitstehen oder nicht. DB2 Universal Database für OS/390 verwendet asynchrone Socket-Aufrufe und kann daher den Verlust der Verbindung erkennen und alle lang andauernden SQL-Anweisungen, die gerade ablaufen, zurücksetzen. |
Außerdem wurde eine neue Profilvariable (Umgebung oder Registrierdatenbank) namens DB2SYSPLEX_SERVER eingeführt, mit der die SYSPLEX-Unterstützung auf Workstation-Ebene inaktiviert werden kann.
Angenommen, Sie setzen die folgenden Anweisungen vom Befehlszeilenprozessor (CLP) ab:
catalog appc node nynode remote nycpic security program catalog dcs database nydb1 as new_york catalog database nydb1 as newyork1 at node nynode authentication dcs
Mit dem Aliasnamen für die Datenbank newyork1 soll ohne Datumsumsetzung auf eine Host-Datenbank zugegriffen werden. weil keine Datumsmaske angegeben wurde.
Mit der neuen Unterstützung für Datumsformatierung können Sie jedoch die folgenden Befehle des Befehlszeilenprozessors verwenden. Da in diesem Fall der Befehlszeilenprozessor verwendet und die Parameterzeichenfolge in doppelten Anführungszeichen angegeben ist, muß der Wert für LOCALDATE innerhalb von zwei Paaren doppelter Anführungszeichen angegeben werden. Durch die Verwendung des Escape-Zeichens für das Betriebssystem "\" (umgekehrter Schrägstrich) können Sie sicherstellen, daß die doppelten Anführungszeichen nicht aus der Angabe für LOCALDATE entfernt werden. Informationen hierzu finden Sie auch im Abschnitt Angeben der Parameterzeichenfolge.
catalog dcs database nydb2 as new_york parms \",,,,,,LOCALDATE=\"\"JJJJMMTT\"\"\" catalog database nydb2 as newyork2 at node nynode authentication dcs
Mit dem Aliasnamen "newyork2" für die Datenbank können Sie auf die gleiche Host-Datenbank zugreifen; für ihn wurde jedoch zusätzlich eine Datumsformatmaske angegeben. Dieses Beispiel verdeutlicht, daß die Datumsformatmaske mit dem Schlüsselwort LOCALDATE angegeben wird und daß es sich hierbei um den siebten positionsgebundenen Parameter im Feld PARMS eines DCS-Verzeichniseintrags handelt.
Die Datumsmaske ist nur gültig, wenn ALLE folgenden Aussagen zutreffen (d. h. wahr sind):
Die folgenden Angaben sind alle gültige Datumsmasken:
"JJjjMmTt" - Ziffern für J, M und T sind unabhängig von der Groß-/Kleinschreibung "MM+TT+JJJJ" - Maske mit mehr als 10 Byte. Ferner sind andere Zeichen als J, M und T in der Maske zulässig "abcJJ+MM" - Folge ohne T zulässig
Die folgenden Angaben sind alle ungültige Datumsmasken:
"JJJJjMMTT" - ungültig, weil 5 J in einer Folge "JJJJMTTM" - ungültig, weil 2 Folgen von M
Wenn eine Datumsformatmaske ungültig ist, wird kein Fehler abgesetzt. Sie wird lediglich ignoriert. Selbst wenn eine Datumsmaske gültig ist, bedeutet dies nicht automatisch, daß sie verwendet wird. Datumsformatumsetzung basierend auf einer gültigen Datumsmaske wird nur ausgeführt, wenn ALLE folgenden Aussagen wahr sind:
Ändern Ihres MVS-Kennworts zeigt das folgende Beispiel zum Katalogisieren eines DCS-Datenbankverzeichnisses mit CHGPWD_SDN:
catalog dcs database db1 as dsn_db_1 parms ",,,,,,,CHGPWD_SDN=pempgm"
",,,,,,,,BIDI=xyz"
Dabei ist xyz die Überschreibung für die ID für codierten Zeichensatz, CCSID (siehe Anmerkung (BIDI_NOTE1)).
Im Handbuch Systemverwaltung finden Sie eine Liste der unterstützten bidirektionalen IDs für codierten Zeichensatz und die entsprechenden Zeichenfolgenarten.
Die folgenden BIDI-Attribute sind für die ordnungsgemäße Handhabung von BIDI-Daten auf verschiedenen Plattformen erforderlich:
Da die Standardeinstellungen auf verschiedenen Plattformen unterschiedlich sind, kommt es zu Problemen, wenn DB2-Daten von einer Plattform an eine andere gesendet werden. Zum Beispiel verwenden Windows-Plattformen Daten des Typs LOGICAL UNSHAPED, während Daten unter MVS und OS/390 in der Regel das Format SHAPED VISUAL aufweisen. Daher werden Daten, die ohne Unterstützung für BIDI-Attribute von DB2 für MVS oder OS/390 an DB2 Connect unter Windows gesendet werden, nicht ordnungsgemäß angezeigt.
Wenn Daten zwischen DB2 Connect und einer Datenbank auf einem Server ausgetauscht werden, führt in der Regel der Empfänger die Umsetzung der eingehenden Daten aus. Diese Vereinbarung gilt normalerweise auch für die BIDI-Layoutumsetzung, die zusätzlich zur gewöhnlichen Codepage-Umsetzung stattfindet. Gegenwärtig unterstützt jedoch kein DB2-Produkt auf einem Host BIDI-spezifische IDs für codierten Zeichensatz oder die BIDI-Layoutumsetzung. Daher wurde DB2 Connect durch eine wahlfreie Funktion erweitert, die eine BIDI-Layoutumsetzung für Daten ausführt, die an die Server-Datenbank gesendet werden sollen und die von der Server-Datenbank empfangen werden.
Damit DB2 Connect die BIDI-Layoutumsetzung für an eine Server-Datenbank abgehende Daten ausführen kann, muß die bidirektionale ID für codierten Zeichensatz der Server-Datenbank überschrieben werden (siehe Anmerkung (BIDI_NOTE2)). Dies wird durch die Verwendung des Parameters BIDI im Feld PARMS des DCS-Datenbankverzeichniseintrags für die Server-Datenbank erzielt.
Die Verwendung dieser Funktion läßt sich am besten anhand eines Beispiels verdeutlichen.
Angenommen, Sie haben einen hebräischen DB2-Client mit der ID für codierten Zeichensatz 62213 (BIDI-Zeichenfolgenart 5), und Sie wollen auf eine DB2-Host-Datenbank mit der ID für codierten Zeichensatz 424 (BIDI-Zeichenfolgenart 4) zugreifen. Sie wissen jedoch, daß die in der DB2-Host-Datenbank enthaltenen Daten auf der ID für codierten Zeichensatz 8616 (BIDI-Zeichenfolgenart 6) basieren.
Bei dieser Situation gibt es zwei Probleme. Zum einen kennt die DB2-Host-Datenbank nicht den Unterschied zwischen den BIDI-Zeichenfolgenarten mit den IDs für codierten Zeichensatz 424 und 8616. Zum anderen erkennt die DB2-Host-Datenbank die ID für codierten Zeichensatz 62213 des DB2-Clients nicht. Sie unterstützt nur die ID für codierten Zeichensatz 862, die auf der gleichen Codepage wie die ID für codierten Zeichensatz 62213 basiert.
Sie müssen sicherstellen, daß die an die DB2-Host-Datenbank gesendeten Daten von Anfang an in der BIDI-Zeichenfolgenart 6 vorliegen, und Sie müssen DB2 Connect mitteilen, daß es eine BIDI-Layoutumsetzung für die von der DB2-Host-Datenbank empfangenen Daten ausführen soll. Katalogisieren Sie die DB2-Host-Datenbank wie folgt:
catalog dcs database nydb1 as TELAVIV parms ",,,,,,,,BIDI=8616"
Damit wird DB2 Connect angewiesen, die ID für codierten Zeichensatz 424 der DB2-Host-Datenbank durch 8616 zu überschreiben. Diese Überschreibung umfaßt die folgenden Verarbeitungsschritte:
Anmerkungen:
Wenn eine bestimmte bidirektionale ID für codierten Zeichensatz Probleme verursacht, die durch diese Empfehlungen nicht behoben werden können, setzen Sie die Umgebungsvariable oder den Registrierungsdatenbankwert DB2BIDI auf NO.
Beispiele für Parameterzeichenfolgen:
Beispielsweise könnten Sie eine der folgenden Angaben machen, wobei "\" (umgekehrter Schrägstrich) das Escape-Zeichen des Betriebssystems ist:
Unter AIX:
NOMAP /u/username/sqllib/map/dcs1new.map,D ,D ,,INTERRUPT_ENABLED NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE=\"\"JJMMTT\"\",,
Unter OS/2, Windows NT oder Windows 2000:
NOMAP d:\sqllib\map\dcs1new.map,D ,,INTERRUPT_ENABLED NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE=\"\"JJMMTT\"\",,
Sie können aber auch die Standardwerte akzeptieren, indem Sie keine Parameterzeichenfolge angeben.
Anmerkung: | Da Sie beim Angeben der Maske LOCALDATE in der Parameterzeichenfolge zwei
Paare von doppelten Anführungszeichen angeben müssen, müssen Sie das
Escape-Zeichen des Betriebssystems "\" (umgekehrter Schrägstrich) verwenden,
zum Beispiel:
db2 catalog dcs db x as y parms \",,,,,,LOCALDATE=\"\"JJMMTT\"\"\"Dies ergibt folgenden DCS-Verzeichniseintrag: Eintrag für DCS 1: Name der lokalen Datenbank = X Name der Zieldatenbank = Y Name des Anwendungs-Requesters = DCS-Parameter = ,,,,,,LOCALDATE="JJMMTT" Kommentar = Release-Stand des DCS-Verzeichnisses = 0x0100 |
Im Systemdatenbankverzeichnis können folgende Informationen angegeben werden:
Format: 1 bis 8 alphanumerische Einzelbytezeichen, einschließlich des Nummernzeichens (#), des kommerziellen A (@), des Dollarzeichens ($) und des Unterstreichungszeichens (_). Der Wert darf nicht mit einem Unterstreichungszeichen oder einer Zahl beginnen.
Für jede Datenbank muß mindestens ein Eintrag in jedem der drei Verzeichnisse (Knotenverzeichnis, DCS-Verzeichnis und Systemdatenbankverzeichnis) definiert werden. In einigen Fällen ist es möglicherweise sinnvoll, mehr als einen Eintrag für die Datenbank zu definieren.
Zum Beispiel soll möglicherweise die SQLCODE-Zuordnung für Anwendungen, die vom Host- oder AS/400-Datenbank-Server übertragen wurden, ausgeschaltet werden, aber die Standardzuordnung für Anwendungen, die für die Client-/Server-Umgebung entwickelt wurden, akzeptiert werden. Hierfür müßten Sie wie folgt vorgehen:
Beide Aliasnamen greifen auf dieselbe Datenbank zu, einer mit und der andere ohne SQLCODE-Zuordnung.