On Linux/UNIX systems, a number of utilities in the TDI_install_dir/bin directory must be invoked in a specific way due to scripting limitations. For example, a given utility script like tdiVerifyInstall.sh can be invoked as follows (assuming you are in the TDI_install_dir/bin directory):
./tdiVerifyInstall.sh or sh ./tdiVerifyInstall.sh or sh <absolute path>/tdiVerifyInstall.sh or tdiVerifyInstall.sh or sh tdiVerifyInstall.sh
The latter two invocations may yield an error like the following output shows:
which: no tdiVerifyInstall.sh in (/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11: /usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin) dirname: missing operand Try `dirname --help' for more information.
This is because the script fails to determine the absolute path of itself if invoked in those ways. Use one of the three first invocation ways instead.
When the configuration instance of an AssemblyLine is terminated on demand, this may cause corruption of the Derby database (applies only to Derby in embedded mode).
If that happens, on subsequent runs the Server may report an error with the System Store like: "java.sql.SQLException: Directory C:\tdi\TDISysStore already exists.".
A configuration instance is terminated on demand when:
To avoid the problem, either do not use termination on demand or do not use Derby in embedded mode.
This a problem that can occur on certain platforms. It all depends on how the platform resolves a hostname to an IP address when the hostname is represented by several IP addresses in the hosts file (or whatever mechanism is used to resolve hostnames). In order to troubleshoot the problem, check the following items:
First you should verify that there is a connection between the Config Editor (CE) workstation and the TDI server machine. Use ping ip-address to see if there is a path to the server where the TDI server runs. If the ping command fails, it could be that the firewall on the remote server has blocked this service.
Second, you should check the remote machine (or path to it) to see if it blocks access to ports used by the TDI server.
The error message in the CE will indicate a connection failure to an IP address that does not match the IP address you specified in the server document.
One reason for this may be that there are multiple entries in the /etc/hosts file on the TDI server side and one of them is inaccessible from the CE workstation.
On SLES 11 you will typically find an additional entry in the hosts file for the servers hostname (127.0.0.2 <hostname>). In the CE, if you see that it cannot connect to "127.0.0.*" this is an indication that this is the case. You can either remove this entry or tell TDI specifically which IP address to use for the server API.
If you choose the latter, then before starting "ibmdisrv" edit the script and modify the line that starts the server:
"$TDI_JAVA_PROGRAM" -Djava.rmi.server.hostname=<ip-address> $TDI_MIXEDMODE_FLAG -cp "$TDI_HOME_DIR/IDILoader.jar" "$LOG_4J" com.ibm.di.loader.IDILoader com.ibm.di.server.RS "$@"
The <ip-address> should be replaced with the proper IP address for the server where the TDI server runs. This is also the IP address you use in your server document connection string.
This problem is seen when your solution meets the following conditions:
On a machine with 3 GB of system memory the AssemblyLine had failed to initialize more than 30000 times before this could be seen.
This only affects ALs failing to initialize when started in Manual Mode. If your solution allows it, start the AssemblyLine in Normal Mode instead and wait for it to complete, otherwise please contact technical support.
You can use the Remote Command Line Function Component to execute shell scripts remotely (limited to the capabilites of the shell), but do not insert carriage returns into your shell script. Perform these steps:
Any shell script with a carriage return will not execute successfully. Avoid carriage returns in shell scripts.
You can find the following message: The java class is not found: Files\IBM\TDI\V6.1\IDILoader.jar com.ibm.di.server.RS - r AssemblyLines.allied -S C:\Documents in either the:
This is a problem with the PATH variable that TDI references from the OS. TDI sets the PATH variable in both the ibmditk.bat and ibmdisrv.bat, and ends the assignment with the system path - %PATH%. If your system path ends with a "\", it will cause this error to occur.
The reason the PATH variable is misbehaving is because the last entry might have the PATH variable ending with a "\" , instead of ";".
Integrator (This is OK).
Integrator; (This is OK).
Integrator\; (This is OK).
Integrator\ (This is not OK).
An error occurs when an encrypted password exceeds the size of the column where the password is stored:
ORA 12899 value too large for column "System".TESTPASSWD"."test1"(actual 178 , maximum 50)
To work around this problem, ensure that the tables used to store passwords are sufficiently large.
Normally a connector in Lookup mode expects only one hit, and if more than one hit occurs, you are given the opportunity to remedy the situation using error Hooks On Multiple Entries or On No Match. Connectors in the Loop Component behave differently:
If the Lookup Connector finds no entries, the following error occurs:
java.lang.Exception: [IF_MgrFound] Entry not found
Occasionally a crash also occurs if the exception is not caught.
To work around this error, enable the No Entry Found Hook without any code in it.
To prevent deletion of advanced link criteria, put your advanced Link Crit in a connector in your Library that you use in the Loop. Then you will inherit the Link Crit as well.
If you want to use more than one configuration file on the ibmdisrv command line, also specify the -d switch (Run in daemon mode) in addition to the -c switch. If you do not specify the -d switch, only one configuration file is allowed.
The problem is observed for configurations that have a solution name defined. When you request tombstones for such configuration by specifying the configuration file name instead of the solution name, no tombstones are found.
When querying tombstones, you can use a configuration file name for the -c option only when the configuration file contains no Solution Name:
tdisrvctl -op tombstone -c myconfig.xml -r al
In all other cases specify a configuration instance id or you will get no results:
tdisrvctl -op tombstone -c myconfig -r al
Note that from version 7.0 the Config Editor puts a Solution Name in each configuration file by default.
If you reinitialize connectors a lot, make sure to use their terminate() method before you call their initialize() method. The classic example is an AssemblyLine starting up but not able to connect to your data source. If the connector is not terminated before being initialized again, you might leak memory.