Infrequent errors on executing query statements.

Context: Java Web Application running on Tomcat that schedules some DAILY operations over SQL Gateway, currently using CONNX 4.6 JDBC Driver connected to Mainframe.

For some awkward unknown reason, one or two times a week (nor even same weekdays), the Java routine throws an exception. I really don’t know where to find the solution for these errors. Sometimes the query statement that wasn’t executed last day, runs flawlessly on the next day, without any changes :shock: .

Does anyone experienced anything like this? I really need help.

Trace of last error (SQL gateway response looks truncated):


org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback; uncategorized SQLException for SQL [SELECT COUNT(*) AS count_return FROM XXX  WHERE AAA = ? AND BBB = ? AND CCC = ? AND DDD = ? AND EEE = 'ATIVO']; SQL state [HY000]; error code [146]; Unable to get record from table (XXX).
>>> Error Executing Query:  Adabas nucleus response code = (146); ADD2 = (00000002) SubCode = (02) SubField = (
; nested exception is java.sql.SQLException: Unable to get record from table (XXX).
>>> Error Executing Query:  Adabas nucleus response code = (146); ADD2 = (00000002) SubCode = (02) SubField = (
Caused by: java.sql.SQLException: Unable to get record from table (XXX).
>>> Error Executing Query:  Adabas nucleus response code = (146); ADD2 = (00000002) SubCode = (02) SubField = (
	at com.Connx.jdbc.TCConnxDistributedObjects.TCCdo.unpackError(TCCdo.java:166)
	at com.Connx.jdbc.TCConnxDistributedObjects.TCConnxStatementCmd.unpackBag(TCConnxStatementCmd.java:123)
	at com.Connx.jdbc.TCService.TCServiceMgr.processService(TCServiceMgr.java:38)
	at com.Connx.jdbc.TCConnxDistributedObjects.TCConnxStatementCmd.<init>(TCConnxStatementCmd.java:88)
	at com.Connx.jdbc.TCJdbc.TCJdbcStatement.statementCmd(TCJdbcStatement.java:770)
	at com.Connx.jdbc.TCJdbc.TCJdbcPreparedStatement.executeQuery(TCJdbcPreparedStatement.java:77)
	at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:82)
	at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:82)
	at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:688)
	at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:629)
	... 80 more

I would recommend contacting support. i believe there is an update available for this issue.

1 Like

Response 146 is Invalid buffer length, with subcode 2 pointing to the record buffer. I am guessing your CDD file is not in agreement with the actual FDT. You may want to rebuild your CDD file with the updated DDM and see if the errors go away. You may also want to check to see if your DDM agrees with the FDT also.

1 Like

Thank you Larry and Brian.

Brian, I really appreciated your technical comment.
I’m going to discuss it with the DBAs and I think that it points to an answer.
Another error (by the way, this one happened TODAY) that sometimes occurs:


PreparedStatementCallback; uncategorized SQLException for SQL [INSERT INTO XXX (AAA,BBB,CCC,DDD,EEE,FFF,GGG,HHH,III,JJJ,KKK,LLL,MMM,NNN) Values (?,?,?,?,?,?,?,'ATIVO',?,?,?,?,?,?)]; SQL state [HY000]; error code [52]; Unable to Put table record. >>> Error Inserting Record: Adabas nucleus response code = (052); ADD2 = (C1C20001) SubCode = (01) SubField = (AB) ; nested exception is java.sql.SQLException: Unable to Put table record. >>> Error Inserting Record: Adabas nucleus response code = (052); ADD2 = (C1C20001) SubCode = (01) SubField = (AB)

What about this one? Is there any source documentation where I could look for these codes?

It is possible that the CDD and FDT do not agree. However the intermittent nature of the issue could be a reported (and resolved) program issue.

The error codes are Adabas response codes which can be found in the adabas documentation online via empower.

I would recommend you contact support, as these types of errors can be better handled there rather than in a tech forum.

Response 52 subcode 01 means “Invalid packed or unpacked decimal value in record buffer.” It also tells you the field in error is field AB, which should help direct you in the comparison of the FDT vs DDM vs CDD comparison.

That’s not a good thing… assuming the field AB is a packed numeric field. I concur with Larry at this point that this should be escalated to support.