KCIIN0363E and KCIIN2205E during new configuration of TEPS

Diagnosing The Problem

1. Check /opt/IBM/ITM/logs/kfwdb2prep_db2inst1.log

or
/opt/IBM/ITM/logs/db2prep.log /tmp/.itmnnnnnnnnnnnn.tmp

KFWDB2PREP Starting on ...
Command issued:
db2 ATTACH TO db2inst1 USER db2inst1 USING [PASSWORD] 2>&1
Failed to attach to the db2 instance

Please check the followings:
Check the existence of the db2inst1 instance.
Check the instance is started and running.
Check the Admin User db2inst1 is defined.
Check the Admin User password is correct.

• Based on fact that invoking the command in standalone mode, the cause may be a permissions issue.
  Try changing the permissions (chmod 777) of the $candlehome/logs/kfwdb2* files.  Test and check results.

2. Troubleshooting by modifying the $CANDLEHOME/bin/kfwdb2prep.shscript
     Within the script comment out the lines that remove the generated temp files.

Comment out these lines:
rm -rf $tmpFile1                                                  
rm -rf $tmpFile2                                                  
rm -rf $tmpFile3       
Save the kfwdb2prep.shscript and launch the TEPS configuration again. Step through the configuration as usual.                                           

If the configuration fails gather the following:

> PDCOLLECT gathered using the command 'tacmd pdcollect -o nohist'
> $CANDLEHOME/bin/kfwdb2prep.sh                                   
> The configuration will also generate files in the /tmp directory. The files will appear as                                              /tmp/<PID>-1.tmp                                              
/tmp/<PID>-2.tmp                                                
/tmp/<PID>-3.tmp                                                                                                                  

Where <PID> is the PID associated with the configuration.
Obtain the file(s) from the /tmp directory.

NOTE: The /tmp directory may not contain all 3 files, the existence of all 3 files depends on where the kfwdb2prep.sh script failed.          

It's possible, the password used to attach to the DB2 instance contains special characters which cause a problem for the kfwdb2prep.sh.

3. In reported case(s), it does appear that the correct and same password entered in the command natively matches what's in the /tmp file:

ATTACH TO db2inst1 USER db2inst1 USING ‘db2inst1'

This is unexpected if it works via the command and not via the shell and if the permissions were granted as described earlier.  Therefore, try the following:

Modify the shell script as follows:

Change  (line 41 in reported case) from:

print "ATTACH TO ${KFW_DB2INST_ID} USER ${KFW_DB2ADMIN_ID} USING '${KFW_DB2ADMIN_PW}'" > $tmpFile1

to

print "ATTACH TO ${KFW_DB2INST_ID} USER ${KFW_DB2ADMIN_ID} USING 'db2inst1'" > $tmpFile

We are basically hardcoding the password within the attach command above, inside the shell script instead of pulling it from variable defined as
KFW_DB2ADMIN_PW=$(grep adminPW $7|cut -f2 -d"=")

IF this gets passed the stage where the ATTACH is successful, then I expect the next logical step to CONNECT to it will fail (line 83 in the script).  IF this is the case, we can then hardcode the value there too.