|
In order to interface an RDBMS (Oracle, DB/2, SyBase, etc), XCICS requires some additional information such dbc and binding.
DBC (DataBase Connection)
A DBC entry is an object identifying the single connection RDBMS/USER, and can be defined using define dbc.
Syntax:
| define dbc | name=<value>,
database=<value>,
user=<value>,
password=<value>,
[connect_type=(1|2)],
[sql_rules=(db2|std)]
[syncpoint_type=(onephase|twophase|none)],
[disconnect_type=(expl|cond|auto)],
[deferred_prepare=(no|yes|all)]; |
name
name is the dbc identifier (used in bind)
database
the database identifier.
user
the database user
password
the user password.
The database identifier
The database identifier, specified with the parameter database, is name used by the database communication layer to identify a local or remote database instance. It corresponds at the following objects, depending on the database in use.
Database
|
Value
|
Oracle Database
|
The TNS name of the instance, as referred in sqlnet.ora
|
IBM UDB
|
The database name as defined in the local UDB instance
|
MS SQL Server
|
The ODBC connection name that identifies the SQL Server instance
|
ODBC database connections
|
The ODBC connection name that identifies the ODBC database instance
|
Binding
Binding is the relationship between XCICS users, transactions and dbc. Using bind it is possible to associate a specific dbc to some transaction or some users.
A default binding must be provided. Binding is specified using bind.
Syntax
bind dbc=<name> default;
or
bind dbc=<name>, user=(<name>|*), transaction=(<name>|*);
When specifying a default it means that all users and transaction are using that dbc, if not furthermore specified.
Specific bind can be done using the second format of bind directive.
user
name of XCICS user using that dbc. If astersik (*) is specified all user can use the dbc.
transaction
TAC of the transaction using that dbc. If astersik (*) is specified all transaction can use the dbc.
For Example:
#
# defining the production DB...
# both for standard and administration functions
#
define dbc name=PROD, database=ORAPROD, user=CED01, password=CED01;
define dbc name=ADMPROD, database=ORAPROD, user=SYSTEM, password=MANAGER;
#
# ...and the Test DB
#
define dbc name=TEST, database=ORATEST, user=CED02, password=XXX;
#
# application default dbc is PROD
#
bind dbc=PROD default;
#
# user DEVEL must use TEST DB for ALL transactions
#
bind dbc=TEST, user=DEVEL, transaction=*;
#
# transaction DBA1 uses on TEST DB
#
bind dbc=TEST, user=*, transaction=DBA1;
#
# user ROOT works on PROD with DBA1
#
bind dbc=PROD, user=ROOT, transaction=DBA1
Native UDB only parameters
The following parameters apply only to "native" type connections to UDB database. The native UDB connection type is selected at the moment of XFRAME installation for UNIX/Linux system and in the configuration file for Windows.
These options configure the UDB client API layer (SET CLIENT API), and they have no effect on other connections types (i.e. Oracle or UDB/XA).
For further information on UDB client API settings please refer to the IBM UDB documentation.
connection_type
Specifies how to set up the CONNECTION type. The valid values are:
Value
|
Description
|
1
|
Type 1 CONNECTs enforce the single database per unit of work semantics of older releases, also known as the rules for remote unit of work (RUOW).
|
2
|
Type 2 CONNECTs support the multiple databases per unit of work semantics of DUOW.
|
Default value is "1".
sql_rules
Specifies how to set up the SQLRULES. The valid values are:
Value
|
Description
|
db2
|
Enable the SQL CONNECT statement to switch the current connection to an established (dormant) connection.
|
std
|
Permit only the establishment of a new connection through the SQL CONNECT statement. The SQL SET CONNECTION statement must be used to switch the current connection to a dormant connection.
|
Default value is "db2".
syncpoint_type
Specifies how to set up the coordination among multiple database connections during commits or rollbacks. The valid values are:
Value
|
Description
|
onephase
|
Uses one-phase commits to commit the work done by each database in multiple database transactions. Enforces single updater, multiple read behavior.
|
twophase
|
Requires a Transaction Manager (TM) to coordinate two-phase commits among databases that support this protocol.
|
none
|
Uses one-phase commits to commit work done, but does not enforce single updater, multiple read behavior.
|
Default value is "twophase".
disconnect_type
Specifies how to set up the scope of disconnection to databases at commit. The valid values are:
Value
|
Description
|
expl
|
Removes those connections that have been explicitly marked for release by the SQL RELEASE statement at commit.
|
cond
|
Breaks those connections that have no open WITH HOLD cursors at commit, and those that have been marked for release by the SQL RELEASE statement.
|
auto
|
Breaks all connections at commit.
|
Default value is "expl".
deferred_prepare
Specifies when to execute the PREPARE statement. The valid values are:
Value
|
Description
|
no
|
The PREPARE statement will be executed at the time it is issued.
|
yes
|
Execution of the PREPARE statement will be deferred until the corresponding OPEN, DESCRIBE, or EXECUTE statement is issued. The PREPARE statement will not be deferred if it uses the INTO clause, which requires an SQLDA to be returned immediately. However, if the PREPARE INTO statement is issued for a cursor that does not use any parameter markers, the processing will be optimized by pre-OPENing the cursor when the PREPARE is executed.
|
all
|
Same as YES, except that a PREPARE INTO statement which contains parameter markers is deferred. If a PREPARE INTO statement does not contain parameter markers, pre-OPENing of the cursor will still be performed. If the PREPARE statement uses the INTO clause to return an SQLDA, the application must not reference the content of this SQLDA until the OPEN, DESCRIBE, or EXECUTE statement is issued and returned.
|
Default value is "no".
|
