Ръководство за потребителя

Събиране на информация

Приложение B, Работен лист за персонализиране на директории показва информацията, която трябва да съберете. Може да се окаже удобно за вас, ако направите копие на таблицата и въведете стойностите за вашата система.

Директория на възлите

Можете да определите следната информация в директорията на възлите:

Име на възел
Прякор за хоста или AS/400 сървъра на базата данни, на който се намира отдалечената база данни. Това име се определя от потребителя. Напишете едно и също име на възел и в двете таблици - с параметрите на директорията на възлите и с параметрите на системната директория на базата данни.

Формат: 1-8 еднобитови буквено-цифрови символи, включително числен знак (#), знака at (@), знака за долар ($), и долно тире (_). Не може да започва с долно тире или число.

Протокол
Може да е APPC или TCPIP.

Име на символно предназначение
При определяне на APPC възел използвайте името на символно предназначение, което е било определено в таблицата с информацията за CPI комуникациите (например името на CPI-C Symbolic Destination Properties, когато се използва Microsoft SNA сървър). Трябва да получите тази стойност от човека, който е инсталирал и/или конфигурирал SNA. В името на символното предназначение е от значение използването на малки и главни букви (може да получите код на връщане SQL1338, ако има несъответствие между главни и малки букви в имената).

Тип на защита
Типът на защитните проверки, които ще се изпълнят. За APPC възлите валидните опции са SAME, PROGRAM и NONE. За TCP/IP възли SECURITY SOCKS е опция, която определя, че възелът ще е активен за SOCKS, като в този случай променливите от обкръжението SOCKS_NS и SOCKS_SERVER са задължителни и трябва да са настроени да разрешават SOCKS. За допълнителна информация вижте Защита и се обърнете към Справочник на командите.

TCP/IP име на отдалечен хост или IP адрес
При дефиниране на TCP/IP възел или името на отдалечения TCP/IP хост, или отдалечен TCP/IP адрес. Ако е определено име на хост, тогава трябва да е получено на DB2 Connect работната станция чрез сървъра на имена на области (DNS - Domain Name Server), или чрез запис в локалния файл на TCP/IP хост.

При отдалечен хост на DB2 за OS/390 името се появява в съобщението DSNL004I (DOMAIN=име на хост), когато се стартира помощното средство за разпределени данни (DDF - Distributed Data Facility).

Име на TCP/IP услуга или номер на портr
При определяне на TCP/IP възел - име на отдалечена TCP/IP услуга или номер на порт. Трябва да се определи за TCP/IP на отдалечения хост. Номерът на порт 446 е регистриран като номер на порт по подразбиране за DRDA.

При отдалечен хост на DB2 за OS/390 номерът на порта се определя в Boot Strap Data Set (BSDS) като PORT и освен това се намира в съобщението DSNL004I (TCPPORT=номер на порт) при стартиране на помощното средство за разпределени данни (DDF).
Забележка:Сървърът присвоява втория порт, използван при операции с двуфазов протокол за записване на промените и синхронизиране през TCP/IP свързвания. Например DB2 Universal Database за OS/390 bootstrap dataset присвоява номер на порт (RESPORT), който да се използва за повторно синхронизиране само на входящите свързвания към DB2 Universal Database за OS/390. В този случай не е необходимо да се дефинира име на услуга.

DCS Директория

Можете да определите следната информация в DCS директорията:

Име на базата данни
Дефиниран от потребителя прякор за хоста или AS/400 сървъра на базата данни. Използвайте едно и също име на база данни в двете таблици - с параметрите на DCS директорията и с параметрите на системната директория на базата данни.

Формат: 1-8 еднобитови буквено-цифрови символи, включително числен знак (#), знака at (@), знака за долар ($), и долно тире (_). Не може да започва с долно тире или число.

Име на базата данни приемник
Базата данни на хоста или AS/400 сървъра на база данни, както следва:

MVS/ESA
DB2 Universal Database за OS/390 подсистема, идентифицирана от своето ИМЕ НА МЯСТО.

ИМЕТО НА МЯСТОТО може да се определи след влизане в TSO и генериране на следното SQL запитване с помощта на някое от достъпните средства:

   select current server from sysibm.sysdummy1

ИМЕТО НА МЯСТОТО освен това се дефинира в MVS/ESA Boot Strap Data Set (BSDS) и се съдържа в съобщението DSNL004I (LOCATION=място), което се записва при стартирането на Distributed Data Facility (DDF).

OS/390
DB2 Universal Database за OS/390 подсистема, идентифицирана от своето ИМЕ НА МЯСТО.

ИМЕТО НА МЯСТОТО може да се определи след влизане в TSO и генериране на следното SQL запитване с помощта на някое от достъпните средства:

   select current server from sysibm.sysdummy1

ИМЕТО НА МЯСТОТО освен това се дефинира в Boot Strap Data Set (BSDS) и се съдържа в съобщението DSNL004I (LOCATION=място), което се записва при стартирането на Distributed Data Facility (DDF).

VSE или VM
Името на базата данни (DBNAME)

OS/400
Името на релационна база данни (RDBNAME)

Други
За OS/2, Windows NT, Windows 2000 и UNIX-базирани системи псевдонимът на базата данни, който се намира в директорията на базата данни.

Име на средство за обработка на запитвания
Името на средството за обработка на запитвания, което препраща SQL заявките към DRDA сървъра на приложения. Средството за обработка на запитвания обработва заявките от името на приложната програма.

Формат: AR <име_на_рикуестър_на_приложения>

По подразбиране е DB2 Connect средството за обработка на запитвания.

Параметричен низ
Ако искате да промените настройките по подразбиране, определете следните параметри в посочения ред. Параметричният низ не може да се определи с помощта на Асистента за конфигуриране на клиенти, а като се използва CLP, параметричният низ трябва да е обграден от единични кавички (например на OS/2 или Windows NT) или двойни кавички (например на AIX):

файл-карта
Името на файла със SQLCODE съответствията, който заменя SQLCODE съответствията по подразбиране. За да изключите SQLCODE съответствията, определете NOMAP. За повече информация вижте Преобразуване на SQLCODE.

,D
Това е втория позиционен параметър. Ако е определен, приложението ще прекъсне връзката към базата данни на хоста или на AS/400 сървъра на база данни, когато се върне един от следните SQLCODE кодове:
   SQL30000N
SQL30040N
   SQL30050N
SQL30051N
   SQL30053N
   SQL30060N
   SQL30070N
   SQL30071N
   SQL30072N
   SQL30073N
   SQL30074N
   SQL30090N

Когато не е определен параметър за прекъсване на връзката ,D свързването ще се прекъсне само когато се върнат следните SQLCODE кодове:

   SQL30020N
   SQL30021N
   SQL30041N
   SQL30061N
   SQL30081N

Обяснения на тези кодове потърсете в Справочник на съобщенията.
Забележка:Ако поради грешка DB2 Connect прекъсне връзката, автоматично се изпълнява ролбек.

,,INTERRUPT_ENABLED
Това е третият позиционен параметър. Ако INTERRUPT_ENABLED е конфигуриран в DCS директория на DB2 Connect работна станция и приложение на клиент генерира прекъсване, докато е свързано към хоста или AS/400 сървъра на база данни, DB2 Connect ще изпълни прекъсване, като премахне свързването и изпълни ролбек за единицата работа. Такова прекъсване се поддържа на AIX, OS/2, Windows NT и Windows 2000.

Приложението ще получи sqlcode (-30081), който показва, че е прекъсната връзката към сървъра. Приложението трябва след това да установи нова връзка към хоста или AS/400 сървъра на база данни, за да обработи останалите заявки. На платформи, различни от AIX V4.1 и следващи, SNA Server V3.1 и следващи, OS/2, Windows NT и Windows 2000, DB2 Connect не поддържа възможността за автоматично прекъсване на връзка, когато приложение, което я използва, получи заявка за прекъсване.
Забележка:Тази поддръжка работи на TCP/IP свързвания на всички платформи. Клиентът може да прекъсне връзката, но - в зависимост от реализацията на сървъра - може да има или не неполучени неща. DB2 Universal Database за OS/390 използва асинхронни сокет повиквания и следователно може да открие загубата на връзката и да върне обратно всички дълготрайни SQL изрази, които са активни в момента.

,,,,,SYSPLEX
Този параметър, шестият позиционен параметър, може да се използва, за да се активира явно SYSPLEX поддръжката на DB2 Connect за определена база данни.

Въведена е нова променлива на профила (обкръжението или регистъра), наречена DB2SYSPLEX_SERVER, която може да се използва за деактивиране поддръжката на SYSPLEX на ниво работна станция.

,,,,,,LOCALDATE="<стойност>"
ТОзи параметър, седмият позиционен параметър, се използва за активиране поддръжка на формат за датата от DB2 Connect. Това се реализира с помощта на маска за дата за <стойност> както следва:

Да предположим, че подадете следните оператори на процесора за обработка на команди (CLP):

   
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

Псевдонимът на базата данни newyork1 се използва за достъп до хост база данни без трансформиране на датата, тъй като не е определена маска за датата.

Въпреки това с новия тип поддръжка за форматиране на датата можете да използвате следните CLP команди. Тъй като в този случай се използва CLP и самият параметричен низ се определя с двойни кавички, стойността LOCALDATE трябва да се определи вътре в две двойки двойни кавички. Отбележете използването на специалния символ на операционната система "\" (наклонена черта), за да сте сигурни, че двойните кавички няма да се пропуснат от спецификацията на LOCALDATE. Вижте също Определяне на параметричния низ.

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

Псевдонимът на базата данни "newyork2" ви дава достъп до същата хост база данни, но освен това има определена маска за формат на датата. Този пример показва, че маската за формата на датата се определя с помощта на ключовата дума LOCALDATE и е седмият позиционен параметър в полето PARMS на запис в DCS директорията.

За да бъде валидна маската на датите, ВСИЧКИ следващи изисквания трябва да бъдат изпълнени:

  1. Може да има най-много една последователност от Y, M и D, където Y е цифра на годината, M е цифра на месеца, а D - цифра на деня.
  2. Максималният брой на Y подред е 4.
  3. Максималният брой на M подред е 2.
  4. Максималният брой на D подред е 2.

Например, следните са валидни маски на дати:

   
"YYyyMmDd" - Y, M и D не са
чувствителни към големи/малки букви.
"MM+DD+YYYY" - може да има маска,
по-дълга от 10 байта и да има символи,
различни от Y, M и D в маската
"abcYY+MM"   - може да няма последователност от D

Следните са невалидни маски на дати:

   
"YYYYyMMDD"  - невалидна,
защото има 5 Y.
"YYYYMDDM"   - невалидна,
защото има две M.

Ако форматът на маската на датите е невалидна, няма да бъде отчетена грешка. Тя ще бъде игнорирана. Само защото маска на датите е валидна, това не значи, че ще бъде използвана. Ще бъде извършена трансформация на данните, базирана на валидна маска на данните, само ако са изпълнени ВСИЧКИ следващи условия:

  1. Няма SQL грешка.
  2. Стойността е дата във формат, подобен на ISO (ISO и JIS).
  3. Размерът на изходните данни е поне 10 байта. Това е минималният размер на изходните данни, за да се запише стойността, даже и да не бъде извършена трансформация на формата на датата. Това изискване се отнася даже, ако маската на формата на датите е по-къса от 10 байта.
  4. Има валидна маска за формата на датите, указана в запис на DCS директорията, и тази маска се вмества в областта на изходните данни.

,,,,,,,CHGPWD_SDN=<име>
Този параметър е осмият позиционен параметър и се използва за определяне на име на символно предназначение, което да се използва при управлението на изтичане на срока на паролите (PEM - Password Expiration Management). От значение е използването на главни и малки букви при определяне на <име>.

Променяне на MVS парола показва пример за каталогизиране на dcs директория на база данни с помощта на CHGPWD_SDN, както следва:

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

,,,,,,,,BIDI=<ccsid>
Този параметър е деветият позиционен параметър и се използва за определяне на двупосочен (BiDi -Bidirectional) CCSID, който да се използва за заменяне на стандартния за сървъра на базата данни BiDi CCSID. Например:
    ",,,,,,,,BIDI=xyz" 

където xyz представлява заменянето на CCSID (вижте (BIDI_NOTE1)).

Списък с поддържаните BiDi CCSID заедно с техните типове низове ще намерите в Ръководство за администриране.

Изискват се следните BiDi атрибути за правилното управление на двупосочни данни на различни платформи:

Тъй като подразбиращите се стойности не са едни и същи на различните платформи, възникват проблеми, когато DB2 данни се изпращат от една платформа на друга. Например, Windows платформите използват данни LOGICAL UNSHAPED, докато данните на MVS и OS/390 обикновено са във формат SHAPED VISUAL. Следователно без никаква поддръжка за BiDi атрибути ще се представят неправилно данните, изпратени от DB2 за MVS или OS/390 на DB2 Connect за Windows.

Когато се обменят данни между DB2 Connect и база данни на сървър, обикновено получателят изпълнява конвертирането на входящите данни. Същото правило обикновено се прилага и при трансформация на BiDi форматиране, което е допълнително спрямо обикновеното конвертиране на кодова страница. Въпреки това засега няма DB2 продукти за хост, който да поддържа трансформации на специфични двупосочни CCSID или двупосочен формат. Следователно DB2 Connect е усъвършенстван с допълнителна възможност за изпълнение на трансформации на двупосочен формат върху данни, които ще се изпратят на сървър на база данни в допълнение към данните, получени от сървъра на базата данни.

За да може DB2 Connect да изпълни трансформация на двупосочен формат върху изходящи данни към сървър на база данни, BiDi CCSID на сървъра на базата данни ще трябва да се замени (вижте (BIDI_NOTE2)). Това се осъществява чрез използването на параметъра BIDI в полето PARMS на запис в DCS директорията за сървъра на базата данни.

Използването на тази възможност може да се илюстрира най-добре с пример.

Да разгледаме DB2 клиент с език иврит, който използва CCSID 62213 (BiDi низ тип 5) и би искал да осъществи достъп до DB2 хост база данни, която използва CCSID 424 (BiDi низ тип 4). Обаче знаете, че данните в DB2 хост базата данни са базирани на CCSID 8616 (BiDi низ тип 6).

В тази ситуация има два проблема. Първият е, че DB2 хост базата данни не знае разликата между типовете BiDi низове със CCSIDs 424 и 8616. Вторият проблем е, че DB2 хост базата данни не разпознава CCSID с номер 62213 на DB2 клиента. Поддържа само CCSID 862, който е базиран на същата кодова таблица, като CCSID 62213.

Най-напред ще трябва да се уверите, че данните, изпратени към DB2 хост базата данни, са във формат с BiDi низ тип 6 и освен това да уведомите DB2 Connect, че ще трябва да изпълни трансформация на BiDi формат върху данните, които получи от DB2 хост базата данни. Ще използвате следното каталогизиране за DB2 хост базата данни:

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

Така съобщавате на DB2 Connect да промени CCSID на DB2 хост базата данни от 424 на 8616. Тази замяна включва следните обработки:

  1. DB2 Connect ще се свърже към DB2 хост базата данни с помощта на CCSID 862.
  2. DB2 Connect ще изпълни трансформация на двупосочно форматиране върху данните, които ще изпрати към DB2 хост базата данни от CCSID 62213 (BiDi низ тип 5) на CCSID 62221 (BiDi низ типe 6).
  3. DB2 Connect ще изпълни трансформация на двупосочно форматиране на данните, които получи от DB2 хост базата данни от CCSID 8616 (BiDi низ тип 6) на CCSID 62213 (BiDi низ тип 5).

Забележки:

  1. Променливата на обкръжението или регистърната стойност DB2BIDI трябва да се установи на YES, за да влезе в сила параметърът BiDi.

  2. Ако искате DB2 Connect да изпълни трансформация на форматирането на данните, които ще изпрати към DB2 хост база данни, дори ако не е необходимо да се заменя нейния CCSID, отново ще трябва да добавите параметър BIDI към полето PARMS на DCS директорията. В този случай CCSID, който трябва да осигурите, ще е еднакъв със CCSID по подразбиране на DB2 хост базата данни.

  3. В някои случаи в резултат от използването на двупосочен CCSID самото SQL запитване може да се промени така, че да не се разпознае от DB2 сървъра. Особено трябва да избягвате използването на CCSID от тип IMPLICIT CONTEXTUAL и IMPLICIT RIGHT-TO-LEFT, когато може да се използва различен тип низ. Използването на CCSID от тип CONTEXTUAL може да доведе до непредсказуеми резултати, ако SQL запитването съдържа низове в кавички. Избягвайте използването на низове в кавички в SQL изрази и когато е възможно вместо тях използвайте хост променливи.

    Ако определен двупосочен CCSID причинява проблеми, които не могат да се отстранят, като изпълните следващите препоръки, тогава трябва да установите променливата от обкръжението или регистърната стойност на NO.

Определяне на параметричния низ

Ето примери за някои параметрични низове, които можете да определите.

Например можете да определите някой от следните, като символът "\" (наклонена черта) е специален символ escape на операционната система:

На AIX:

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

За OS/2, Windows NT или Windows 2000.

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

В противен случай можете да приемете стойностите по подразбиране, като не определите параметричния низ.
Забележка:Поради необходимостта да въведете две двойки двойни кавички, когато определяте маската LOCALDATE в параметричния низ, трябва да използвате символа escape на операционната система, който е "\" (наклонена черта), например:
    db2 catalog dcs db x as y parms \",,,,,,LOCALDATE=\"\"YYMMDD\"\"\"
В резултат се получава следния запис в DCS директорията:
    DCS 1 запис:
 
    Име на локална база данни          = X
    Име на базата данни приемник       = Y
    Име на рикуестъра за приложения    =
    DCS параметри                      = ,,,,,,LOCALDATE="YYMMDD"
    Коментар                           =
    Версия на DCS директорията         = 0x0100

Системна директория на база данни

Можете да определите следната информация в системната директория на базата данни:

Име на базата данни
Същата стойност, която сте записали в таблицата с параметрите на DCS директорията.

Псевдоним на базата данни
Псевдоним за хоста или AS/400 сървъра на базата данни. Това име ще се използва от приложните програми при достъп до базата данни. По подразбиране се използва стойността, която определите за име на базата данни.

Формат: 1-8 еднобайтови буквено-цифрови символи, включително числен знак (#), знака at (@), знака за долар ($), и долно тире (_). Не може да започва с долно тире или число.

Име на възел
Същата стойност, която сте записали в таблицата с параметрите на директорията на възлите.

Разпознаване
Определя къде ще се провери валидността на името и паролата на потребителя. Валидни опции са: SERVER, SERVER_ENCRYPT, CLIENT, DCE, DCS и DCS_ENCRYPT. За допълнителна информация вижте Защита.

Задаване на множество записи

За всяка база данни трябва да определите поне един запис във всяка от трите директории (директория на възлите, DCS директория, системна директория). Понякога може да е необходимо да дефинирате повече от един запис за базата данни.

Например може да предпочитате да изключите преобразуването на SQLCODE за приложенията, които се прехвърлят от хоста или AS/400 сървъра на базата данни, но да приемете преобразуването по подразбиране, което е разработено за обкръжението клиент/сървър. Можете да направите това, както следва:

И двата псевдонима осъществяват достъп до една и съща база данни, като при единия има преобразуване на SQLCODE, а при другия няма.


[ Начало на страницата | Предишна страница | Следваща страница ]