Unable to start a new REST/JCP

Products

• CA Automic Workload Automation - Automation Engine

Issue/Introduction

After installing AE for the first time, the system is unable to start a new JCP or REST process. This is not the first JCP or REST process that is failing to start but either secondary JCP on the same node or a REST process on a secondary node. The following error message is shown in log.

U00045014 Exception 'java.lang.NullPointerException: "Cannot invoke "java.lang.CharSequence.toString()" because "replacement" is null"' at 'java.lang.String.replace():2963'.

Cause

In the automic DB we deliver MQCP tables from 1 till 6 with the install
Any additional CP process that is started, will create its tables automatically.
When CP7 is started, its table MQCP007 does not exist, so the process tries to create it.
The process tries to get the location of the data and the index tablespaces, so the table data is created in the data tablespace and the index in the index tablespace.

The information for the data comes back when setting traces with tcp/ip=2, db=4 on the process

The information for the data comes back:
select TABLESPACE_NAME DIVDB_String from USER_TABLES where TABLE_NAME = 'OH'
20250812/205016.702 - 1      UCUDB32 SCLO RET 0000 HSTMT: 0000000000001878 VALUE: 0000000000000000 ALL:  0.00100 DB:  0.00000 ODBC:  0.00000 UDB:  0.00000
20250812/205016.702 - 1      UCUDB32 READ RET 0000 HSTMT: 0000000000001878 VALUE: 0000000000000001 ALL:  0.00000 DB:  0.00000 ODBC:  0.00000 UDB:  0.00000
20250812/205016.702 - 1      U00009909 TRACE:(DB-DATEN: DIVDB_STRING) size 000008
20250812/205016.702 - 1                00000000  5543345F 44415441                    >UC4_DATA<

and points to UC4_DATA.

When the same query is done, it comes back as empty:
20250812/205016.704 - 1      select TABLESPACE_NAME DIVDB_String from USER_INDEXES where INDEX_NAME = 'PK_OH'
20250812/205016.704 - 1      UCUDB32 SCLO RET 0000 HSTMT: 0000000000001878 VALUE: 0000000000000000 ALL:  0.00000 DB:  0.00000 ODBC:  0.00000 UDB:  0.00000
20250812/205016.704 - 1      UCUDB32 READ RET 0001 HSTMT: 0000000000001878 VALUE: 0000000000000000
20250812/205016.704 - 1      UCUDB32 CLST RET 0000 HSTMT: 0000000000001878 VALUE: 0000000000000000

Since PK_OH is the primary key of the OH table, this has to exist.

Resolution

Check with the DBA why is this query returning 0 rows