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
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.
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?
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.