Restrictions for running DB2 for i CLI in server mode

Here are the restrictions when you run DB2® for i CLI in server mode.

• A job must set the server mode at the very beginning of processing before doing anything else. For jobs that are strictly CLI users, they must use the SQLSetEnvAttr call to turn on server mode. Remember to do this right after SQLAllocEnv but before any other calls. As soon as the server mode is on, it cannot be turned off.
• All the SQL functions run in the prestart jobs and commitment control. Do not start commitment control in the originating job either before or after entering server mode.
• Because the SQL is processed in the prestart job, there is no sensitivity to certain changes in the originating job. This includes changes to library list, job priority, message logging, and so forth. The prestart is sensitive to a change of the coded character set identifier (CCSID) value in the originating job, because this can affect the way data is mapped back to the program of the user.
• When running server mode, the application must use SQL commits and rollbacks, either embedded or by the SQL CLI. They cannot use the CL commands, because there is no commitment control that is running in the originating job. The job must issue a COMMIT statement before disconnecting; otherwise an implicit ROLLBACK occurs.
• It is not possible to use interactive SQL from a job in server mode. Use of STRSQL when in server mode results in an SQL6141 message.
• It is also not possible to perform SQL compilation in server mode. Server mode can be used when running compiled SQL programs, but must not be on for the compiles. The compiles fail if the job is in server mode.
• Function SQLDataSources() is unique in that it does not require a connection handle to run. When in server mode, the program must already have done a connection to the local database before using SQLDataSources(). Because SQLDataSources() is used to find the name of the RDB for connection, IBM® supports passing a NULL pointer for the RDB name on SQLConnect() to obtain a local connection. This makes it possible to write a generic program, when there is no prior knowledge of the system names.
• When doing commits and rollbacks through the CLI, the calls to SQLEndTran() and SQLTransact() must include a connection handle. When not running in server mode, one can omit the connection handle to commit everything. However, this is not supported in server mode, because each connection (or thread) has its own transaction scoping.
• It is not recommended to share connection handles across threads, when running in SQL server mode. This is because one thread can overwrite return data or error information that another thread has yet to process.
• Before V6R1, running CLI applications and Native JDBC applications in the same job will lead to unpredictable behavior. In most cases it will lead to errors. In V6R1 it is possible to run Native JDBC and CLI applications in the same job provided each interface runs in server mode and the CLI applications do not set any CLI environment attributes. CLI attributes can be specified at the connection and statement levels instead.
• Within a single job, CLI allows for a one time switch from non-server mode to server mode. As discussed earlier, it does not allow an application to switch from running in server mode to non-server mode.