I am developing a simple java program in CICS Explorer to connect to DB2 on mainframe.
Using the plug-in development option in CICS Explorer, I have converted the DB2 jars as plug-ins,deployed them and added the deployed plugins in the JVM profile OSGi Bundles option .I have also added the same in the LIBPATH option in JVMProfile and in the CICS Explorer target platform.
But on deploying the bundle in CICS , I am getting the error :
Error msg : No Suitable driver
SQLSTATE : 08001
Error code : 0
Kindly help me trace the issue
If you're having to convert the DB2 JARs into OSGi bundles it's likely that you've not got the requisite APARs applied. If you use the JARs that are provided with the following APARs:
PM36832
PM36838
then they are already OSGi bundles, plus, they also register the DB2 Driver automatically - avoiding the 'No Suitable driver' problem.
Related
I´m trying to deploy a war that connects to CISC into a Websphere Liberty Profile app server 8.5.5. It works perfectly in WAS, however there is a feature missing but I don´t know which.
java.lang.ClassNotFoundException: com.ibm.etools.marshall.util.ConversionUtils
at com.ibm.ws.classloading.internal.AppClassLoader.findClassCommonLibraryClassLoaders(AppClassLoader.java:504)
at com.ibm.ws.classloading.internal.AppClassLoader.findClass(AppClassLoader.java:276)
at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:941)
at java.lang.ClassLoader.loadClass(ClassLoader.java:876)
at com.ibm.ws.classloading.internal.AppClassLoader.findOrDelegateLoadClass(AppClassLoader.java:482)
at com.ibm.ws.classloading.internal.AppClassLoader.loadClass(AppClassLoader.java:443)
at java.lang.ClassLoader.loadClass(ClassLoader.java:846)
It looks like you are missing the "Record" class from the development tools (such as Rational Application Developer). In Liberty these classes are not bundled with the runtime and need to be imported. The instructions are here:
https://www.ibm.com/support/knowledgecenter/en/SS7K4U_liberty/com.ibm.websphere.wlp.zseries.doc/ae/twlp_dat_radrecdata.html
This includes the conversion utils that your stack trace is showing.
I have created a Service running on Tibco, containing a JDBC-enabled process within it, and tested it successfully. The database server is MySQL, and is hosted remotely. When connecting to the remote DB from the service hosted on my machine, the SQL is executed well, but after building the Tibco EAR file and deploying to another external machine, then trying to access the same remote DB server using the same credentials, the external machine returns the below error upon returning:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'OPTION SQL_SELECT_LIMIT=DEFAULT' at line 1
So, a few questions:
What could be the cause of the above error, given the DB being accessed is the exact same one, using same SQL query, but from different machines?
Is the JDBC driver used for development compiled as part of the packaged EAR file?
Does the JDBC driver being used in a Tibco Process depend on the Tibco service installed or on the packaged EAR file?
Am asking from a learner PoV as am currently picking up Tibco
It looks like jdbc driver issue. You may have different mysql driver version in tibco designer and BusinessWorks.
You don't need to add jdbc driver to your ear package.
Please note that you can specify mysql driver in your package classpath. In tibco Administrator PackageName->Configuration->ServerSettings->Prepend to ClassPath or Append to Class path.
You can also try to copy the driver from your tibco designer(in BW5 it's in \tibco\bw\5.11\lib\
) to the BusinessWorks classpath
This link explains the new things about WildFly. Under the Migrating The Database Connection -> JDBC Driver the article explains about two ways of using jdbc drivers for the applications. I tried with installing it as a module and it works fine. The problem is which way is better and when it is better, whether deploy it as any other application package or install it as a module?
(I noted that install it as a module is necessary for clustered environment. I am looking for, are there any other reasons?)
I think the correct link to the article you are referencing is this one : http://wildfly.org/news/2014/02/06/GlassFish-to-WildFly-migration/
(The other one does not seem to point to the article you are mentioning)
Below is the interesting part from "Migrating The Database Connection" section you are referencing:
On WildFly, you have two ways of installing the JDBC driver: whether
you deploy it as any other application package or you install it as a
module. You can always choose to deploy the driver, but it’s specially
recommend when you have a cluster environment, since the deployments
are automatically propagated in the server groups.
You may have issues with the deployment if the driver is not
JDBC4-compliant. In this case, installing the driver as a module
solves those issues. The advantage of the JDBC driver as a module is
the possibility of creating a custom WildFly bundle for your
organization. This way, you can repeat exactly the same installation
throughout several machines, preserving the same configuration. This
is perfect for the development environment.
So in this section, the author describes the following advantage:
You may have issues with the deployment if the driver is not JDBC4-compliant. In this case, installing the driver as a module solves those issues.
The following Wildfly documentation describes this also:
Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version. A JDBC JAR is identified using the Java service provider mechanism. Such JARs will contain a text a file named META-INF/services/java.sql.Driver, which contains the name of the class(es) of the Drivers which exist in that JAR. If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways. (...)
Thus, deploying your driver as a module is easier than deploying it as any other application package in case it is not JDBC-4 compliant. (Because you would have to modify and rebuild your JDBC-4 not compliant jar to deploy it as any other application package)
I have downloaded the JTOpen toolbox (http://jt400.sourceforge.net/) and am using the XPages Ext Lib "JDBC Driver Plug-in Wizard" to create an OSGI plug-in for JDBC access to iSeries files.
On the Wizard I left the Type drop-down empty and manually entered a Class of "com.ibm.as400.access.AS400JDBCDriver" - I think this is the correct class, but not 100% certain. I added the JAR file jt400.jar from the java6 directory of JTOpen.
After importing the generated site.xml into the Update Site database and restarting the HTTP task I issued a "tell http osgi ss com.ibm.as400" command - but do not see the OSGI plugin listed.
I have previously been through the same process for a JDBC driver for SQL Server and that works fine. I suspect I'm either using the wrong jar file or have the wrong class name. The Domino server is 9.0.1 FP1.
Any suggestions welcome!
If you issue the command tell http osgi diag com.ibm.as400, that will tell you of any dependency issues.
In trying to connect from an MQSeries 7.5 client to a 7.5 local server I'm getting a CSIException: JMSCS0002 which when I look up the error in the IBM codes says:
JMSCS0002
The call could not be completed because CommonServices has not been initialized.
CommonServices is an internal component and needs to be initialized at startup but has failed.
Check that the installation and classpath setup is correct.
But both my compile and run classpaths include com.ibm.mq.commonservices.jar, com.ibm.msg.client.commonservices.jar, and com.ibm.msg.client.commonservices.j2se.jar
I'm was using Oracle JDK 1.6. I tried using the WS MQ java but it made no difference.
Any help appreciated. Thanks.
Caused by: com.ibm.msg.client.commonservices.CSIException: JMSCS0002
at com.ibm.msg.client.commonservices.workqueue.PIWorkQueueManager.enqueueItem(PIWorkQueueManager.java:67)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.enqueue(WorkQueueManager.java:225)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.enqueue(WorkQueueManager.java:194)
at com.ibm.msg.client.wmq.common.internal.WMQThreadPool.enqueue(WMQThreadPool.java:91)
I had been using jar files from an uninstalled MQSeries 7.5 Client because I wanted to make sure that the functionality I was using would work just with the jars provided by the free client license. According to IBM documentation taking uninstalled jars is problematic.
When I switched to the jars from the installed server trial then things works ok.