DB2 Connect Benutzerhandbuch

Zusammentragen von Informationen

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.

Knotenverzeichnis

Im Knotenverzeichnis können folgende Informationen angegeben werden:

Knotenname (Node Name)
Ein Kurzname für das Datenbank-Server-System des Hosts oder Systems IBM AS/400, auf dem sich die ferne Datenbank befindet. Dieser Name ist benutzerdefiniert. Derselbe Knotenname muß sowohl in der Parametertabelle für das Knotenverzeichnis als auch in der Parametertabelle für das Systemdatenbankverzeichnis 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.

Protokoll (Protocol)
Kann APPC oder TCPIP sein.

Symbolischer Bestimmungsname (Symbolic Destination Name)
Verwenden Sie beim Definieren eines APPC-Knotens den symbolischen Bestimmungsnamen, der in der Tabelle mit Nebeninformationen zur CPI-Kommunikation angegeben wurde (z. B. den Namen der CPI-DFV-Eigenschaften für den symbolischen Bestimmungsnamen (CPI-C Symbolic Destination Properties) für Microsoft SNA-Server). Dieser Wert ist von dem Benutzer erhältlich, der SNA installiert und/oder konfiguriert hat. Der symbolische Bestimmungsname ist abhängig von der Groß-/Kleinschreibung (Sie erhalten möglicherweise einen Rückkehrcode SQL1338, wenn die Groß-/Kleinschreibung in den Namen nicht genau beachtet wird).

Sicherheitseinstufung (Security Type)
Die vorzunehmende Art von Sicherheitsprüfung. Gültige Optionen für APPC-Knoten sind SAME, PROGRAM und NONE. Für TCP/IP-Knoten ist SECURITY SOCKS eine Option, die angibt, daß der Knoten für SOCKS aktiviert wird. In diesem Fall sind die Umgebungsvariablen SOCKS_NS und SOCKS_SERVER verbindlich und müssen zur Aktivierung von SOCKS festgelegt sein. Weitere Informationen finden Sie in Kapitel 10, Sicherheit und im Handbuch Command Reference.

Ferner TCP/IP-Host-Name oder ferne IP-Adresse (TCP/IP Remote Hostname or IP Address
Beim Definieren eines TCP/IP-Knotens ist dies entweder der ferne TCP/IP-Host-Name oder die ferne TCP/IP-Adresse. Wenn ein Host-Name angegeben ist, muß er auf der DB2 Connect-Workstation aufgelöst werden. Dies erfolgt entweder durch die DNS-Suchfunktion (Domain Name System Lookup Function) oder durch einen Eintrag in der lokalen TCP/IP-Datei hosts.

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.

TCP/IP-Servicename oder -Anschlußnummer (TCP/IP Service Name or Port number)
Beim Definieren eines TCP/IP-Knotens ist dies entweder der ferne TCP/IP-Servicename oder die ferne TCP/IP-Anschlußnummer. Dieser Wert muß für TCP/IP auf dem fernen Host definiert werden. Anschlußnummer 446 wurde als Standardanschlußnummer für DRDA eingetragen.

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.

DCS-Verzeichnis

Im DCS-Verzeichnis können folgende Informationen angegeben werden:

Datenbankname (Database Name)
Ein benutzerdefinierter Kurzname für den Host- oder AS/400-Datenbank-Server. Derselbe Datenbankname muß sowohl in der Parametertabelle für das DCS-Verzeichnis als auch in der Parametertabelle für das Systemdatenbankverzeichnis 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.

Zieldatenbankname (Target Database Name)
Die Datenbank des Datenbank-Server-Systems auf dem Host oder System IBM AS/400; folgende Angaben sind möglich:

MVS/ESA
Ein Subsystem mit DB2 Universal Database für OS/390, das über seinen LOCATION NAME (Standortnamen) angegeben 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) von MVS/ESA definiert und wird in der Nachricht DSNL004I (LOCATION=standort) angegeben, die geschrieben wird, wenn DDF (Distributed Data Facility) gestartet wird.

OS/390
Ein Subsystem mit DB2 Universal Database für OS/390, das über seinen LOCATION NAME angegeben 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.

VSE oder VM
Der Datenbankname (DBNAME)

OS/400
Der Name der relationalen Datenbank (RDBNAME)

