DB2 FOR LUW / DB2FORLUW / A50 - DB2

Background of the problem ; 
- db2ckupgrade API does sqlestar() and then sqleatin() , 
sqleatin() fails  if virtual host names are used  AND sqleatin() 
is called after sqlestar()  from the same ckupgrade app. 
The actual problem is in oss code sqloGetDftNodeNum() that 
compares a tcpip resolved host name to db2nodes.cfg node lines 
which is not a good comparison if virtual hostnames are used. It 
will fail to understand these 2 hosts are actually same hosts. 
There is a ssh/rsh solution executing this at remote node when 
db2rstar  is used to do ssh/rsh  in this host and figure out 
what it resolves and save it to a file. Then compare these 
values to match the host later instead of trying to do strcmp in 
db2nodes.cfg with tcpip resolve names. 
 
 
API -> blah() -->  sqlestar() -> sqleatin() -> blah... 
 
Closer look : 
                          sqlestar() - > INITAPPENV- > CACHE 
NODE UNKNOWN -> (noDEfaultNodeKnown - IT IS NORMAL - db2start is 
not DONE yet)  [ see detail#2 ] -> sqleatin() -> VOID 
(INITAPPENV : it is already done DOES NOT DO refersh node info) 
-> getDefaultnodeToAttachDBMS ->  CACHED NODE IS STILL UNKNOWN - 
SQLEATIN -> FAILS on attaching DBMS. 
 
 
[detail #2] db2start creates a .dft file that has indeed default 
node number created in .dft file from port 0 detection. Now if 
you call another api indeed it would know the only reason above 
failure in sqleatin()  never do multiple INITAPPENV from same 
app that might be calling 2 different db2 API in the same exe. 
and the point we bail out second time INITAPPENV we WONT refresh 
the nodes info from .dft file. If we were calling now  a second 
time another API that has sqleatin() it would SUCCEED. 
 
 
SUCCESS CASE 
exe1 - sqlestar  OR outright db2start 
exe2 - sqleatin 
 
exe1 + exe2 would work  (sqleatin would refresh in initAPPENV) 
 
 
FAIL CASE 
exe3 - sqlestar + sqleatin  (sqleatin  would NOT refresh in 
initAPPENV ) if it were virtual ip it would fail... 
exe3 would fail 
 
 
The fix : 
inside sqlestart() after startup completes ok , but if node is 
still unknown in the cache of INITAPPENV then refresh this cache 
again. Limited and ugly workaround.

**************************************************************** 
* USERS AFFECTED:                                              * 
* DPF instance                                                 * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to version 10.5 fixpack 3.                           * 
****************************************************************

change the entries in db2nodes.cfg from virtual ip to hostname

DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
 DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows
 

Fixed in version 10.5 fixpack 3. db2iupgrade succeeds with 
upgrading from v10.1 to v10.5

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

07.03.2014
08.09.2014
08.09.2014