Maintaining Siebel Business Applications on DB2 for z/OS

This chapter describes maintenance tasks that you can perform to improve the performance of Siebel Business Applications on DB2 for z/OS after you have completed the Siebel application installation. This chapter includes the following topics:

DB2 Statistics for Siebel Business Applications

It is recommended that you apply statistics to Siebel Business Applications. Update statistics on table spaces that contain EIM interface tables and base tables (including table spaces that contain extension tables and repository tables) when there has been a change of 20 percent or more in the row distribution. It is usually not necessary to update statistics on all of the table spaces, only on those containing tables that have changed.

The RUNSTATS utility and the DSTATS utility are recommended for updating statistics.

About the RUNSTATS Utility

The RUNSTATS utility can be used to collect distribution and frequency statistics for all types of columns (indexed and nonindexed) and for user-defined groups of columns. You can use RUNSTATs to collect statistics on the most and least frequently occurring values, and to collect cardinal values for groups of columns.

Refer to the DB2 catalog history tables to determine when you need to reorganize a table or when you need to update the statistics for a table. When you execute RUNSTATS, you can specify options that allow you to update the catalog history tables without updating the statistics in the catalog tables. This allows you to populate the history tables without affecting existing access paths.

You can run the rstat390 utility from your UNIX or Windows midtier computer to execute RUNSTATS on the DB2 host. The rstat390 script is located within the SIEBSRVR_ROOT\bin directory (Windows) or the SIEBSRVR_ROOT/bin directory (UNIX). For rstat390 help, use option /h.

Update statistics only when there is little activity on the Siebel database, such as after midnight. If you run this utility while users are accessing and updating the Siebel database, lock contention can occur. When this happens, an error message is generated, for example, the following error message is generated from rstat390:

ODBC error S1000 in SQLExecDirect: [IBM][CLI Driver][DB2/6000] SQL2310N The utility 
could not generate statistics. Error "-911" was returned.

This error does not indicate that your database has been harmed; however, you do have to rerun the RUNSTATS job for any table for which this type of error is generated, because statistics were not updated for that table.

You can execute RUNSTATS on an active system if you specify shrlevel change as an option. This option allows concurrent access while the RUNSTATS utility executes. You can also execute RUNSTATS directly from the DB2 host. For additional information on the options available with the RUNSTATS utility, see the relevant IBM documentation.

When to Use the DSTATS Utility

You can execute RUNSTATS following the reorganization of any fragmented table spaces and indexes. For more information on this topic, see About Reorganizing Table Spaces, Partitions, and Indexes.

If you are experiencing slow queries, however, run the DSTATS utility. Slow queries can result when the optimizer chooses an inefficient access path as a result of data skew on nonleading indexed columns or nonindexed columns. In such cases, IBM recommends running the DSTATS utility to collect column distribution statistics on these columns; this can lead to significant improvements in the query time.

About Reorganizing Table Spaces, Partitions, and Indexes

It is recommended that you reorganize the table spaces, partitions, and indexes that have a tendency to become fragmented.

No strict guidelines can be offered as to which table spaces, partitions, and indexes might require reorganization due to the variety in application and customer operation variables at any given customer site. However, database administrators must pay attention to the status of large or heavily used table spaces and indexes, because fragmentation of these objects can affect performance significantly.

Avoid using online REORG of Siebel Repository table spaces. Schedule reorganization of Siebel Repository table spaces during application downtime to avoid adversely affecting the Siebel application.

After you reorganize table spaces and indexes, it is recommended that you execute rstat390 (from the midtier) or RUNSTATS (on the DB2 host). For more information on how to run this utility, see About the RUNSTATS Utility.

About Cursor Close

Cursor close allows you to regulate system resource utilization by Siebel clients in a z/OS environment by setting the MaxCursorSize cursor configuration parameter. This parameter specifies the number of database rows a Siebel client cursor can get from a user-entered query or a Siebel operation that generates a SQL query.

Note: There are two cursor configuration parameters: MaxCursorSize and PreFetchSize. When using Siebel Business Applications on DB2 for z/OS, however, only the value you specify for the MaxCursorSize parameter is used; values specified for the PreFetchSize parameter are ignored.

The MaxCursorSize cursor configuration parameter is read at startup from the following places:

Enterprise profile configuration parameters on the Siebel Server for Siebel Web Clients.
Application configuration (.cfg) file for Siebel Developer Web Clients and Siebel Mobile Web Clients.

