Wednesday, 12 December 2018

DB2 on Windows - What a difference a CR/LF makes ....

Context - configuring DB2 on Windows to support an IBM Security Key Lifecycle Manager (SKLM) installation ….

So I start my instance: -


12/12/2018 10:48:22     0   0   SQL5043N  Support for one or more communications
 protocols specified in the DB2COMM environment variable failed to start success
fully. However, core database manager functionality started successfully.
SQL1063N  DB2START processing was successful.

Check the DB2 environment: -



Check the DB2 Service Name: -

db2 get dbm config | find "SVCENAME"

 TCP/IP Service name                          (SVCENAME) = db2c_DB2
 SSL service name                         (SSL_SVCENAME) =

Checked the Windows TCP/IP services file: -

type c:\Windows\System32\drivers\etc\services | find "db2c_DB2"

db2c_DB2        50000/tcp

I then thought to check the DB2 diagnostics: -

db2diag -f

2018-12-12- I296931F497          LEVEL: Error
PID     : 2524                 TID : 2204           PROC : db2syscs.exe
INSTANCE: DB2                  NODE : 000
EDUID   : 2204                 EDUNAME: db2sysc 0
FUNCTION: DB2 UDB, common communication, sqlcctcpconnmgr, probe:5
MESSAGE : DIA3201E The service name "db2c_DB2" specified in the database
          manager configuration file cannot be found in the TCP/IP services

So I rechecked the TCP/IP services file, using Notepad: -

notepad.exe c:\Windows\System32\drivers\etc\services

and swiftly realised that, although I DID have the service listed: -

db2c_DB2        50000/tcp

there was NO Carriage Return / Line Feed ( CR/LF ) after the end of the line.

In other words, the terminator was after the p of tcp.

I added a CR/LF character and saved the file.

I then stopped the instance: -


12/12/2018 10:50:59     0   0   SQL1064N  DB2STOP processing was successful.
SQL1064N  DB2STOP processing was successful.

and started it again: -


12/12/2018 10:51:25     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

which looked good.

I then checked the listening ports: -

netstat -aon|find "LISTEN"

TCP              LISTENING       500
TCP              LISTENING       1244
TCP              LISTENING       492
TCP              LISTENING       1360
TCP              LISTENING       1308
TCP              LISTENING       3664
TCP               LISTENING       1360
TCP              LISTENING       1188


Oh frabjous day :-)

No comments:

TIL - read-only variables in Linux

 A co-worker was seeing an exception: -  line 8: TMOUT: readonly variable when trying to SCP a file from a remote Linux box. I did some digg...