7
Configuring the OS/390 Working Environment

Oracle Connect for CICS includes a number of tuning parameters that can improve performance. Specifically, the daemon can be configured to optimize communication between the OS/390 machine and the client machine and the binding environment can be tuned to optimize the way actual requests are handled.

This chapter contains the following sections:

• Configuring the Daemon for High Availability

• Configuring a Binding Environment

Configuring the Daemon for High Availability

The daemon workspace is responsible for allocating server processes to clients. You can configure a workspace to use a pool of server processes so that a server process is always available for a client request. Use Oracle Studio to maintain daemon and daemon workspace parameters to control the allocation of server processes and their management in a pool.

You can also have a number of daemon workspace configurations. Thus, you can tailor individual workspaces for use with different adapters.

The workspace that will be used is specified in the delivery channel, as described in "Defining the Delivery Channel".

Task: Adding a New Daemon Workspace Configuration

Use Oracle Studio to add a new daemon configuration. You can set up different daemon configurations for different situations.

1. On the machine where Oracle Studio is installed, from the Start menu, choose Start > Programs > Oracle > Studio > Studio.

2. In the Configuration Explorer, click the + next to the machine defined in "Configuring Oracle Connect for CICS".

3. Click the + next to the Daemons node. The daemon configurations available on this machine are listed.

4. Right-click IRPCD and select New Workspace from the popup menu.

5. In the New daemon workspace window, specify a name the new workspace and optionally a description.

6. Specify whether you want it to have default settings or to copy the properties of an existing workspace.

   To copy the properties of an existing workspace, click the ellipsis button and select the workspace from which you want to copy the properties.

Once the workspace is defined the daemon editor is displayed, showing the WS Info tab.

Task: Editing the Workspace

You edit a workspace using the following tabs:

• WS Info - Specifies general information including the server type, the command procedure used to start the workspace, the binding configuration associated with this workspace and the timeout parameters.

• WS Server Mode - Specifies workspace server information including features that control the operation of the servers started up by the workspace and allocated to clients.

• WS Logging - Specifies parameters for logging and the format to use for a log file.

• WS Security - Specifies administration privileges, user access, ports available to access the workspace and workspace account specifications.

• WS Governing - For internal use.

Task: Configuring the Server Mode

The server mode dictates how the daemon starts up new processes. The daemon supports the following server modes:

Single Client - Each client receives a dedicated server process. The account in which a server process runs is determined either by the client login information or by the specific server workspace.

This mode enables servers to run under a particular user account and isolates clients from each other (since each receives its own process). However, this server mode incurs a high overhead due to process startup times and may use a lot of server resources (since it requires as many server processes as concurrent clients).

Multi-Client - Clients share a server process and are processed serially.

This mode has low overhead since the server processes are already initialized. However, because clients share the same process, they may impact one another, especially if they issue lengthy queries.

The number of clients that share a process is determined by the Clients per server limit (the maximum number of concurrent clients a server process for the current workspace accepts).

Reusable - This is an extension of the single client mode. Once the client processing finishes, the server process does not die and can be used by another client, reducing startup times and application startup overhead.

This mode does not have the high overhead of single client mode since the servers are already initialized. However, this server mode may use a lot of server resources (since it requires as many server processes as concurrent clients).

The other modes can be set so that the server processes are reusable by setting the number of times a process can be reused with the Reuse limit value (the maximum number of times a particular server process can be reused or how many clients it can serve before it is retired). Reuse of servers enhances performance since it eliminates the need to repeat initializations. However, reuse runs a risk of higher memory leakage over time. The default for the Reuse limit field value is None, indicating that no reuse limit is enforced.

Set the server mode in the WS Server tab of the daemon editor:

Text description of the illustration wsserver.gif

When using any of the server modes you can specify a pool of server processes. These server processes are started when the daemon starts and are maintained in a pool. The server processes are available for use by new client requests from the pool, saving initialization time. Instead of starting a new server process each time one is requested by a client, the client receives a process immediately from the pool of available processes. When the client finishes processing, this server process either dies, or if reusable servers have been specified, it is returned to the pool.

You set up a pool of server processes by specifying the following parameters in the WS Server tab.

Initial number of servers - The number of server processes that are prestarted for this workspace when the daemon starts up. These are available for use by new client processes with minimal initialization time. Instead of starting a new server process each time one is requested by a client, the daemon immediately allocates (to the client) a server from a pool of available servers. When the number of available server processes drops below the value specified in the Minimum number of available servers field, the daemon again starts server processes until the specified number of available servers is reached. The default for this parameter is 0, meaning that no servers are prestarted for this workspace.

Minimum number of available servers - The minimum number of server processes in the prestarted server's pool before the Oracle Connect daemon resumes creating new server processes (up to the number specified in the Initial number of servers field value, described above). If this parameter is set to a value greater than that of the Initial number of servers field value, the daemon considers the value to be the same as the value specified in the Initial number of servers field. In this case, a new server process is started and added to the pool each time a server process is removed from the pool and allocated to a client). The default for this parameter is 0, meaning that new servers are created only when there are no other available servers.