The Siebel client connector closes the SQL cursor after the number of rows specified by the MaxCursorSize cursor close parameter have been retrieved.

You can choose whether to use cursor close in restricted or unrestricted modes.

Unrestricted Mode

When the MaxCursorSize cursor configuration parameter is not specified or is set to a value of -1, the Siebel application opens a cursor on the user’s behalf and retrieves blocks of records until the query result set is exhausted or until the user cancels the display of remaining records. When a user remains on a list applet with multiple screens of data, for example, Contact List Applet, the application continues to hold the cursor.

The impact on database and network resources when a query returns a large result set can be significant.

Restricted Mode

During normal operation (restricted mode), with the MaxCursorSize cursor configuration parameter set appropriately, the Siebel application retrieves up to the MaxCursorSize number of rows from the Siebel database.

For example, if MaxCursorSize is specified as 128, the Siebel application retrieves up to 128 rows from the database for a single operation or query. The Siebel application then closes the cursor, releasing the thread for other users to access. The user can then scroll through the retrieved rows, because the rows are cached on the Siebel Server within the Application Object Manager.

If a user tries to scroll to records beyond the value of MaxCursorSize (128 in the example), the cursor close alert appears:

There were more rows than could be returned. Please refine your query to bring back 
fewer rows.

Suppose, for example, that you navigate to the My Opportunities view, which is sorted by the Name column. Seventy-five rows qualify for this query. The initial query returns 128 rows. When you try to scroll to the 129th opportunity, the cursor close alert appears. You then have to choose Edit, Query, and then Refine Query. Type ‘>’ in the Name field, and then execute the query to retrieve additional records.

Cursor Close Parameter Values on DB2 for z/OS

By default, on other DBMS platforms, Siebel Business Applications set both MaxCursorSize and PreFetchSize to a value of -1, which causes the cursors to remain open to retrieve additional data.

On DB2 for z/OS, setting the value of the MaxCursorSize parameter to -1 can cause a high number of DB2 Database Active Threads (DBAT); this can potentially lead to DB2 DBM1 address-space task abnormal ends, caused by DBM1 virtual storage constraints. To alleviate this problem, it is recommended that z/OS users set the MaxCursorSize parameter to a positive value. (Siebel Business Applications on DB2 for z/OS ignore values specified for the PreFetchSize parameter.)

The minimum acceptable value that you can specify for the MaxCursorSize cursor close parameter is 32; the default value is 128. This value allows a reasonable number of rows to be retrieved without holding open the cursor. After the cursor is closed, the change is committed and the Database Active Thread (DBAT) becomes inactive.

Note: The default value of the MaxCursorSize parameter for Siebel Tools is -1; because the number of Siebel Tools users is relatively small, the number of active connections at any time is unlikely to exceed the DB2 for z/OS limit.

It is recommended that your corporate IT department and Siebel Business Applications administrator collaborate to determine the value for the cursor close parameter that is most appropriate for each class of users connecting to DB2 for z/OS. Guidelines are outlined in the following table; these are not mandated, but they provide a balance between system resource utilization, user responsiveness, and productivity. However, your enterprise might have unique requirements beyond the scope of this chapter.

Cursor Close Ignored

Many specialized Siebel business components, such as Application Administration, List Management, all charts, all picklists (List Of Values), and all calendar views have been modified to ignore the cursor configuration parameter setting. Ignoring the settings allows these functions to operate correctly.

Modifying the Cursor Close Alert Message

You can modify the message that is displayed to the user when there are more rows than can be returned in a query.

To modify the cursor close alert message

In your Siebel application, navigate to the Administration-Application screen, then the System Preferences view.
The System Preferences view appears.
In the System Preference Name column, select the SSASqlErrRsltsDiscarded parameter.
Edit the value in the System Preference Value column to how you want the cursor close alert message to display.
The maximum message length is 200 characters.
Restart the Siebel application.

Changing Cursor Configuration Parameter Values

This topic describes how to change the cursor configuration parameter values. You can change the cursor configuration parameter for Siebel clients in the following locations:

Application configuration (.cfg) files for the Siebel Developer Web Client and Siebel Mobile Web Client.
From the command line for the Siebel Web Client.
Because the Siebel Web Client does not have an application configuration file, it uses the configuration parameter values specified for the Enterprise Server; these values are applied to all server components and the Web Client.
Application configuration (.cfg) file for Siebel Tools.
At the business component level in Siebel Tools.

