Forced traces U00003516 UCUDB: ... function 'DELETE' = '0'
search cancel

Forced traces U00003516 UCUDB: ... function 'DELETE' = '0'


Article ID: 258906


Updated On:


CA Automic Workload Automation - Automation Engine CA Automic One Automation


After zero downtime upgrade from 12.3.2 to 12.3.9 HF2, there are forced traces once or twice a day.  The logs show this:

20221216/010304.248 - U00015006 System forced memory trace dump.
20221216/010304.249 - U00015006 System forced memory trace dump.
20221216/010304.250 - U00003631 Dump caused by:
20221216/010304.250 - U00003516 UCUDB: Affected lines in function 'DELETE' = '0'
20221216/010304.250 - U00011801 Error in Server routine 'JPEXEC_R', Server: 'PROD#WP020' AE system: 'PROD'.

Is there any impact to this?


Release : 12.3.9 HF2


Turn on a database=4, tcp/ip=2 and looking at the WP traces: 

The hangup is coming on this statement that WP4 tried to run:

20221220/211707.084 - U00009909 TRACE: (BINDPAR:  EH_AH_Idnr         0x7f99fe415c9c 00004
                                00000000  F49A1B62                             >ôš.b<
20221220/211707.084 -                                         >1645976308<
20221220/211707.084 - U00009909 TRACE: (BINDPAR:  ROWID              0x7f99f9402bc0 00018
                                00000000  4141414A 5A704143 44414142 534F4A41  >AAAJZpACDAABSOJA<
                                00000010  414A                                 >AJ<
20221220/211707.084 -  DELETE FROM EH WHERE EH_AH_Idnr = ? AND ROWID=?
20221220/211707.085 -  UCUDB32 DLTE RET 3516 HSTMT: 0x00000002ace070 VALUE:            (nil) ALL:  0.00106 DB:  0.00090 ODBC:  0.00001 UDB:  0.00016

The RET 3516 corresponds as well with the U code for the error message:

20221220/211707.097 -  U00003516 UCUDB: Affected lines in function 'DELETE' = '0'

In this case, the customer chose not to further troubleshoot this for RCA or possible bug as 12.3 is out of maintenance and they'll be updating to 21.0 soon.

There should be no impact with this 'DELETE' = '0' forced trace except that the trace file is created.  For some reason the record is having a delete tried twice in the same transaction and the record doesn't exist.  There is no impact to logic or processing.