Podręcznik użytkownika

Zbieranie informacji

Dodatek B, Arkusz konfiguracji katalogów zawiera informacje, które należy zebrać. Może okazać się, że wygodnie jest ten arkusz skopiować i wpisać w nim wartości dla swojego systemu.

Katalog węzłów

W katalogu węzłów można wpisać następujące informacje:

Nazwa węzła
Pseudonim systemu serwera baz danych hosta lub AS/400, na którym przechowywana jest zdalna baza danych. Tę nazwę definiuje użytkownik. Należy ją wpisać w tabelach Node Directory Parameters (Parametry katalogu węzłów) i System Database Directory Parameters (Parametry systemowego katalogu bazy danych).

Format: 1-8 jednobajtowych znaków alfanumerycznych łącznie ze znakiem (#), (@), ($) i znakiem podkreślenia (_). Nazwa nie może zaczynać się znakiem podkreślenia ani cyfrą.

Protocol (Protokół)
Protokołem może być APPC lub TCPIP.

Symbolic destination name (Symboliczna nazwa docelowa)
Podczas definiowania węzła APPC należy użyć symbolicznej nazwy docelowej, podanej w tabeli CPI Communications Side Information (Informacje uboczne interfejsu CPI) (na przykład dla serwera Microsoft SNA Server należy użyć nazwy CPI-C Symbolic Destination Properties - Właściwości symbolicznej nazwy docelowej CPI-C). Wartość tę należy pobrać od osoby, która instalowała lub konfigurowała architekturę SNA. W symbolicznej nazwie docelowej rozróżnia się wielkość liter (może tu wystąpić kod powrotu SQL1338, jeśli występuje niezgodność wielkości liter w nazwach).

Security type (Typ ochrony)
Wykorzystywany typ ochrony. W przypadku węzłów APPC poprawne opcje to SAME, PROGRAM i NONE. W przypadku węzłów TCP/IP opcja SECURITY SOCKS określa, że węzeł będzie korzystał z mechanizmu SOCKS. Jeśli wybrano tę opcję, zmienne środowiskowe SOCKS_NS i SOCKS_SERVER są obowiązkowe i muszą być ustawione tak, aby mechanizm SOCKS był dostępny. Więcej informacji na ten temat można znaleźć w rozdziale Ochrona i podręczniku Command Reference.

Nazwa TCP/IP zdalnego hosta lub adres IP
W przypadku węzła TCP/IP jest to nazwa hosta TCP/IP lub adres TCP/IP. Jeśli podano nazwę hosta, musi ona zostać przekształcona na stacji roboczej DB2 Connect za pomocą serwera DNS (Domain Name Server) lub na podstawie lokalnego pliku hostów TCP/IP.

W przypadku zdalnych hostów DB2 for OS/390 nazwa hosta pojawia się w komunikacie DSNL004I (DOMAIN=nazwa_hosta) podczas uruchamiania Distributed Data Facility (DDF).

Nazwa usługi TCP/IP lub numer portu
W przypadku węzła TCP/IP jest to zdalna nazwa usługi TCP/IP lub numer portu. Musi ona być zdefiniowana na zdalnym hoście TCP/IP. Jako domyślny numer portu dla komunikacji DRDA zarejestrowano numer 446.

W przypadku zdalnych hostów DB2 for OS/390 numer portu jest definiowany jako PORT w zbiorze danych programu ładowania początkowego (BSDS); jest on także podawany w komunikacie DSNL004I (TCPPORT=numer_portu) przy uruchamianiu Distributed Data Facility (DDF).
Uwaga:Numer drugiego portu, który jest wykorzystywany w operacjach ponownej synchronizacji w dwufazowym zatwierdzaniu w przypadku połączeń TCP/IP, określa serwer. Na przykład zbiór danych programu ładowania początkowego DB2 Universal Database for OS/390 określa numer portu (RESPORT), który ma być używany tylko przy ponownej synchronizacji połączeń przychodzących do DB2 Universal Database for OS/390. Nie należy podawać tu żadnej nazwy usługi.

Katalog DCS

W katalogu DCS można umieścić następujące informacje:

Database name (Nazwa bazy danych)
Zdefiniowany przez użytkownika pseudonim serwera baz danych hosta lub systemu AS/400. Należy go wpisać w tabelach Parametry katalogu DCS (DCS Directory Parameters) i Parametry systemowego katalogu baz danych (System Database Directory Parameters).

Format: 1-8 jednobajtowych znaków alfanumerycznych łącznie ze znakiem (#), (@), ($) i znakiem podkreślenia (_). Nazwa nie może zaczynać się znakiem podkreślenia ani cyfrą.

Target database name (Nazwa docelowej bazy danych)
Jest to baza danych w następujących systemach serwera baz danych hosta lub AS/400:

MVS/ESA
Podsystem DB2 Universal Database for OS/390 identyfikowany przez LOCATION NAME.

LOCATION NAME można określić, logując się do TSO i wydając następujące zapytanie SQL za pomocą jednego z dostępnych narzędzi tworzenia zapytań:

   select current server from sysibm.sysdummy1

Definicja LOCATION NAME znajduje się także w MVS/ESA Boot Strap Data Set (BSDS), jak również w komunikacie DSNL004I (LOCATION=location), który jest zapisywany w momencie uruchamiania programu Distributed Data Facility (DDF).

OS/390
Podsystem DB2 Universal Database for OS/390 identyfikowany przez LOCATION NAME.

LOCATION NAME można określić, logując się do TSO i wydając następujące zapytanie SQL za pomocą jednego z dostępnych narzędzi tworzenia zapytań:

   select current server from sysibm.sysdummy1

Definicja LOCATION NAME znajduje się także w Boot Strap Data Set (BSDS), jak również w komunikacie DSNL004I (LOCATION=location), który jest zapisywany w momencie uruchamiania programu Distributed Data Facility (DDF).

VSE lub VM
Nazwa bazy danych (DBNAME).

OS/400
Nazwa relacyjnej bazy danych (RDBNAME).

Inne
W systemach OS/2, Windows NT Windows 2000 i systemach UNIX jest to alias bazy danych odnaleziony w katalogu bazy danych.

Application requester name (Nazwa requestera aplikacji)
Nazwa requestera aplikacji poprzedzająca żądania SQL do serwerów aplikacji DRDA. Requester aplikacji obsługuje żądania w imieniu aplikacji.

Format: AR <nazwa_requestera_aplikacji>

Wartością domyślną jest requester aplikacji DB2 Connect.

Łańcuch parametrów
Aby zmienić wartości domyślne, należy podać jeden lub wszystkie poniższe parametry w następującej kolejności. Łańcuch parametrów nie może być określony za pomocą Asysty podczas konfigurowania klienta. Jeśli używa się Procesora wiersza komend, łańcuch musi być ujęty w znaki pojedynczego cudzysłowu (na przykład w systemie OS/2 lub Windows NT) lub w znaki podwójnego cudzysłowu (na przykład w systemie AIX):

plik-odwzorowania
Nazwa pliku odwzorowania SQLCODE, który przesłania domyślne odwzorowanie SQLCODE. Aby wyłączyć odwzorowanie SQLCODE, należy podać NOMAP. Więcej informacji można znaleźć w rozdziale Odwzorowanie SQLCODE.

,D
Jest to parametr zajmujący drugą pozycję. Jeśli go podano, aplikacja rozłączy się z bazą danych serwera baz danych hosta lub AS/400 po otrzymaniu jednego z następujących kodów SQLCODE:
   SQL30000N
   SQL30040N
   SQL30050N
   SQL30051N
   SQL30053N
   SQL30060N
   SQL30070N
   SQL30071N
   SQL30072N
   SQL30073N
   SQL30074N
   SQL30090N

Jeśli nie podano parametru rozłączenia (,D), aplikacja zostanie odłączona tylko po otrzymaniu następujących kodów SQLCODE:

   SQL30020N
   SQL30021N
   SQL30041N
   SQL30061N
   SQL30081N

Wyjaśnienia dotyczące kodów można znaleźć w podręczniku Komunikaty.
Uwaga:Jeśli DB2 Connect rozłącza się z powodu błędu, wycofanie zmian następuje automatycznie.

,,INTERRUPT_ENABLED
Jest to parametr zajmujący trzecią pozycję. Jeśli na stacji roboczej DB2 Connect w katalogu DCS skonfigurowano parametr INTERRUPT_ENABLED i aplikacja klienta wywołuje przerwanie podczas połączenia z serwerem baz danych hosta lub AS/400, DB2 Connect zakończy połączenie i wycofa zmiany wprowadzone w ostatniej jednostce pracy. Ta reakcja na przerwanie obsługiwana jest w systemach AIX, OS/2, Windows NT i Windows 2000.

Aplikacja otrzymuje kod sqlcode (-30081) wskazujący, że połączenie z serwerem zostało zakończone. Następnie musi ustanowić nowe połączenie z serwerem baz danych hosta lub AS/400, aby przetwarzać następne żądania do bazy danych. Na platformach innych niż AIX V4.1 i wersje następne, SNA Server V3.1 i wersje następne, OS/2, Windows NT i Windows 2000 DB2 Connect nie obsługuje opcji automatycznego rozłączania, gdy aplikacja, która z niego korzysta otrzyma żądanie przerwania.
Uwaga:Opcja jest obsługiwana na wszystkich platformach w przypadku połączeń TCP/IP. Klient może odłączyć gniazdo, ale - w zależności od implementacji serwera - mogą pojawić się oczekujące żądania odbioru. DB2 Universal Database for OS/390 używa wywołań asynchronicznych, może więc wykryć utratę połączenia i wycofać zmiany wprowadzane za pomocą instrukcji SQL, które są w toku i wykonują się długo.

,,,,,SYSPLEX
Parametru na szóstej pozycji można użyć, aby w sposób jawny włączyć obsługę SYSPLEX DB2 Connect dla określonej bazy danych.

Wprowadzono nową zmienną profilu (środowiska lub rejestru) o nazwie DB2SYSPLEX_SERVER. Można jej użyć do wyłączenia obsługi SYSPLEX na poziomie stacji roboczej.

,,,,,,LOCALDATE="<wartość>"
Parametr na siódmej pozycji umożliwia włączenie obsługi formatowania daty w DB2 Connect. Zostało to zaimplementowane przy użyciu maski daty dla <wartość> w sposób następujący:

Załóżmy, że uruchomiono następujące instrukcje Procesora wiersza komend:

      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

Alias bazy danych newyork1 ma być użyty przy dostępie do bazy danych hosta bez przekształcania daty, ponieważ nie określono żadnej maski daty.

Nowa obsługa formatowania daty pozwala jednak używać następujących komend Procesora wiersza komend. W tym przypadku, ponieważ używany jest Procesor wiersza komend, a łańcuch parametrów ujęto w znaki podwójnego cudzysłowu, wartość LOCALDATE musi zostać ujęta w dwie pary podwójnych cudzysłowów. Warto zwrócić uwagę na użycie znaku zmiany znaczenia z systemu operacyjnego "\" (ukośnik odwrotny), który zapewnia, że znaki podwójnego cudzysłowu nie zostaną usunięte ze specyfikacji LOCALDATE. Patrz także sekcja Określanie łańcucha parametrów.

      catalog dcs database nydb2 as new_york
        parms \",,,,,,LOCALDATE=\"\"YYYYMMDD\"\"\"
   catalog database nydb2 as newyork2 at node nynode
                authentication dcs

Alias bazy danych "newyork2" umożliwia dostęp do tej samej bazy danych hosta, lecz określa także maskę daty. Przykład ten pokazuje, że maska daty jest określana za pomocą parametru LOCALDATE i stanowi ona parametr zajmujący siódmą pozycję w polu PARMS pozycji katalogu DCS.

Aby maska daty była poprawna, muszą zostać spełnione WSZYSTKIE następujące warunki:

  1. Może być tylko jeden ciąg znaków Y, M i D, przy czym Y jest cyfrą roku, M jest cyfrą miesiąca, a D - cyfrą dnia.
  2. Maksymalna liczba znaków Y w ciągu wynosi 4.
  3. Maksymalna liczba znaków M w ciągu wynosi 2.
  4. Maksymalna liczba znaków D w ciągu wynosi 2.

Następujące maski daty są poprawne:

   "YYyyMmDd" - znaki Y, M i D mogą być małe lub wielkie
   "MM+DD+YYYY" - można mieć maskę dłuższą niż 10 bajtów,
                  zawierającą znaki inne niż Y, M i D
   "abcYY+MM"   - ciąg znaków D nie musi wystąpić

Następujące maski daty są niepoprawne:

   "YYYYyMMDD"  - niepoprawny jest piąty znak Y w sekwencji
   "YYYYMDDM"   - niepoprawne są dwie sekwencje znaków M

Jeśli maska daty jest niepoprawna, nie wystąpi błąd. Zostanie ona po prostu zignorowana. To, że maska daty jest poprawna, nie oznacza jeszcze, że będzie używana. Przekształcenie formatu daty oparte na poprawnej masce zostanie wykonane, jeśli spełnione będą WSZYSTKIE następujące warunki:

  1. Nie wystąpi błąd SQL.
  2. Wartością wyjściową jest data w formacie ISO lub JIS.
  3. Obszar wyjściowy daty ma długość przynajmniej 10 bajtów. Jest to minimalny rozmiar obszaru wyjściowego daty, nawet jeśli nie wykonano ŻADNEGO przekształcania. Warunek ten musi być spełniony, nawet gdy maska daty jest krótsza niż 10 bajtów.
  4. W pozycji katalogu DCS określono poprawną maskę daty i pasuje ona do obszaru wyjściowego daty.

,,,,,,,CHGPWD_SDN=<nazwa>
Ten ósmy parametr pozycyjny jest używany do podania symbolicznej nazwy docelowej, która ma być użyta przez narzędzie zarządzające okresami ważności haseł (Password Expiration Management) (PEM). W wartościach określonych dla <nazwa> rozróżniane są wielkości liter.

Sekcja Zmiana hasła w systemie MVS przedstawia przykład wpisywania do katalogu, katalogu bazy danych za pomocą CHGPWD_SDN w następujący sposób:

   catalog dcs database db1 as dsn_db_1 parms
      ",,,,,,,CHGPWD_SDN=pempgm"

,,,,,,,,BIDI=<ccsid>
Dziewiąty parametr pozycyjny jest używany do podania dwukierunkowego (BiDi) CCSID, który ma być użyty do przesłonięcia domyślnego dwukierunkowego CCSID bazy danych serwera. Na przykład:
    ",,,,,,,,BIDI=xyz" 

gdzie xyz oznacza przesłonięcie CCSID (patrz uwaga (BIDI_NOTE1)).

Listę obsługiwanych dwukierunkowych CCSID z typami łańcuchów można znaleźć w podręczniku Administration Guide.

Następujące atrybuty BiDi są wymagane do poprawnej obsługi danych dwukierunkowych na różnych platformach:

Ponieważ wartości domyślne na różnych platformach są różne, problemy pojawiają się, gdy dane DB2 są przesyłane między platformami. Na przykład platformy Windows używają danych LOGICAL UNSHAPED, podczas gdy dane w systemie MVS i OS/390 mają zazwyczaj format SHAPED VISUAL. Dlatego bez obsługi tych atrybutów dane wysyłane z DB2 for MVS lub OS/390 do DB2 Connect w systemie operacyjnym Windows są wyświetlane nieprawidłowo.

Gdy dane są wymienianie między DB2 Connect a bazą danych znajdującą się na serwerze, zazwyczaj odbiorca wykonuje konwersję danych przychodzących. Ta sama zasada ma również zastosowanie do dwukierunkowej (BiDi) transformacji układu, występującej oprócz zwykłej konwersji strony kodowej. Jednak obecnie żaden host DB2 nie obsługuje dwukierunkowych (BiDi-specific) CCSID ani dwukierunkowej (BiDi) transformacji układu. Dlatego ulepszono DB2 Connect o opcjonalną możliwość wykonywania dwukierunkowej (BiDi) transformacji układu dla danych przesyłanych do bazy danych serwera (oprócz możliwości wykonania tej transformacji dla danych odebranych z bazy danych serwera).

Aby DB2 Connect mógł wykonać dwukierunkową (BiDi) transformację układu dla danych wychodzących do bazy danych serwera, BiDi CCSID bazy danych serwera musi zostać przesłonięty (patrz sekcja (BIDI_NOTE2)). Można to wykonać, używając parametru BIDI w polu PARMS pozycji katalogu DCS dla bazy danych serwera.

Użycie tej opcji przedstawia następujący przykład.

Przypuśćmy, że klient DB2 w wersji hebrajskiej korzysta z CCSID 62213 (typ łańcucha BiDi 5) i chce uzyskać dostęp do bazy danych hosta DB2 korzystającej z CCSID 424 (typ łańcucha BiDi 4). Wie jednak, że dane znajdujące się w bazie danych hosta DB2 są oparte o CCSID 8616 (typ łańcucha BiDi 6).

W takiej sytuacji występują dwa problemy. Pierwszy polega na tym, że baza danych hosta DB2 nie zna różnicy między typami łańcuchów BiDi o identyfikatorach CCSID 424 i 8616. Drugi problem polega na tym, że baza danych hosta DB2 nie rozpoznaje identyfikatora CCSID 62213 klienta DB2. Obsługuje ona tylko CCSID 862, oparty na tej samej stronie kodowej co CCSID 62213.

Należy sprawdzić, czy dane wysłane do bazy danych hosta DB2 mają format łańcucha BiDi typu 6, należy również powiadomić DB2 Connect, że musi wykonać dwukierunkową (BiDi) transformację układu dla danych, które odbiera z bazy danych hosta DB2. Dla bazy danych hosta DB2 należy użyć następującej komendy:

   catalog dcs database nydb1 as TELAVIV parms ",,,,,,,,BIDI=8616"

Komenda ta powiadamia DB2 Connect, aby przesłonił CCSID bazy danych hosta DB2 424 wartością 8616. Przesłonięcie to obejmuje następujące przetwarzanie:

  1. DB2 Connect połączy się z bazą danych hosta DB2, używając CCSID 862.
  2. DB2 Connect wykona dwukierunkową (BiDi) transformację układu dla danych, które ma wysłać do bazy danych hosta DB2 z CCSID 62213 (łańcuch BiDi typu 5) na CCSID 62221 ( łańcuch BiDi typu 6).
  3. DB2 Connect wykona dwukierunkową (BiDi) transformację układu dla danych, które odbiera z bazy danych hosta DB2 z CCSID 8616 (łańcuch BiDi typu 6) na CCSID 62213 (łańcuch BiDi typu 5).

Uwagi:

  1. Aby parametr BIDI był aktywny, należy ustawić wartość zmiennej środowiskowej lub rejestru DB2BIDI na YES.

  2. Jeśli produkt DB2 Connect ma wykonać transformację układu dla danych wysyłanych do bazy danych hosta DB2, nawet gdy nie nadpisano identyfikatora CCSID, należy dodać parametr BIDI w polu PARMS katalogu bazy danych DCS. W tym przypadku CCSID, który należy udostępnić, jest domyślnym CCSID bazy danych hosta.

  3. W niektórych przypadkach użycie dwukierunkowego CCSID może spowodować samoistną modyfikację zapytania SQL w taki sposób, że nie zostanie rozpoznana przez serwer DB2. Szczególnie należy unikać używania identyfikatorów CCSID IMPLICIT CONTEXTUAL i IMPLICIT RIGHT-TO-LEFT, gdy można użyć różnych typów łańcuchów. Działanie identyfikatorów CCSID CONTEXTUAL może być nieprzewidywalne, jeśli zapytanie SQL zawiera łańcuchy w cudzysłowie. Należy unikać używania łańcuchów w cudzysłowie w instrukcjach SQL, a zamiast tego należy używać zmiennych języka bazowego, jeśli jest to możliwe.

    Jeśli konkretny dwukierunkowy CCSID powoduje problemy, których nie można rozwiązać uwzględniając powyższe zalecenia, należy ustawić zmienną środowiskową lub wartość rejestru DB2BIDI na NO.

Określanie łańcucha parametrów

Podano tu przykłady dopuszczalnych łańcuchów parametrów.

Znak "\" (ukośnik odwrotny) jest znakiem zmiany znaczenia, związanym z systemem operacyjnym:

W systemie AIX:

      NOMAP
   /u/username/sqllib/map/dcs1new.map,D
   ,D
   ,,INTERRUPT_ENABLED
   NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE=\"\"YYMMDD\"\",,

W systemach OS/2, Windows NT i Windows 2000:

       NOMAP
   d:\sqllib\map\dcs1new.map,D
   ,,INTERRUPT_ENABLED
   NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE=\"\"YYMMDD\"\",,  

Można też zaakceptować wartości domyślne, nie podając łańcucha parametrów.
Uwaga:Ponieważ przy określaniu maski LOCALDATE podaje się dwie pary znaków podwójnego cudzysłowu w łańcuchu parametru, należy użyć znaku zmiany znaczenia "\" (ukośnik odwrotny), na przykład:
      db2 catalog dcs db x as y parms \",,,,,,LOCALDATE=\"\"YYMMDD\"\"\"
Wynikiem tej komendy jest następująca pozycja katalogu DCS:
      Pozycja 1 DCS:
 
    Local database name                = X
    Target database name               = Y
    Application requester name         =
    DCS parameters                     = ,,,,,,LOCALDATE="YYMMDD"
    Comment                            =
    DCS directory release level        = 0x0100

Systemowy katalog baz danych

W systemowym katalogu baz danych można podać następujące informacje:

Database name (Nazwa bazy danych)
Ta sama wartość, którą podano w tabeli Parametry katalogu DCS (DCS Directory Parameters).

Database alias (Alias bazy danych)
Alias serwera baz danych hosta lub AS/400. Nazwa ta będzie używana przez aplikację, która korzysta z bazy danych. Wartością domyślną jest podana nazwa bazy danych.

Format: 1-8 jednobajtowych znaków alfanumerycznych łącznie ze znakiem (#), (@), ($) i znakiem podkreślenia (_). Nazwa nie może zaczynać się znakiem podkreślenia ani cyfrą.

Node name (Nazwa węzła)
Ta sama wartość, którą podano w tabeli Parametry katalogu węzłów (Node Directory Parameters).

Authentication (Uwierzytelnianie)
Określa, gdzie będzie sprawdzana nazwa i hasło użytkownika. Poprawne opcje to: SERVER, SERVER_ENCRYPT, CLIENT, DCE, DCS i DCS_ENCRYPT. Więcej informacji można znaleźć w sekcji Ochrona.

Definiowanie wielu pozycji dla jednej bazy danych

Dla każdej bazy danych należy zdefiniować przynajmniej jedną pozycję w każdym z trzech katalogów (katalogu węzłów, katalogu DCS i systemowym katalogu baz danych). W pewnych przypadkach może być potrzebne zdefiniowanie kilku pozycji dla jednej bazy danych.

Można wyłączyć odwzorowanie SQLCODE dla aplikacji, które przeniesiono z serwera baz danych hosta lub AS/400, ale zaakceptować domyślne odwzorowanie dla aplikacji, które utworzono dla środowiska klient/serwer. Można to zrobić w następujący sposób:

Oba aliasy odwołują się do tej samej bazy danych, jeden używa przy tym odwzorowania SQLCODE, drugi - nie.


[ Początek strony | Poprzednia strona | Następna strona | Spis treści | Indeks ]