For information on overriding the MaxCursorSize parameter value from within a Siebel script, see 478276.1 (Article ID) on My Oracle Support. This document was formerly published as Siebel Technical Note 592. For information on Siebel clients, see Siebel Installation Guide for the operating system you are using. For more information on Siebel Tools, see Using Siebel Tools.

Setting the Cursor Configuration Parameter for the Siebel Web Client and Siebel Servers

For the Siebel Web Client, the MaxCursorSize parameter value is set from the command line at the Siebel Enterprise Server level. As a result, you cannot set this parameter separately for each class of users. You must set it to the same value for all users, typically 128.

For additional information on modifying enterprise server parameters and using the Siebel Server Manager command-line interface (srvrmgr) program, see Siebel System Administration Guide.

To set the cursor configuration parameter value for the Siebel Web Client

List the DSMaxCursorSize cursor configuration parameter to check its current value. From the Siebel Server Manager command-line interface, enter the following:
```
srvrmgr > list advanced param DSMaxCursorSize for named subsystem ServerDataSrc
```
Change the value of the DSMaxCursorSize parameter by entering the following from the command line:
```
srvrmgr > change parameter DSMaxCursorSize=valuefor named subsystem 
ServerDataSrc
```
where value is the new value you want to specify for the DSMaxCursorSize parameter.
Stop and restart the Siebel Server for the changes to take effect.

Setting the Cursor Configuration Parameter for the Siebel Developer Web Client and Siebel Mobile Web Client

For the Siebel Developer Web Client and the Siebel Mobile Web Client, you can set the MaxCursorSize cursor configuration parameter for different classes of users in application configuration files. The following table lists the user classes and the recommended MaxCursorSize parameter value for each class.

Note: You do not need to set a cursor configuration parameter value for Siebel Mobile Web Client users who connect exclusively to the local database and update by synchronizing with the corporate Siebel database. These users do not have a cursor configuration parameter in the [Local] sections of their application configuration (.cfg) files.

Take special care with the training of Siebel Mobile Web Client users who access both their local database and the Siebel database. This training must include explaining the difference in operation between the two platforms, setting appropriate expectations for receiving cursor close alerts when connected to the Siebel database, and showing how to formulate queries for common cursor close alert scenarios.

Table User Classes and Recommended Max CursorSize Parameter Values

User Class	Description	Recommended Value
Siebel administrator	Accesses the database to perform system updates. Might need to access large amounts of data.	-1
Siebel application developer	Performs development and customization of the Siebel application using Siebel Tools.	-1
Special	Sporadically submits queries or executes operations returning a large number of rows. Special users cannot be effective if their queries are limited by the cursor configuration parameter value. Examples include: No requery formulation is available to access the next set of data. Operation requires the complete result set. Data returned must be internally consistent. When a requery is issued, the returned data set might have changed because of other database activity.	-1
Typical	Majority of users. Examples include call center agents and sales representatives.	128

For information on application configuration files, see Siebel System Administration Guide.

To set the cursor configuration parameter for the Siebel Developer and Siebel Mobile Web Clients

Create a backup copy of the application configuration (.cfg) file.
Open the original .cfg file in a text editor.
Set the MaxCursorSize parameter in the [ServerDataSrc] section of the .cfg file.
Save your changes.

Using Siebel Tools to Bypass the Number of Rows Returned

There might be cases where you do not want to change the general limitation concerning the number of rows returned (default 128), but do want to have an unlimited number of rows available for certain operations.

To do this, leave the parameter value for MaxCursorSize in the .cfg file set to the default number (or any number you choose), but use Siebel Tools to set values for the specific business components for which you want unrestricted operation.

To ignore the cursor close limitation, change the properties for the MaxCursorSize parameter for these business components to -1.

Database Connection Pooling

Siebel database Connection Pooling is a feature that allows database connections to be shared and reused, so reducing the number of DB2 database active threads (DBATs) that are required. This feature saves the overhead of creating and maintaining database connections for each user session and allows the number of concurrent user sessions to exceed the number of database connections. Database Connection Pooling is not enabled by default.

About Database Connection Pooling

With Database Connection Pooling, a user session is not tied to a database connection. The Application Object Manager component creates database connections as required. When a new connection is needed (a user session is started), the Application Object Manager creates an initial connection for user authentication. If there are connections in the connection pool, this initial connection is dropped; if the shared connection pool is empty, this initial connection is added to the pool.

When the user issues a query, it is run on any free database connection in the pool and the connection is blocked until the statement has finished running. When the query completes, the connection is returned to the pool and becomes available to run any other user queries. If a number of users issue fast-running queries, they can share the same connection without blocking.

