We have setup a new physical server, with a number of virtual servers on
top of it. When we run db2start on any of the virtual servers we get:

~]$ db2start
SQL5043N Support for one or more communications protocols failed to
start successfully. However, core database manager functionality started
successfully.

]$ echo $?
6

Everything seems to be working fine, and it is possible to do both local
and remote connections to databases. Both db2tcpcm and db2ipccm appears
to be running:

~]$ db2pd -edus | grep cm
15 47018219137344 16577 db2tcpcm
0.000000 0.000000
14 47018223331648 16576 db2ipccm
0.000000 0.000000

The only protocol specified is tcpip:

# db2set | grep DB2COMM
DB2COMM=tcpip

and /etc/services seems ok:

~]$ grep db2 /etc/services
db2c_db2inst1 50000/tcp # DB2 related


Any ideas what might cause the error message?

/Lennart

On Nov 29, 6:28*am, Lennart Jonsson <erik.lennart.jons... (AT) gmail (DOT) com>
wrote:
What messages do you get in db2diag.log ?

On 2010-11-29 18:20, Ian wrote:
[...]
Hi Ian, see my response to globomike in this thread


/Lennart

On Nov 29, 11:57*am, Lennart Jonsson <erik.lennart.jons... (AT) gmail (DOT) com>
wrote:
OK. I have seen an error in the past where there's SPM log
corruption, but I don't remember what the db2diag.log entries look
like. Is the SPM_NAME dbm cfg parameter set for your instance? This
enables the SPM protocol.

IFF this is the case, then the solution is basically to ensure that
there aren't any indoubt transactions (using LIST DRDA INDOUBT
TRANSACTIONS), and if there aren't, then shut down the instance,
remove the SPM log files (see SPM_LOG_PATH dbm cfg for location) and
restart the instance. DB2 will automatically generate new SPM log
files. This procedure is described (kind of) for the error SPM0439N
in the documentation.


Ian

On 2010-11-30 00:10, Ian wrote:
Found one:

2010-11-30-05.40.35.168591+060 I14212428E364 LEVEL: Severe
PID : 3058 TID : 47146329958720PROC : db2sysc
INSTANCE: db2inst1 NODE : 000
APPHDL : 0-6
EDUID : 17 EDUNAME: db2spmrsy
FUNCTION: DB2 UDB, syncpoint manager, sqlcspm_readlog, probe:10
MESSAGE : SPM0438 The Sync point manager recovery log is bad.

It is indeed set (but as far as I can tell to a dummy value). It is set
on all instances in this environment that I have looked at. I tried to
read up om SPM but I couldn't find much ( I haven't heard of it before :-).

I'm pretty sure we can remove the setting ( guess someone used it to
something at some point in history ), since we don't use any
functionality provided by it.

I guess the files won't have to deleted if the cfg is changed, but it's
probably a good idea anyhow.

Thanks for your suggestions, much appreciated


/Lennart

On 2010-11-30 06:58, Lennart Jonsson wrote:
[...]
Hmm, not sure how to turn off SPM. Any idea? I checked another instance
and there it is empty:

SPM name (SPM_NAME) =

according to the docs it is defaulted to the hostname.


Anyhow, stopping the instance and removing SPMLOG.LCF and the files in
SPMLOGSD solved the problem.

/Lennart