Problem
When using IBM solidDB as the default TDI System Store the following error may be encountered:
CTGDIS810E handleException - cannot handle exception , get java.sql.SQLException: [Solid JDBC 06.30.0029] SOLID Database Error 16503: Serializable isolation level is not supported in M-tables.
This exception is thrown because the in-memory tables in solidDB do not support the default isolation level set in the Delta settings. You can find more information about this at http://publib.boulder.ibm.com/infocenter/soliddb/v6r3/index.jsp?topic=/com.ibm.swg.im.soliddb.admin.doc/doc/choosing.transaction.isolation.levels.html.
Solution
Possible workarounds are:
Problem
If we start 2 TDI Server instances using the same solution directory, with the default system queue, you may get this message from JMS:
javax.jms.JMSException: Cannot start a queue manager for JMS at com.ibm.mqe.jms.MQeConnectionFactory.startQueueManager(DashoA8173) at com.ibm.mqe.jms.MQeConnectionFactory.getQueueManager(DashoA8173) at com.ibm.mqe.jms.MQeConnectionFactory.startConnection(DashoA8173) at com.ibm.mqe.jms.MQeQueueConnectionFactory.createQueueConnection(DashoA8173) at com.ibm.mqe.jms.MQeQueueConnectionFactory.createQueueConnection(DashoA8173) at com.ibm.di.systemqueue.SystemQueue.<init>(SystemQueue.java:155) at com.ibm.di.systemqueue.SystemQueueEngine.initSystemQueue(SystemQueueEngine.java:158) at com.ibm.di.systemqueue.SystemQueueEngine.getInstance(SystemQueueEngine.java:119) at com.ibm.di.server.RS.initializeSystemQueue(RS.java:681) ...
MQe allows only once instance of a queue manager in one JVM, see http://publib.boulder.ibm.com/infocenter/iwedhelp/v6r0/index.jsp?topic=/com.ibm.mqe.doc/ovr51440.html
The first TDI Server/JVM will use the MQePWStore directory in the Solution Directory as its base directory.
Any subsequent TDI Server that is started with the same Solution Directory will have a separate JVM, and could potentially have it's own MQe. However, since it's using the same Solution Directory as the first JVM it doesn't have rights to that MQePWStore directory and hence the exception is thrown.
Solution
Use different Solution Directories for our TDI Servers, or use a different Queue Manager like IBM MQSeries.
TDI 6.1 and newer ships with the IBM Java Script Engine, replacing Rhino. The IBM Java Script Engine utilizes the regular express library shipped with Java 1.5 (java.util.regex.Pattern). This library is not fully compliant with the ECMA-262 specification regarding regular expressions.
TDI does not claim support for the ECMA-262 specification with regards to regular expressions. See the following URL to get details on the behavior and proper usage of the particular regular expression library that the IBM Java Script Engine uses: http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html.
When starting Launchpad, one of the options in the left navigation area is Exit. When you click Exit, a confirmation dialog box appears, giving the options OK and Cancel. The title bar of the confirmation window should display IBM TDI Install Launchpad. Firefox browsers incorrectly display the following string in the Exit confirmation window: Javascript Application.
This is a current limitation of Mozilla Firefox browsers. The problem may be fixed in future versions of TDI or Firefox browsers.
The TrustManager shipped with IBM Java Runtime Environment (JRE) 1.5.0 verifies a certificate chain up to the trusted certificate; it does not verify the trusted certificate itself. If the self-signed certificate is the trusted certificate, CERTPATH will not examine it to see whether the certificate is expired. Because CERTPATH does not check for self-signed certificate expiration, an SSL connection can be established with an expired certificate.
The TrustManager shipped with IBM JRE 1.4.2 verifies the entire certificate chain up to and including the trusted certificate. As a result, if an expired certificate is encountered, an exception is thrown. If you are using IBM JRE 1.5.0, but want to revert to 1.4.2 behavior regarding expired certificates, make the following changes:
In the java.security file of the Client JVM, change the following entry:
ssl.KeyManagerFactory.algorithm=IbmX509 ssl.TrustManagerFactory.algorithm=PKIX
to
ssl.KeyManagerFactory.algorithm=IbmX509 ssl.TrustManagerFactory.algorithm=IbmX509
If the SSL Client-Auth value is set to True, make the same change in the Server JVM's java.security file.
To disable components we will need to use the Initial Work Entry (IWE) to pass a control flag. If your AssemblyLine has an Iterator, store the value in a script variable and zero out the Work Entry; otherwise the Iterator will not engage on the first cycle.
For example, to disable a branch, we can use a script like this:
var branchEnabled = work.getString( "enableBranch" ); task.setWork( null );
Then set your Branch to "Match All" and include a scripted condition like this:
ret.value = branchEnabled.equals( "yes" );
If you intend to use IWE, use an extra attribute that clear out before continuing.
Disabling connectors is difficult and requires modifying the Config object before starting the AssemblyLine. If the connector is not disabled before we start the AssemblyLine, it will be initialized even if you disable it in the prolog before initialization. Modifying the in-memory Config object is possible, but not advised. An alternative is to set your connector to passive, but this will not help if you are trying to avoid an initialization completely.
The -c switch does not work with multiple filenames.
The -c switch has been designed so that a single configuration filename can be passed to the ibmdisrv command. If you do not specify the -d switch, only one configuration file is allowed.
ibmdisrv cannot be used to specify the AssemblyLines, using the -r switch, when the -c (config file) option specifies multiple Configs. Because the -r option is not operative while loading multiple Configs, we have to use either the autostart option or use -d and start the AssemblyLine using the Administration and Monitoring Console Interface.
Example:
With the AssemblyLines in the autostart folder, use this command to start multiple configs and AssemblyLines using ibmdisrv. You must specify the autostart option for the corresponding AssemblyLines.
ibmdisrv -d -c C1.xml,C2.xml
You can also start AssemblyLines on a running server other than the Administration and Monitoring Console using the tdisrvctl command in the bin folder.
When using TDI on a computer system that is running the Red Hat Enterprise Linux (RHEL) 5.0 operating system, or while using TDI on a computer system that is running any security-enhanced Linux (SELinux) operating system, a customer may see the error Failed to find VM - aborting when trying to invoke the TDI server, Configuration Editor, or other TDI commands.
RHEL 5.0 has a new security feature named "Security Enhanced Linux", or SELinux. A weaker version of SELinux was included in RHEL 4.0, and was disabled by default. RHEL 5.0 enables SELinux by default. SELinux helps to keep the host secure from certain types of malicious attacks. However, the default settings have been known in many cases to prevent Java 1.5 from running properly.
The TDI installer issues the command chcon -R -t textrel_shlib_t <install_dir/jvm/jre> to set the permissions. If for some reason the chcon command failed, or was unavailable, the TDI JRE is prevented from running by SELinux.
To fix this issue, we can choose one of the following options:
Substitute the installation path tdi_install_dir, for an installation path such as /opt/IBM/TDI/V7.0.