SQL xa_open string Configuration Options

Enterprise Server provides xa_open string options for XARs in addition to those provided by each database vendor.

You can add these options to a resource definition by including them in the xa_open string using the format specified by the database vendor. For example, most databases use a comma separator (,), but Oracle uses a plus sign (+) separator. See your database documentation for more information.

UserP={T|F}

Determines how to establish the identity of the current Enterprise Server user for each CICS transaction or batch job.

T

The identity for the connection is established via the credentials of the current Enterprise Server user for each CICS transaction or batch job. This is known as User Impersonation. To use this option, the credentials supplied in the open string must be for an account that can impersonate other users, but otherwise should have minimal database privileges and access rights. See User Impersonation for CICS and JCL for more information.

Note:

• DB2 and Oracle - When UserP=T is set for a DB2 or an Oracle XAR that uses dynamic registration, you must build the module in Enterprise Developer and specify the XAID compiler directive option.
• One-phase commit for ODBC - UserP=T is supported only for SQL Server .
• User Impersonation is not supported for Web services.

F

The identity for the connection is established via the credentials supplied in the xa_open string and does not change. Default.

BatchOnly={T|F}

Determines the availability of XA resources in Enterprise Server SEPs.

T

Makes the associated XAR available in Enterprise Server via JCL only for batch jobs and their corresponding SEPs only. This saves transactional workload overhead because it does not require that a connection be opened in other Enterprise Server SEPs.

F

Makes the associated XAR available in all Enterprise Server SEPs. Default.

LocalTX={T|F}

Determines how the XAR handles transactions.

T

The associated XAR uses local (non-distributed) transactions. This option reduces overhead, and therefore can be a good option when using a single XAR. Be advised, however, that LocalTX=T also handles commits and roll backs for each XAR, independent of other resources, and should be used with care. Avoid setting LocalTX=T on jobs that use both VSAM and SQL.

F

The associated XAR uses XA distributed, global transactions. Default.