SQL6031N Error in the db2nodes.cfg file at line number "1". Reason code "10".
DB2 caches your machine’s hostname in several places. If your machine is changing its hostname, or if you are somehow moving an existing installation to a machine with a different hostname, you will need to adjust the hostname stored by DB2. Hostname change is common in virtual and cloud environments, so even better than adjusting it would be writing a script that adjusts it for you.
Here’s my rudimentary stab at a such a script:
#!/bin/sh echo -n "Discovering the new hostname " UNAME_CACHE=$(uname -n) echo -n "Adjusting hostname list for unconfigured database partitioning feature " # this may need to be changed if DPF preconfigured if [ -e /home/db2inst1/sqllib/db2nodes.cfg ]; then chmod 666 /home/db2inst1/sqllib/db2nodes.cfg su - db2inst1 -c "cp /home/db2inst1/sqllib/db2nodes.cfg /home/db2inst1/sqllib/db2nodes.cfg.old" su - db2inst1 -c "echo 0 $UNAME_CACHE 0 > /home/db2inst1/sqllib/db2nodes.cfg" fi echo -n "Making registry writable " chmod 666 /var/db2/* echo -n "Adjusting the DB2 hostname " UNAME_CACHE=$(uname -n) /opt/ibm/db2/V9.7/adm/db2set -g db2system=$UNAME_CACHE echo -n "Updating DAS configuration " # todo # db2 uncatalog node db2 catalog admin tcpip node $UNAME_CACHE remote $UNAME_CACHE system $UNAME_CACHE db2 update admin cfg using DB2SYSTEM $UNAME_CACHE db2 update admin cfg using SMTP_SERVER $UNAME_CACHE
This doesn’t cover all cases. For example, if you use extended operating system security, you may also need to set the db2accountname and db2instowner parameters. A quick check with db2set -all should tell you if this applies in your case — if there is something that looks like a hostname in those parameters already, you need to change them.
I may also have missed other necessary changes. Please let me know if I did.:-)