Andere Systeme
Bei OS/2-, Windows NT-, Windows 2000- und UNIX-gestützten Systemen der im Datenbankverzeichnis angegebene Aliasname für die Datenbank

Name des Anwendungs-Requesters (Application Requester Name)
Der Name des Anwendungs-Requesters, der SQL-Anforderungen an DRDA-Anwendungs-Server weiterleitet. Der Anwendungs-Requester bearbeitet Anforderungen für das Anwendungsprogramm.

Format: AR <anwendungs-requester-name>

Standardmäßig wird der Anwendungs-Requester von DB2 Connect verwendet.

Parameterzeichenfolge (Parameter String)
Wenn die Standardwerte geändert werden sollen, müssen beliebige oder alle der folgenden Parameter in der nachstehenden Reihenfolge angegeben werden. Die Parameterzeichenfolge kann nicht mit 'Client-Konfiguration - Unterstützung' festgelegt werden, und bei Verwendung des Befehlszeilenprozessors muß die Parameterzeichenfolge von einfachen Anführungszeichen (zum Beispiel unter OS/2 oder Windows NT) bzw. von doppelten Anführungszeichen (zum Beispiel unter AIX) umschlossen werden:

zuordnungsdatei
Der Name einer SQLCODE-Zuordnungsdatei, die die Standard-SQLCODE-Zuordnung überschreibt. Wenn die SQLCODE-Zuordnung ausgeschaltet werden soll, geben Sie NOMAP an. Weitere Informationen finden Sie in Kapitel 11, SQLCODE-Zuordnung.

,D
Dies ist der zweite positionsgebundene Parameter. Wird er angegeben, trennt die Anwendung die Verbindung zur Datenbank des Datenbank-Servers auf dem Host oder System IBM AS/400, wenn einer der folgenden SQLCODE-Werte zurückgegeben wird:
     
              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.

,,INTERRUPT_ENABLED
Dies ist der dritte positionsgebundene Parameter. Wenn INTERRUPT_ENABLED im DCS-Verzeichnis auf der DB2 Connect-Workstation konfiguriert ist und eine Client-Anwendung eine Unterbrechung absetzt, während eine Verbindung zum Host- oder AS/400-Datenbank-Server besteht, führt DB2 Connect die Unterbrechung aus. Dabei wird die Verbindung freigegeben und die Arbeitseinheit zurückgesetzt. Dieses Unterbrechungsverhalten wird von AIX, OS/2, Windows NT und Windows 2000 unterstützt.

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.

,,,,,SYSPLEX
Mit diesem Parameter, dem sechsten positionsgebundenen Parameter, können Sie explizit SYSPLEX-Unterstützung unter DB2 Connect für eine bestimmte Datenbank aktivieren.

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.

,,,,,,LOCALDATE="<wert>"
Mit diesem Parameter, dem siebten positionsgebunden Parameter, können Sie Unterstützung für Datumsformatierung unter DB2 Connect aktivieren. Sie wird wie folgt mit Hilfe einer Datumsmaske für <wert> implementiert:

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):

  1. Es kann nur jeweils eine Folge von Angaben aus J, M und T geben, wobei J eine Jahresziffer, M eine Monatsziffer und T eine Tagesziffer ist.
  2. Die maximale Anzahl für J in einer Folge ist 4.
  3. Die maximale Anzahl für M in einer Folge ist 2.
  4. Die maximale Anzahl für T in einer Folge ist 2.

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:

  1. Es gibt keine SQL-Fehler.
  2. Die Ausgabe ist ein Datumswert in ISO-ähnlichem (ISO und JIS) Format.
  3. Der Ausgabedatenbereich ist mindestens 10 Byte lang. Dies ist die minimale Größe eines Ausgabedatenbereichs für die Speicherung eines Datenwerts, selbst wenn KEINE Datumsformatumsetzung ausgeführt wird. Diese Anforderung gilt selbst dann, wenn die Datumsformatmaske kürzer als 10 Byte ist.
  4. Im DCS-Verzeichniseintrag ist eine gültige Datumsformatmaske angegeben, und diese Maske paßt in den Ausgabedatenbereich.

