I'm currently developing a JAVA (1.7) server application running on an JBoss 7. Using Spring and Hibernate this would be nothing unusual, but I have to connect an old AS/400 DB to the system. So far I've adjusted the drivers for the application server and the database connection has been established. The application server has logged that the database has beend found.
Now I've tried to access the data using JPA and Hibernate. But there seems to be a problem with my libraries. He is what the server is logging.
English:
For this file no library has been found in the SQL/ODBC files. The file was not found in the *CURLIB, *LIBL or the default library of the data base source. There is no OVRDBF or a OVRDBF has not been set. [...] PCSACC/400
German original:
Für diese Datei wurde keine Bibliothek in den SQL/ODBC-Daten ermittelt. Die Datei wurde nicht in der *CURLIB, *LIBL oder in der Default-Bibliothek der Datenquelle gefunden. Es besteht kein OVRDBF oder in einem OVRDBF wurde keine Bibliothek angegeben. [..] PCSACC/400
Is my assumption right and I have to add an additional library to my EAR in order to run the queries? Another scenario would be, that the AS/400 has to be accessed in a different way - perhaps the application has connected to the db but not to the instance I need to access.
One additional question - can I simulate this type of db?
The data source onfiguration of the JBoss 'urn:jboss:domain:datasources:1.0' subsystem:
<xa-datasource jta="true" jndi-name="java:/asdb" pool-name="asdb" enabled="true" use-java-context="true" use-ccm="true">
<xa-datasource-property name="ServerName">192.168.1.666</xa-datasource-property>
<xa-datasource-property name="databaseName">A1B2C3D4</xa-datasource-property>
<xa-datasource-property name="Libraries">DMS7_0</xa-datasource-property>
<xa-datasource-property name="User">myuser</xa-datasource-property>
<xa-datasource-property name="Password">myuser</xa-datasource-property>
<xa-datasource-property name="naming">system</xa-datasource-property>
<xa-datasource-property name="translateBinary">true</xa-datasource-property>
<xa-datasource-property name="errors">full</xa-datasource-property>
<driver>com.ibm.as400</driver>
</xa-datasource>
And the possible drivers:
<drivers>
<driver name="net.sourceforge.jtds" module="net.sourceforge.jtds">
<driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>
<xa-datasource-class>net.sourceforge.jtds.jdbcx.JtdsDataSource</xa-datasource-class>
</driver>
<driver name="com.ibm.db2" module="com.ibm.db2">
<driver-class>com.ibm.db2.jcc.DB2Driver</driver-class>
<xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
</driver>
<driver name="com.ibm.as400" module="com.ibm.as400">
<driver-class>com.ibm.as400.access.AS400JDBCDriver</driver-class>
<xa-datasource-class>com.ibm.as400.access.AS400JDBCXADataSource</xa-datasource-class>
</driver>
</drivers>
The Hibernate versions:
The JBoss-Web-Configuration for the data source
<resource-ref>
<res-ref-name>jdbc/ASdb</res-ref-name>
<jndi-name>java:/asdb</jndi-name>
</resource-ref>
It's unlikely that you're connecting to AS/400; those machines are decades old. However, your colleagues may still refer to it as this. The current OS is called IBM i, and this is important for internet searches to return modern results.
DB2 for i has two naming styles: SYSTEM and SQL. It looks like this connexion is using SYSTEM naming. Perhaps there's a way to change it to SQL naming so that the connexion uses the library/schema needed.
There is only one instance of DB2 on a given copy of IBM i.
What I do is to set the library list (SYSTEM naming) by way of the job description that the user profile is set up to use. So connecting with user QA runs with the QA libraries, and the exact same client connecting with user PRODUCTION runs with the production libraries. This is handled by the IBM i sysadmin.
You can almost simulate this DB if you load up DB2 LUW. There are many similarities between DB2 for i and LUW. But they are not identical! On IBM i, I can write stored procedures, functions, and triggers in a HLL. LUW only allows them to be written in SQL. So 'moving' a copy from IBM i to Linux might be a lot of work. And then there are the syntactical differences between them. If the IBM i version is quite current (7.3 in Jan 2017) then you have a better chance of success.