If the user issues a query and all the existing connections are busy, then a new connection is created, provided the pool has less than the maximum number of connections allowed. Thevalue specified for theMaxSharedDbConns server parameterdetermines the maximum number of database connections that can be created.

When the maximum number of connections is reached, the Application Object Manager randomly checks all existing connections for their availability and assigns the query to the first free connection that it finds. The Application Object Manager keeps track of connection utilization and determines the minimum number of connections that is required depending on statement load.

For additional information on Database Connection Pooling, see Siebel Performance Tuning Guide.

Note: In the current release of Siebel Business Applications, you can cancel user-initiated query operations even if Connection Pooling is turned on.

About Connection Pooling and Cursor Close

Connection Pooling can give you flexibility in increasing the number of rows returned from a query or in keeping cursors open by setting the DSMaxCursorSize parameter to -1. However, consider the latter option only if it is essential to your business needs. Setting the DSMaxCursorSize parameter to the -1 setting requires careful DB2 buffer pool tuning and the use of DB2 storage contraction DSNZPARMs. For further information, see About Cursor Close and DSNZPARM Parameter Settings for Siebel Business Applications.

You must also review the unlimited cursor close values in combination with other factors, such as:

DB2 DBM1 virtual storage
Transaction rate of arrival
Average length of a transaction
Maximum number of connected threads
Number of expected long-running complex queries

Dynamic SQL in the Siebel Application

Traditional applications are typically based on static, hard-coded SQL. However, Siebel Business Applications generate dynamic SQL statements at run time, using the Siebel Application Object Manager and the program configuration in use by the customer. As a result, SQL statements can be as individual as the deployments in which they occur and, in some cases, dynamic SQL can become very complex, for example, joins with 30-40 tables are not uncommon.

To reduce the complexity of generated SQL (such as the number of joins, the number of columns in SELECT statements, or the number of tables in FROM statements), consider eliminating columns from the standard Siebel applets that you do not require for your business needs, especially in the most frequently used screens and views. Also keep this consideration in mind when you customize the Siebel application by creating new objects.

About Spooling SQL in the Siebel Application

Using spooling with the Siebel application can be useful for several reasons:

It allows you to identify the SQL statement being executed when an SQL error code is returned.
It can help you in assessing the time taken by the various SQL statements when you encounter performance issues.
When data appears to be missing from a view, you can identify the SQL used to retrieve that data.

You can then run the SQL manually, either from the midtier computer, for example using the DB2 Command Center, or on the DB2 for z/OS host, for example using tools such as SPUFI, to see what data is being returned.

To minimize the amount of SQL tracing produced, and, therefore, the size of the log files, limit the tests to the minimum number of screen changes needed to allow the issue to be reproduced. If possible, spool SQL on a Developer Web Client as you have more control over the testing which makes it easier to minimize the amount of SQL traced.

Note: The z/OS-specific parameters of SQL statements are not displayed in the spool files. Add appropriate values for the z/OS parameters to the spooled SQL to ensure that the output of any Explain statements you run on the spooled SQL is not misleading.

Turning on SQL Spooling for the Application Object Manager and the Database Connector

You can turn on component event logging for the Developer and Mobile Web Clients and the server component. You can spool the SQL generated by the Siebel Application Object Manager and by the database connector but do not turn on spooling for both. If you do, the amount of data returned will be confusing.

To turn on SQL spooling for the Application Object Manager

To turn on SQL spooling for the Application Object Manager, set the component event Application Object Manager SQL Log to 4.

To turn on SQL spooling for the database connector

To turn on SQL spooling for the database connector, set the component event SQL Parse and Execute to 5.

For some components, the SQL Profiling event can be used to identify the most poorly performing queries.

For Developer Web Clients, you can also set these component events as environment variables. They work in addition to the spooling options.

About Tracing SQL Generated by the Siebel Application

The SQL that the Siebel application generates is sent to the DB2 host on the z/OS platform through ODBC and the DB2 Call Level Interface (CLI) before the SQL command is processed by DB2. To effectively troubleshoot issues, you might have to trace the relevant SQL statement through one or all of these layers. For help selecting the most appropriate tracing for the situation, create a service request (SR) on My Oracle Support.

Steps to initiate tracing are described in the following topics:

Enabling DB2 CLI Tracing

You can enable DB2 Call Level Interface (CLI) tracing by adding the following lines to the db2cli.ini file (this procedure applies to Windows and UNIX).

