The following command-line options are for the IBM TDI server (ibmdisrv [options]):
Example:
ibmdisrv -c"C:\demos\rs.xml" -r"Access2LDAP" -l"c:\metamerge\mydemo.log"
Notes:
If the specified directory does not exists, it will be created by the TDI server, and populated with a number of properties files (based upon those in the installation directory) that we can tailor to our needs. See Appendix B. Example Property files for more information.
Submitting multiple configuration files is only allowed if the -d option is also specified.
If we use includes and namespaces, the AssemblyLine can be myNamespace:/AssemblyLines/alName (assuming namespace myNamespace and AssemblyLine name alName).
If we start with -d, we will start one anonymous instance (the daemon), which will start one config instance for each config file specified on the command line; this allows us to start multiple config instances on the fly. You may specify 0 or more config files on the command line. It does not make sense to specify any AssemblyLines to run in this mode, since it is impossible to state which config file the AssemblyLine will be in. We can autostart AssemblyLines, though, since those belong to the config instance that specifies the autostart.
If we start without -d, we will get one config instance that loads the config file specified on the command line. You must specify exactly one config file on the command line. (If use multiple config files, they may be piped in on standard input.) In this mode, we can specify any number of AssemblyLines to run. This is the traditional way of running the server.
If any property files are specified at the command line, they are valid only for the Config Instances specified with the -c command-line option (which are loaded on TDI server startup). The property files specified at the command line do not have any impact on Config Instances which have not been explicitly named with the -c command-line option (these can be Config Instances loaded by remote server API client for example).
If a Property Store whose name is specified with the -f command-line switch cannot be found in a Config Instance, an error message is logged in the server log (ibmdi.log in the Install-directory). When a Property Store name is specified more than once with the -f command-line switch then there are two effects: (1) a warning message is logged, and (2) the file specified last will take effect. This feature is implemented in the com.ibm.di.server.RS Java class (referenced by way of the main variable when scripting). After the reload() method is called, the MetamergeConfig object is loaded, and for each Property Store specified on the command line, the corresponding PropertyStoreConfig object is updated.
Although Copy/Paste of Config objects (ALs, Connectors, FCs, and so forth) are fully supported. We can easily copy ALs and components and then paste them into another Config. We can also exchange ALs and components using IM chats, e-mails and text files, because the copy-buffer is filled with the TDI Config XML definition of the selected item. This makes passing stuff around simple and easy, and is a great tool for support and online assistance (for example, ICT/NotesBuddy, forums, ...).
Make sure we select the entire <MetamergeConfig> node in your copy command, including the start and end tags.
When IBM TDI ends it returns one of the following exit codes:
AssemblyLines run from the Configuration Editor are started in a different way and will not exit with status 2.
If the Server is shutdown by an administration request and a custom exit code is specified, that custom code will be used as the exit code of the Server.