Set maximum number of servers - The maximum number of available server processes pooled for this workspace. If the server is reusable, once a client disconnects from the server, the daemon returns the server to the pool of available servers. If the limit is reached, excess server processes are discarded.

Number of sub-tasks - The number of sub-tasks for a server that are prestarted for this workspace when the daemon starts up. In addition to setting up a pool of server processes as described above, you can set additional server processes as sub-tasks by specifying this parameter. Thus, setting 10 servers and 10 prestarted sub-tasks results in 100 tasks started (10 sub-tasks for each process).

Configuring a Binding Environment

Each binding configuration includes the following:

• Environment settings, which are used to configure the environment used by any of the adapters defined in the binding

• Application adapters on the current machine

• Inbound queues for adapters on the OS/390 workstation machine. (Inbound queues are referred to as events in Oracle Studio)

Configuring data sources, adapters and inbound queues are described in Chapter 3, "Modeling Interactions for Oracle Application Server Integration Adapter for CICS". The following section describes the environment settings.

Task: Setting a Binding Environment

1. On the machine where Oracle Studio is installed, from the Start menu, choose Start > Programs > Oracle > Studio > Studio.

2. In the Configuration Explorer, click the + next to the machine defined in "Configuring Oracle Connect for CICS".

3. Click the + next to the Bindings node. The binding configurations available on this machine are listed.

4. Right-click NAV and select Edit Binding.

5. In the Properties tab edit the environment settings as needed.

To edit an environment setting, expand the property category and click the value to edit. The binding environment is divided into the following categories:

• comm Category

• debug Category

• miscellaneous Category

• odbc Category

• oledb Category

• optimizer Category

• queryProcessor Category

• transactions Category

• tuning Category

comm Category

The following parameters define communication buffers:

comCacheBufferSize - The size of a memory buffer on a client, which is used by the Oracle Connect client/server to store read-ahead data. The default is 200000 bytes.

comMaxSocketSize - The maximum bytes that can be written in one chunk on a socket. The default is -1 (no limitation).

comMaxXmlInMemory - The maximum size of an XML document held in memory. The default is 65535 bytes.

comMaxXmlSize - The maximum size of an XML document passed to another machine. The default is 65535 bytes.

debug Category

The following parameters define debugging and logging operations.

acxTrace - When set to "true", the input xml sent to the backend adapter and the output xml returned by the backend adapter, are written to the log.

analyzerQueryPlan - For internal use.

gdbTrace - For internal use.

generalTrace - When set to "true", logs general trace information. The default writes only error messages to the log.

logFile - The high-level qualifier of the log file for messages. The following types of message are written to the log:

• Error messages

• Trace information and information about the query optimization strategy if generalTrace is set to "true"

oledbTrace - For internal use.

optimizerTrace - For internal use.

queryWarnings - For internal use.

traceDir - For internal use.

miscellaneous Category

The following parameters define miscellaneous operations, including national language support (NLS) and the directory where temporary files are written.

codepage - For use with National Language Support (NLS) to identify the codepage for the workspace.

See Also: Appendix E, "National Language Settings"

cvtSeverityLevel - The data type conversion policy when a conversion error occurs:

• 0 (Default) - The data in the output column will be a null or empty value.

• 1 - The data in the output column will be a null or empty value and the error is reported to the log.

• 2 - An error is reported and processing stops.

edit - For internal use.

language - Identifies the application language. A default codepage is selected based om the value specified for this parameter.

See Also: Appendix E, "National Language Settings"

nlsString - Specifies the codepage used by a field whose data type is defined as "nlsString". You use this for a field whose codepage is other than that of the machine's codepage. This parameter includes the following values:

• The name of the codepage.

• Whether the character set reads from right to left (as in middle eastern character sets). The default is "false".

tempDir - The directory where temporary files are written, including the temporary files created for use by hash joins and for sorting files. The default is the current high-level qualifier.

year2000Policy - Determines the way 2-digit years are converted into 4-digit years. When the parameter year2000Policy is not set, or when it is set to a value outside the range of values defined for the policy, as described below, a default value of 5 and the Sliding Base Year policy is used. Two policies are provided:

Fixed Base Year - year2000Policy is set to a value greater than, or equal to 1900. In this case, the value of year2000Policy is the first 4-digit year after 1900 that can be represented by a 2-digit year. For example, if year2000Policy is set to 1905, the years 2000->2004 will be represented by 00->04. All other 2 digits will map to 19xx.

This solution is most appropriate if there is live data at the low end (close to the year 1900), which the user wants to keep with the current 2-digit format.

The user will probably change the base date only after ensuring that these old dates have been deleted from the data source.

Sliding Base Year - year2000Policy is set to a positive value less than 100. In this case, the value of year2000Policy represents the number of years ahead of the current year that can be represented by a 2-digit number. With each passing year the earliest year that can be represented by a 2-digit number changes to a year later.

odbc Category

The odbc parameters are for internal use.

oledb Category

The oledb parameters are for internal use.

optimizer Category

The optimizer parameters are for internal use.

queryProcessor Category

The queryProcessor parameters are for internal use.

transactions Category

The transactions parameters are for internal use.

tuning Category

The tuning parameters are for internal use.