To enable DB2 CLI tracing

Add a section to the db2cli.ini file labeled [COMMON].

Add the following entries to the [COMMON] section.

[COMMON]
Trace=1
TracePathName=C:\TRACE
TraceFlush=1
TraceComm=1

For each thread, one trace file is created in the path specified in TracePathName (ensure you have already created the path). On UNIX systems, the DB2 process owner must have the appropriate permissions to write to the directory specified in TracePathName.

Only review the trace files created at the time of problem re-creation.

Each DB2 process generates its own trace file. The events in the DB2 CLI trace are specific to DB2 clients.

About Enabling ODBC Tracing

You can enable ODBC tracing by following the instructions in 475526.1 (Article ID) on My Oracle Support. This document was formerly published as Siebel FAQ 1343. ODBC tracing produces results similar to the CLI trace, but focuses on the ODBC API calls. You cannot see the data being passed in the SQLExecute calls with the ODBC trace but you can see it in the DB2 CLI traces.

Enabling SQL Tracing for Siebel Database Utilities

You can enable SQL tracing by setting the DBUTIL_LOG_EVENTS environment variable before you run any of the Siebel database utilities, for example, the ddlimp, dataimp, ddlsync, dev2prod, or repimexp utilities.

To enable SQL tracing for Siebel database utilities

Set the environment variables as follows:

set DBUTIL_LOG_EVENTS=SQLParseAndExecute=5,SQLDBUtilityLog=3

About SQL Tracing on the DB2 Host

Determine the tracing to set on the DB2 host in conjunction with the DBA. Refer to the documentation for the DB2 performance monitoring tool you use to determine how to enable the tracing.

Long-Running Queries and the RLF Error Message

You can set the DB2 Resource Limit Facility (RLF) to cancel long-running queries. For more information on using RLF, refer to the appropriate IBM documentation.

When performing long-running queries, users might receive the following RLF error message:

An error has occurred executing a query.  Query did not execute successfully because 
it exceeded the resource limits set on the database server.
Please simplify your query or report this problem to your systems administrator.

This error occurs when an SQL statement is canceled by the DB2 Governor, because it exceeds the resource limits set on the database server.

If this message results from the execution of a Query by Example (QBE), users can try to simplify the query, or contact their systems administrator and describe what they were doing in the application when the error occurred.

Using the odbcsql Utility to Submit SQL Statements

The Siebel Server installation program installs the odbcsql utility in the SIEBSRVR_ROOT\bin directory (Windows) or the SIEBSRVR_ROOT/bin directory (UNIX) of the Siebel Server. Siebel Business Applications use this program to perform operations on the DB2 database whenever these operations are performed from the midtier, that is, from the Siebel Server.

You can use odbcsql to submit SQL statements, for example, to obtain the DB2 storage group names for data and indexes which you have to specify during the Siebel database installation process.

Note: You can also use other utilities that allow you to query and return result sets to the client.

You can also use odbcsql to test your ODBC data source after you install the Siebel Server.

To execute odbcsql

Navigate to the SIEBSRVR_ROOT\bin directory (Windows) or the SIEBSRVR_ROOT/bin directory (UNIX) and enter the following from the command prompt:
```
odbcsql /s database_alias /u username /p password
```
for example:
```
odbcsql /s siebsrvr_siebel /u sadmin /p dgt^js12*gzs
```
where:
- /s is the source ODBC DSN for the connection
- /u is the user ID
- /p is the password
If the odbcsql connection is successful, you can enter queries against the DB2 catalog tables. For example, the following query returns a list of all DB2 storage groups:
```
SELECT NAME FROM SYSIBM.SYSSTOGROUP;
```
To exit odbcsql, enter EXIT. For additional information on the utility, enter the following at a command prompt:
```
odbcsql /help
```

The odbcsql utility is also useful in troubleshooting postinstallation connectivity problems that arise in the ODBC layer of your installation.

Enabling DB2 Dynamic Statement Caching

Siebel Business Applications use the DB2 global statement caching capability. Global statement caching allows dynamic SQL statements that are reexecuted to bypass the PREPARE phase after the first execution. Dynamic statements are prepared once, stored on a global statement cache, then reused many times. The Siebel application also maximizes the reuse of statement caching.

To enable global statement caching either

Set the CACHEDYN parameter to YES in the macro DSN6SPRM when generating DSNZPARMs.
Set CACHE DYNAMIC SQL to YES when installing DB2.

About Managing the Dynamic Statement Cache

