Restrictions for running DB2® UDB CLI in server mode
- A job must set 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 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 compiles while 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.
- 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 connect
to the local database, before using SQLDataSources. Since DataSources is used
to find the name of the RDB for connection, IBM® supports passing a NULL pointer for
the RDB name on SQLConnect. This obtains 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.
- If any other SQL work has been done in the job before
setting server mode in CLI, then it is impossible to change CLI's environment
to run in server mode. An example of this is the use of embedded SQL before
the call to do any CLI work that attempted to set the server
mode attribute.