During IPL brought down the DCDCONTL started task (STC) but after the IPL not able to bring the task up.
2021-11-27 21:03:52,311 Exception while canceling in progress scans. Cause:
com.ca.security.dcd.exceptions.DatabaseException: Error canceling controller's active scans during shutdown.
Exception Context:
[1:ERRORCODE=DCD0362E]
[2:ERROR=error_in_cancelActiveScansDuringShutdown]
[3:STATUSCODE=]
[4:TRANSLATIONKEY=error_in_cancelActiveScansDuringShutdown]
[5:Controller=DCDCONTL]
[6:Resolution=Contact CA Support.]
---------------------------------
at com.ca.security.dcd.service.ScanServiceImpl.cancelActiveScansDuringShutdown(ScanServiceImpl.java:1421) ~[Database-Module-3.0-SNA
PSHOT.jar:na]
Release : 3.0
Component : DATA CONTENT DISCOVERY
DCDCONTL job log showed root cause of the problem was failure to connect to DB2 via JDBC i.e.
===
...
2021-11-27 21:03:52,311 Exception while canceling in progress scans. Cause:
com.ca.security.dcd.exceptions.DatabaseException: Error canceling controller's active scans during shutdown.
...
Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.ibm.db2
jcc.am.DisconnectNonTransientConnectionException: [jcc][t4][2043][11550][4.23.50] Exception java.net.ConnectException: Error openin
g socket to server nnnnnnnn/xxx.xxx.xxx.xxx on port 446 with message: EDC8128I Connection refused. (Connection refused). ERRORCODE=-4499,
SQLSTATE=08001
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) ~[spring-jdbc-4.2.3.RELEASE.jar:4.2.3
RELEASE]
...
===
The DCD techdocs message page advises for an EDC8128I connection error as follow:
===
Db2 Database JDBC Connection error with message: <message>
Reason:
The Data Content Discovery Controller was unable to connect to the Db2 Database because of the given <message>.
Action:
If you receive an EDC8128I Connection refused message perform the following:
1. Verify that the correct host and port are used for the Db2 connection. They are specified in uss_runtime_path/config/dao.properties in the jdbc.db2.dbUrl=.
2. If you made changes to the values in dao.properties, you must make the changes in runtime_hlq.CFEYCFG(FEYCFG) for DB2_HOST= and DB2_PORT= so your changes remain after maintenance is applied.
===
Additional information which may help:
a. If the JDBC parameters for host/IP Address & port are correct and the DB2 connection was working before could there be some temporary problem with the connection or perhaps some firewall problem?
b. The DB2 JDBC connection URL in file uss_runtime_path/config/dao.properties is formatted as follows: jdbc.db2.dbUrl=jdbc:db2://host_name:port/DB2_subsystem
You can locate these components in the DB2 master address space, searching for "LOCATION". This has several parameters some of which can be substituted in the JDBC URL:
jdbc.db2.dbUrl=jdbc:db2://DOMAIN:TCPPORT/LOCATION
c. The DB2 subsystem needs to support JDBC connections over TCP/IP.
d. There might be some messages in the DB2 DIST address space regarding the JDBC logon id, DCDADM by default, that can help the DBA to troubleshoot.
e. Another setup issue seen is when the LOCATION and TCPPORT specify DB2 data sharing. In these cases the URL was changed to point to one specific subsystem.
*** For this particular scenario the DCDCONTL STC was started successfully after using the correct user ID to do so (an incorrect user ID was used initially).