Because DB2 uses the Environmental Descriptor Manager (EDM) component to manage the dynamic statement cache, it is important that you set EDM-related system parameters to appropriate values. Prior to DB2 for z/OS Version 8, the cached SQL statements were stored in either the primary EDM Pool, or in a data space. In DB2 for z/OS Version 8 and later releases, the cached SQL statements are always stored in a dedicated storage pool above the 2-GB bar. For guidance on setting the EDM system parameters, see your IBM documentation.

Note: Monitor and adjust the EDM Pool and the related cache storage areas based on your workload.

System parameters associated with dynamic statement caching are described in the following table.

Table System Parameters Associated with Dynamic Statement Caching

Parameter	Value	Description
CACHEDYN	YES	Enables dynamic statement caching.
`CONTSTOR`	`YES`	Contracts working storage for connections periodically (every 50 commits or when storage use reaches 2 MB).
`EDMPOOL`	`32768`	EDM pool storage size in KB.
EDMSTMTC	102400	Global statement cache size, in KB, used by EDM in DB2 for z/OS Version 8 and later releases.
`MINSTOR`	`YES`	Minimizes thread storage usage.

About Invalidating Cached Statements

After DB2 prepares a SQL statement and places it in the global statement cache, it is reused. If you are performing SQL tuning and you want to force DB2 to prepare and reoptimize a cached statement, the global SQL statement cache must be invalidated.

To invalidate an entry in the global statement cache for a specific SQL statement, one of the tables referenced by the SQL statement or the table catalog statistics must be altered in some way.

You can invalidate a dynamically cached statement using one of the following methods:

Use the RUNSTATS utility to automatically invalidate cached statements that refer to objects against which RUNSTATS is executed. You can run the RUNSTATS utility on any table or table space referenced in the SQL statement.
You can use the REPORT NO UPDATE NONE option to invalidate the cache entries without incurring the overhead of executing all the RUNSTATS logic.
Use the DB2 command STOPOBJECT or the SQL DROP, ALTER, or REVOKE statements (for example, REVOKEALLFROM PUBLIC) on any object related to the plan to invalidate both global and local caches. While some ALTER statements require that an object is stopped, others do not; for example, STOP OBJECT is not required for DROP or REVOKE.
Use the command ALTER TABLE tablename AUDIT NONE to purge statements that reference the named table from the cache.
Use a CREATE INDEX statement on tables used in the DB2 access path.
Stop the DB2 subsystem and restart it.

Tracing the Source of a Query

Administrators can identify the terminals from which queries are generated using the Session ID. The session ID is composed of three parts: ClientIP_ClientProcessID_SerialNumber. The following is an example of a session ID:

172.20.80.25_324_1.

Eventually, the Application Object Manager and the DB2 host share the same string which can be used to identify the current connection.

After the session ID is displayed at the Server Manager, you can also check it on the database side.

To verify session ID on the DB2 host

At the Option prompt, enter the location of the DB2 Primary Option Menu.
The DB2 Primary Option Menu appears.
At the Command prompt, enter D to access the DB2 Defaults Panel.
At the Command prompt, enter the name of the subsystem that you are connecting to.
Press F3 to go back to the DB2 Primary Option Menu.
At the Command prompt, enter the appropriate selection to go to the DB2 Command window.
At the DB2 Command window, enter the following:
```
-DISPLAY THREAD(*) DETAIL 
```
Note: The hyphen before DISPLAY is required.
Press Enter to display current active threads.
The session ID string is displayed in the application name field. If there are many active threads shown, identify your thread by matching the corresponding host name and userid.

About Coordinated Universal Time and DB2 for z/OS

Siebel Global Deployment Guide contains information on using Coordinated Universal Time (UTC). In Siebel Business Applications, the UTC System Preference default value is TRUE. If you do not want to implement UTC, you must change this value to FALSE.

When installing and configuring UTC on DB2 for z/OS, consider the following:

The Siebel UTC implementation only works if the system time that the database software uses is in UTC.
Any system or database parameter that implements a time zone different to UTC must remain at zero. The use of any other value is not supported, as it effectively returns the database configuration to a local time zone.
As an example, the z/OS system parameter, TIMEZONE, can be set in the CLOCKxx member of SYS1.PARMLIB. For a correct Siebel UTC implementation, the value of this parameter must be zero, as shown:
```
TIMEZONE W.00.00.00   /* GMT */
```
The UTC upgrader is not supported on DB2 for z/OS.
Configure UTC using a fresh database install only.