,,,,,,,CHGPWD_SDN=<name>
Mit diesem Parameter, dem achten positionsgebundenen Parameter, können Sie den symbolischen Bestimmungsnamen für die Kennwortablaufverwaltung angeben. Der für <name> angegebene Wert ist von der Groß-/Kleinschreibung abhängig.

Ä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=<ccsid>
Mit diesem Parameter, dem neunten positionsgebundenen Parameter, können Sie die bidirektionale ID für codierten Zeichensatz angeben, durch die der Standardwert für die bidirektionale (BIDI) ID für codierten Zeichensatz der Server-Datenbank überschrieben werden soll. Beispiel:
    ",,,,,,,,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:

  1. DB2 Connect stellt die Verbindung zur DB2-Host-Datenbank mit der ID für codierten Zeichensatz 862 her.
  2. DB2 Connect führt die BIDI-Layoutumsetzung für die Daten aus, die an die DB2-Host-Datenbank gesendet werden sollen. Dabei wird die ID für codierten Zeichensatz 62213 (BIDI-Zeichenfolgenart 5) in die ID für codierten Zeichensatz 62221 (BIDI-Zeichenfolgenart 6) der DB2-Host-Datenbank umgesetzt.
  3. DB2 Connect führt die BIDI-Layoutumsetzung für die Daten aus, die von der DB2-Host-Datenbank empfangen werden. Dabei wird die ID für codierten Zeichensatz 8616 (BIDI-Zeichenfolgenart 6) der DB2-Host-Datenbank in die ID für codierten Zeichensatz 62213 (BIDI-Zeichenfolgenart 5) umgesetzt.

Anmerkungen:

  1. Die Umgebungsvariable bzw. der Registrierungswert DB2BIDI muß auf YES gesetzt werden, damit der Parameter BIDI angewendet wird.

  2. Wenn DB2 Connect eine Layoutumsetzung für die Daten ausführen soll, die an die DB2-Host-Datenbank gesendet werden sollen, ohne daß die ID für codierten Zeichensatz überschrieben werden muß, müssen Sie trotzdem den Parameter BIDI im Feld PARMS des DCS-Datenbankverzeichnisses hinzufügen. In diesem Fall müssen Sie den Standardwert für die ID für codierten Zeichensatz der DB2-Host-Datenbank angeben.

  3. In einigen Fällen wird die SQL-Abfrage durch eine bidirektionale ID für codierten Zeichensatz derart geändert, daß sie vom DB2-Server nicht erkannt wird. Versuchen Sie, vor allem IDs für codierten Zeichensatz des Typs IMPLICIT CONTEXTUAL und IMPLICIT RIGHT-TO-LEFT zu vermeiden, wenn eine andere Zeichenfolgenart verwendet werden kann. Bei IDs für codierten Zeichensatz des Typs CONTEXTUAL kann es zu unvorhersehbaren Ergebnissen kommen, wenn die SQL-Abfrage Zeichenfolgen in Anführungszeichen enthält. Vermeiden Sie die Verwendung von Zeichenfolgen in Anführungszeichen in SQL-Anweisungen. Verwenden Sie statt dessen Host-Variablen, sofern möglich.

    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.

Angeben der Parameterzeichenfolge

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

Systemdatenbankverzeichnis

Im Systemdatenbankverzeichnis können folgende Informationen angegeben werden:

Datenbankname (Database Name)
Derselbe Wert, der in der Parametertabelle für das DCS-Verzeichnis angegeben wurde.

Aliasname für die Datenbank (Database Alias)
Ein Aliasname für den Host- oder AS/400-Datenbank-Server. Dieser Name wird von jedem Anwendungsprogramm verwendet, das auf die Datenbank zugreift. Als Standardwert wird der für den Datenbanknamen angegebene Wert verwendet.

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.

Knotenname (Node Name)
Derselbe Wert, der in der Parametertabelle für das Knotenverzeichnis angegeben wurde.

Authentifizierung (Authentication)
Gibt an, wo die Gültigkeitsprüfung für den Namen und das Kennwort des Benutzers erfolgen soll. Gültige Optionen sind: SERVER, SERVER_ENCRYPT, CLIENT, DCE, DCS und DCS_ENCRYPT. Weitere Informationen finden Sie in Kapitel 10, Sicherheit.

Definieren mehrerer Einträge für dieselbe Datenbank

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.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]