After each modification of one of the configuration parameters, all of them are displayed upon the terminal.
4.2.3.1 MAXTIM Parameter
The MAXTIM parameter specifies the maximum time in milliseconds allowed for an SQL statement to execute.
The variable provided for this parameter must be of type PIC S9(9) COMP-2. If the execution of an SQL statement takes more than MAXTIM to execute, the current ORACLE operation is cancelled, the commitment unit is rolled back, and the TDS transaction is aborted. The return code issued is "ORACLE 38,
TIMEOUT".
Setting MAXTIM
The default value is 20000 milliseconds. The minimum value is 1000 milliseconds. The maximum value is 1000000 milliseconds.
The default value of MAXTIM is the same as the default value of TIMOUT (see below). If the value of MAXTIM is no greater than the value of TIMOUT, the
deadlock detection mechanism of TIMOUT with automatic rollback is never used since the value of MAXTIM takes precedence.
If MAXTIM is set to 0, the current value is left unchanged.
4.2.3.2 MAXWAT Parameter
The MAXWAT parameter specifies the maximum time a TPR can wait to re- establish an ORACLE connection that has been lost during the commit phase. The variable provided for this parameter must be of type PIC S9(9) COMP-2.
Setting MAXWAT
The default value is 240000 milliseconds. The minimum value is 60000 milliseconds. The maximum value is 1000000 milliseconds.
MAXWAT should be set to a value which corresponds to the maximum time the ORACLE database may be unavailable; that is, at least for the duration of a warm restart of the ORACLE database. It is also advisable to add the time necessary to restore and roll forward the database after a disk crash.
If this parameter is set to 0, the current value is left unchanged.
MAXWAT Exceeded
When TDS does not succeed in connecting to an ORACLE server after MAXWAT milliseconds, an error is returned (on the CONNECT statement of the TPR) through SQLCODE -6 ("Unrecoverable Timeout error").
In that case, the status of the ORACLE data remain unknown for the current commitment unit (they may have been committed or rolled back).
Specific action to recover this error depends on the application:
• if the Commitment Unit did not modify any ORACLE data, SQLCODE=-6 should be processed as a simple CONNECT failure (no risk of data being damaged).
4.2.3.3 TIMOUT Parameter
TIMOUT specifies the maximum time a TPR is allowed to wait for a non-available resource in an ORACLE database.
It is used to detect deadlocks between databases.
The variable provided for this parameter must be of type PIC S9(9) COMP-2. When the timeout event occurs, the current ORACLE operation is cancelled, the commitment unit is rolled back, and then restarted.
Setting TIMOUT
The default value is 20000 milliseconds. The minimum value is 1000 milliseconds. The maximum value is 1000000 milliseconds.
If TIMOUT is set to 0, the current value is left unchanged.
4.2.3.4 CSIZE Parameter
The CSIZE parameter specifies the number of ORACLE contexts which can be cached by the ORACLE/TDS interface. This can help optimize the performance of ORACLE/TDS applications.
Setting CSIZE
The default value for CSIZE is 16.
Minimum value is -1. This indicates that no ORACLE context is cached. Maximum value is 1024.
If set to 0, the current value is left unchanged.
In the Job Occurrence Report (JOR) of the ORACLE/TDS session you will find statistics relating to the ORACLE/TDS cache. These will help in determining an optimum value for CSIZE.
Changing the value of CSIZE may have direct consequences to the performance of your TDS application. So, you must be aware of the fact that:
• Reducing the CSIZE value reduces the number of ORACLE/TDS contexts cached. Then, "x" cache entries will be destroyed (where x = actual cache size - new CSIZE). This results in the physical disconnection of all connections
entries linked to each of these cache entries. The deleted cache entries are the oldest FREE entries.
• Setting CSIZE to -1 disconnects all FREE entries in the cache, which allows the shutdown of the accessed ORACLE servers without stopping your TDS
application (cache size is reduced to 0). For more information on ORACLE/TDS context caching, please refer to Chapter 5.
4.2.3.5 TRACELVL Parameter
This parameter specifies the TRACE level. There are two different trace levels: 1. the TRACE mechanism is not activated,
2. the basic TRACE mechanism is on. ORACLE/TDS events are traced.
3. detailed; SQLNET events are also traced.
When you use "ORACLE TRACEON", the TRACELVL is set to 1. When you use "ORACLE TRACEOFF", the TRACELVL is set to 0.
4.2.3.6 Tracefile Parameter
Starting from O7340A the trace file processing has change:
using the ORACLE transaction a user can specify a trace file which will be written in the « TDSname.SLLIB »:
• trace file name will be of the form « subfilename_trc » - command to issue is: ORACLE TRACEFILE = subfilename[_trc]
• it is possible to change trace file during the TDS session by issuing a new ORACLE transaction command. This, first close the current subfilename_trc and then, opens the new one
• if a trace level is active and no trace file mentioned ORACLE7 opens the ORACLE_TRC subfile in the « TDSname.SLLIB ».
• the new TRACELVL accepted values are: 0: no trace active,
2: minimum level of trace active,