Release : 8.6
Component : CA Gen Enterprise Java Beans
This problem does not appear to be related to Gen generated Java code nor the Gen Java runtimes.
1. For block-mode COBOL generated applications where TD DB2 z/OS has "DBMS Access Method=Embedded SQL", there is nothing in the generated embedded SQL code to handle the Fieldproc "REVNUM" and it should all be handled in the DB2 DB which runs that field procedure and then returns the result to the application. Similarly for Java generation where TD DB2 z/OS has "DBMS Access Method=ODBC/ADO.NET/JDBC", the same would be true and the DB2 DB should return the correct result to the application via the DB2 JDBC driver.
2. From the error message jcc 4.19.77 is the version of DB2 for z/OS JDBC 4.0 Driver for DB2 for z/OS v11:
https://www.ibm.com/support/pages/db2-jdbc-driver-versions-and-downloads-db2-zos
When searching the web there are some hits on DB2 JDBC driver/jcc for similar "Illegal conversion" exceptions with SQLCODE 4474 involving some DB2 APARs but the symptoms are not an exact match to using a field procedure e.g. this one: https://www.ibm.com/support/pages/node/3419901
For the above, an incorrect SQLTYPE is being returned to the DB2 JDBC driver by the DB causing the application error.
In this scenario, the character column is defined as a string in the Java code and it appears that an incorrect SQLTYPE may be getting returned causing the attempted conversion to byte.
Referred to IBM Support - details of a final resolution to follow.
LATER UPDATE FROM USER:
Deployed the same application onto JBOSS EAP using the same JDBC drivers.
When tested from SOAP UI, able to retrieve all the data correctly.
After looking more into the WebSphere Application Server DB2 logs, the main driving READ EACH is on a Table-1 which has a Fieldproc column and a second READ, on another Table-2 which also has a Fieldproc column and also has a relationship with the Table-1 using the Table-1's Fieldproc Column. This flow fetched the results correctly for the 1st row in the Table-1's READ EACH. However when the program is processing the 2nd row from the result set, the READ on Table-2 is failing.
Therefore this appears to be a WebSphere Application Server specific issue.