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.
W katalogu węzłów można wpisać następujące informacje:
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ą.
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).
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. |
W katalogu DCS można umieścić następujące informacje:
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ą.
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).
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).
Format: AR <nazwa_requestera_aplikacji>
Wartością domyślną jest requester aplikacji DB2 Connect.
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. |
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. |
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.
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:
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:
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=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:
Uwagi:
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.
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 |
W systemowym katalogu baz danych można podać następujące informacje:
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ą.
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.