Using the OracleAS 10.1.

2 Forms and Reports Builders with Oracle

Applications Release 12 [ID 444248.1]
Modified 02-AUG-2010 Type WHITE PAPER Status PUBLISHED

Using the OracleAS 10.1.2 Forms and Reports Builders with Oracle
Applications Release 12

Last revised: August 2, 2010 12:34 PM

See Change Record

The most current version of this document can be obtained in OracleMetaLink Note 444248.1. Ensure
that you have the most current version before you begin.

In This Document

• Section 1: Overview
• Section 2: Running the Forms Builder
• Section 3: Running the Reports Builder
• Section 4: Setting Up a Release 12 Environment with a Separate Developer Suite 10.1.2
Install
• Section 5: Compiling Forms
• Section 6: Compiling Reports
• Section 7: FAQ
• Section 8: Related Documentation
• Change Record

Section 1: Overview

The Forms and Reports objects shipped with Oracle Applications Release 12 are built using Forms
10.1.2 and Reports 10.1.2, both components of Oracle Application Server 10.1.2 (OracleAS 10.1.2).
By default, the standalone OracleAS 10.1.2 product does not include the builders, as it is designed to
provide a runtime deployment environment, not a development environment. OracleAS 10.1.2 only
includes the compilers and runtime, so customers wishing to develop their own Forms and Reports
would need to use OracleAS 10.1.2 Developer Suite (DS 10.1.2).

For Applications Release 12 customers, the OracleAS 10.1.2 Oracle home created by Rapid Install
includes the Forms and Reports builders, but only for Linux, Solaris and Windows. The builders were
included by Oracle Applications Development (with the support of the Application Server development
group) for the convenience of Applications customers, to help with support and maintenance of
Release 12 environments. Customers developing their own Forms and Reports applications, or
customizing, should still license the builders separately.

Developer Suite 10.1.2 is only available on Linux, Solaris and Windows. It was not possible to include
the builders in the Applications Release 12 Rapid Install for AIX, HP-UX and HP-Itanium platforms,
because they had never been ported to these platforms. Customers will need either a Windows,
Linux, or Solaris machine with DS 10.1.2 installed if they need to use the builders. Instructions are
given below.

In terms of UI and functionality, the 10.1.2 builders are very similar to the Developer 6i versions.
However, there are some architectural differences. The builders require the 1.4.2 version of the JDK
installed under the OracleAS 10.1.2 Oracle home, not the JDK used by Oracle Applications runtime.
Both builders now start up in-process JVMs, so it is important that $CLASSPATH,
$LD_LIBRARY_PATH, and so on are set correctly.
On UNIX/Linux platforms, always run the builders using the script provided, and not by running the
standalone executable: this way, you can be sure CLASSPATH and LD_LIBRARY_PATH will be set
correctly.

As for Developer 6i, the builders on Linux and Solaris are Motif executables, so require a valid X
server and display. They can be run from a properly configured X emulator.

To test that you will be able to run the builders, try running a standard X application such as xclock. If
you cannot do so successfully, you must resolve the issue before trying to run the builders.

Section 2: Running the Forms Builder

This section assumes you are running the builder on the Release 12 Application tier for either Linux,
Solaris or Windows.

Linux and Solaris

First, source the Oracle Applications generated OracleAS 10.1.2 environment file. The environment
file will be located under the 10.1.2 subdirectory of the Release 12 instance home. For example,
assuming Release 12 is installed under /slot01/appmgr, and the instance name is "txk123", source the
following file:

/slot01/appmgr/inst/apps/txk123/ora/10.1.2/txk123.env

The above could also be written as $ORACLE_CONFIG_HOME/txk123.env, or

$INST_TOP/ora/10.1.2/txk123.env. You can look up $ORACLE_CONFIG_HOME in the Help->About
Window of a Release 12 Forms session if you are not sure of the underlying directory structure. The
Forms Help->About Window displays settings for the OracleAS 10.1.2 Oracle home.

Second, modify the environment variable FORMS_PATH, so the referenced forms can be found.
Referenced forms are only required by the builder and compiler. The compiler merges in everything it
needs from the referenced form when it generates the .fmx, so the referenced forms are not used at
runtime; this is the reason they are not in the default FORMS_PATH.

FORMS_PATH=$FORMS_PATH:$AU_TOP/forms/US
export FORMS_PATH

This assumes you are working with the US English version of the form. For other languages, add the
appropriate language subdirectory to FORMS_PATH in place of US. The referenced objects will then
be in the correct language.

Launch the builder by running the following command:

frmbld.sh &

You must use the frmbld.sh script, under $ORACLE_HOME/bin. Do not run the executable
standalone. After sourcing the 10.1.2 environment file, $ORACLE_HOME should be set to
~/apps/tech_st/10.1.2, and $ORACLE_HOME/bin should be included in $PATH.

Be aware that Forms searches the current working directory ($PWD) for referenced forms and
libraries before FORMS_PATH. If you run the builder from your home directory, and have old copies
of fmb's and pll's saved there, these will be picked up instead.
Windows

On Windows, you need to set the appropriate variables in the registry. For the Applications Release
12 Forms runtime on Windows, the FORMS variables are set in the Applications startup script, rather
than the registry. Consequently, FORMS_PATH may not exist in the registry, or may exist with the
default DS 10.1.2 values. You will therefore have to set it appropriately if you want to use the builder,
by defining the relevant variables under the
HKEY_LOCAL_MACHINE/Software/Oracle/<AS10.1.2DevSuiteHome> registry key. (Even if
FORMS_PATH is not defined, you should see several other FORMS_* variables, plus
ORACLE_HOME, so you can identify the correct registry key.) Set FORMS_PATH to
<$AU_TOP>/resource;<$AU_TOP>/forms/US (where $AU_TOP is replaced with the full directory
path, and directories are separated with a semicolon).

In addition to FORMS_PATH, set the following variables in the registry. These are required to compile
Applications forms cleanly, when using either the builder or compiler.

EVENT_10932=8
DE_DISABLE_PLS_512=1
FORMS_FLAG_DIFFERENT_SUBORD=1

Failure to set the above variables will result in a large number of warnings relating to mirror items, or
errors such as the following on compiling some forms.

PL/SQL ERROR 512 at line 1140, column 55

Implementation Restriction: 'FND_API.G_MISS_CHAR': Cannot directly access remote
package variable or cursor

Launch the Forms builder from the Windows Start Menu:

Programs -> Oracle Developer Suite -> Forms Developer -> Forms Builder

You will not be able to run applications forms in the DS environment because you will not have the
Applications user-exits for that platform. User-exits are only required at runtime - the builder and
compiler do not verify that the user-exit call is valid, other than checking that the parameters passed
to the user-exit built-in are syntactically correct.

When you test a form, the Forms builder now launches the web runtime, as client-server is not
supported in Forms 10.1.2. Instructions for running Applications forms standalone are not provided:
this was never supported in the past with client-server, and many Applications forms will not work in a
standalone Forms session in any case.

Section 3: Running the Reports Builder

First, source the Applications-generated OracleAS 10.1.2 environment file, as described in the Forms
builder section above.

Next, unset the following environment variables which are required by Forms, but in some
circumstances can cause problems for Reports. Reset the variables before either running the Forms
builder or compiling forms manually.

unset EVENT_10932
unset DE_DISABLE_PLS_512

Open $ORACLE_HOME/bin/reports.sh in a text editor and comment out the following lines.
 TNS_ADMIN=$ORACLE_HOME/network/admin; export TNS_ADMIN
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1; export NLS_LANG

This modification is needed because these variables were set when the Applications OracleAS 10.1.2
environment was sourced, so must not be overwritten by the script. This problem will be fixed in
OracleAS 10.1.2.3, when the Reports script will be modified to set the variables only when not already
defined in the calling environment (as done for the frmbld.sh script).

Launch the builder by running the following script.

rwbuilder.sh &

On Windows, add or modify the Reports environment variables under the same registry key as for the
Forms builder, setting the variables listed in this section. Launch the Reports builder from the
Windows Start Menu.

Section 4: Setting Up a Release 12 Environment with a Separate

Developer Suite (DS) 10.1.2 Install

Forms

This section is for customers using AIX, HP-UX, and HP-Itanium who need to install Oracle DS 10.1.2
on either Solaris, Linux or Windows if they need to use the builders. It is also applicable to customers
who want to work with Applications forms on client PCs, rather than on the Release12 application tier.

First, source the Developer Suite 10.1.2 environment so variables such as ORACLE_HOME are set
correctly. You will also need to add your Applications database to tnsnames.ora, and ensure
$TNS_ADMIN is set correctly. Open the builder and confirm you can connect to the database. This is
all covered in the DS 10.1.2 install guide.

Move the attached libraries and referenced forms to the development machine

An attached library is a file containing shared client-side PL/SQL packages which is linked to the form
at design time. Most Oracle Applications forms have dozens of attached libraries - you can see the list
when you expand the attached library section in the navigator pane of the Form Builder.

A referenced form is a form containing shared forms objects that are referenced by other forms.
Referenced forms are read when the .fmb is opened in the builder or by the compiler. Note that
referenced objects are merged in when the runtime .fmx file is created, so referenced forms are not
needed at runtime.

The easiest way to move the attached libraries is to zip up (or tar) all the files in $AU_TOP/resource
that have a .pll suffix, extract them on the development machine, and add the directory to
FORMS_PATH (you do not need the .plx files from $AU_TOP/resource).

Next, copy the referenced forms from $AU_TOP/forms/US, and add the directory to FORMS_PATH.
Any form with a name ending in STAND.fmb (for example, APPSTAND.fmb, HRSTAND.fmb) is a
referenced form. The only way of finding any others is by opening the form you want to work on in the
builder, and check the error messages that tell you if a referenced form is missing.

It is generally preferable to move all the pll's in $AU_TOP/resource, but only the referenced .fmb's
(forms) that you actually need. This is because the average Applications form has numerous attached
libraries, often across many different products, but only a small number of referenced forms.
$AU_TOP/forms/US contains both referenced and non-referenced forms, with only a small minority
used as referenced forms. Moving all the .fmb's in $AU_TOP/forms/US will require much more space
than just the .pll's in $AU_TOP/resource, but this is a simpler strategy if disk space is plentiful.
An alternative to the above would be to utilize an NFS (or equivalent) disk shared by both the Release
12 application tier and the machine where DS 10.1.2 is installed. If you adopt thstrategy (mounting
$AU_TOP/resource and so on a shared way) it is advisable to do so read-only, or you may generate
.fmx or .plx files in the development environment that are incompatible with the runtime environment.

If you working in a language other than US English, replace $AU_TOP/forms/US with the appropriate
language subdirectory in the above instructions. The libraries do not contain any translated objects so
will work for all languages.

Next, set the following environment variables: these are required to compile Applications forms
cleanly, either using the builder or compiler.

EVENT_10932=8
export EVENT_10932

DE_DISABLE_PLS_512=1
export DE_DISABLE_PLS_512

FORMS_FLAG_DIFFERENT_SUBORD=1
export FORMS_FLAG_DIFFERENT_SUBORD

Failure to set the above variables will result in a large numbers of warnings relating to mirror items, or
errors such as the following when compiling some forms

PL/SQL ERROR 512 at line 1140, column 55

Implementation Restriction: 'FND_API.G_MISS_CHAR': Cannot directly access remote
package variable or cursor

Remember that environment variables (or rather, their equivalent) need to be set in the registry on
Windows.

The .fmb version of the form and .pll version of the library are platform-independent binary files, so
can be transferred between all supported platforms - remember, though, that they must be transferred
as binary files, otherwise they will be corrupted in the transfer. The generated .fmb and .plx files are
platform-specific.

All files should be generated in the final runtime environment before being run, even if the
development and runtime environments use the same platform.

Reports

Copy the reports and libraries over from your Release 12 file system to your development
environment. There are far fewer reports than forms, and only a small number of Reports PL/SQL
libraries.

1. Copy over the reports libraries from $AU_TOP/plsql, and add the directory to
$REPORTS_PATH.
2. Set the REPORTS_PATH to include the directory containing the Reports libraries.

Section 5: Compiling Forms

The compilers are shipped with both OracleAS 10.1.2 and DS 10.1.2, so are installed by the Release
12 Rapid Install on all platforms. If using a separate DS 10.1.2 environment to modify your forms,
follow these instructions to generate after transferring the modified object back to the Release 12
environment.
UNIX

There are two versions of the UNIX Forms compiler (often referred to as the Forms Generator):
frmcmp is the Motif version, and frmcmp_batch is the batch version. In the past, the Batch Generator
was often referred to as the Character Mode Generator. Both executables take identical parameters,
and generate identical output, but it is usually easier to use the Batch Generator, as it does not
require a display, and can be run from any telnet session (adadmin uses frmcmp_batch). With the
builder, it is simpler to use the scripts frmcmp.sh and frmcmp_batch.sh.

First, set up the environment OracleAS 10.1.2 environment as for the builder. The following examples
demonstrate use of the compiler. You will need to modify the directory paths to match your own
environment.

frmcmp_batch.sh module=/TEST/testappl/au/12.0/forms/US/ARXTWMAI.fmb
userid=APPS/APPS output_file=/TEST/testappl/ar/12.0/forms/US/ARXTWMAI.fmx
module_type=form compile_all=special

frmcmp_batch.sh module=/TEST/testappl/au/12.0/resource/APPCORE.pll userid=APPS/APPS

output_file=/TEST/testappl/au/12.0/resource/APPCORE.plx module_type=library
compile_all=special

Windows

On Windows, you can launch the Forms compiler from the Start Menu. The compiler displays an input
form UI where you can enter the parameters. You must have set the environment variables in the
Registry first, as described above in the Forms Builder section.

Alternatively, you can run the compiler from a command prompt (Start -> All Programs -> Accessories.
You can also set environment variables in the command prompt window, which will override any
registry settings for the current command prompt window instance. For example, you could run the
following

c:\TEMP>set FORMS_PATH=d:\AppsR12\au\12.0\forms\US;d:\AppsR12\au\12.0\resource

c:\TEMP>set EVENT_10932=8

c:\TEMP>set DE_DISABLE_PLS_512=1

c:\TEMP>set FORMS_FLAG_DIFFERENT_SUBORD=1

c:\TEMP>d:\iDS10.1.2\bin\frmcmp.exe module=d:\AppsR12\au\12.0\forms\US\ARXTWMAI.fmb
userid=APPS/APPS output_file=d:\AppsR12\ar\12.0\forms\US\ARXTWMAI.fmx module_type=form
compile_all=special

c:\TEMP>d:\iDS10.1.2\bin\frmcmp.exe module=d:\AppsR12\au\12.0\resource\APPCORE.pll
userid=APPS/APPS output_file=d:\AppsR12\au\12.0\resource\APPCORE.plx module_type=library
compile_all=special

Note that here is no separate "batch" compiler on Windows: as the window manager is always
running, there is no need for an executable that can run without a window manager.

Additional Comments

Refer to OracleMetaLink Note 191529.1 for sample scripts to automate the batch compilation of forms
and reports. Use the parameters documented above, as Note 191529.1 is not written for Oracle
Applications. You could also add the above commands to a batch (.bat) file on Windows or a shell
script (.sh) on UNIX, and run that from the command line.
Always generate Applications forms using compile_all=special, and not compile_all=yes.
compile_all=special is similar to compile_all=yes in recompiling all the PL/SQL in the form or library,
with the key difference that it does not update the source object.

Section 6: Compiling Reports

Set up the environment as for the builder. The Reports PL/SQL libraries stored under $AU_TOP/plsql
must be compiled with rwconverter: you will get compilation errors if you try to compile them with the
Forms compiler, because the SRW packages are not recognized.

The following examples demonstrate the use of the Reports converter. When the source and
destination types are the same, and compile_all=yes, the converter is simply being used to recompile
the object.

UNIX

rwconverter.sh userid=APPS/APPS source=$FND_TOP/reports/US/FNDATREP.rdf

stype=rdffile dtype=rdffile overwrite=yes batch=yes compile_all=yes

rwconverter.sh userid=APPS/APPS source=$FND_TOP/reports/US/FNDATREP.rdf

dest=/tmp/FNDATREP.rdf stype=rdffile dtype=rdffile overwrite=yes batch=yes
compile_all=yes

rwconverter.sh userid=apps/apps source=$AU_TOP/plsql/BISRPRT.pll stype=pllfile

dtype=pllfile overwrite=yes batch=yes compile_all=yes

rwconverter.sh userid=apps/apps source=$AU_TOP/plsql/BISRPRT.pll

dest=/tmp/BISRPRT.pll stype=pllfile dtype=pllfile overwrite=yes batch=yes
compile_all=yes

Windows

c:\TEMP>d:\iDS10.1.2\bin\rwconverter.exe userid=APPS/APPS
source=d:\AppsR12\fnd\12.0\reports\US\FNDATREP.rdf stype=rdffile dtype=rdffile
overwrite=yes batch=yes compile_all=yes

c:\TEMP>d:\iDS10.1.2\bin\rwconverter.exe userid=APPS/APPS
source=d:\AppsR12\fnd\12.0\reports\US\FNDATREP.rdf dest=c:\temp\FNDATREP.rdf
stype=rdffile dtype=rdffile overwrite=yes batch=yes compile_all=yes

c:\TEMP>d:\iDS10.1.2\bin\rwconverter.exe userid=apps/apps
source=d:\AppsR12\au\12.0\plsql\BISRPRT.pll stype=pllfile dtype=pllfile overwrite=yes
batch=yes compile_all=yes

c:\TEMP>d:\iDS10.1.2\bin\rwconverter.exe userid=apps/apps
source=d:\AppsR12\au\12.0\plsql/BISRPRT.pll dest=c:\temp\BISRPRT.pll stype=pllfile
dtype=pllfile overwrite=yes batch=yes compile_all=yes

Reports converter with above commands, can also be used to convert custom reports designed in
lower version of Reports Designer to current version in R12.

Section 7: FAQ

How do I patch a Developer Suite 10.1.2 environment?

OracleAS 10.1.2 patch sets are applicable to both OracleAS 10.1.2 and DS 10.1.2. The patch set
includes all OracleAS and DS components, but only updates the installed components (as listed in the
inventory). So, for example, when applied to a DS 10.1.2 home, it will not try to patch components that
only exist in an OracleAS 10.1.2 home. One-off type patches recommended for Applications
Customers may not always be applicable to to DS 10.1.2: if that is the case, however, opatch should
tell you the component is not installed.

You do not need to maintain the patch level of your DS 10.1.2 environment to be the same as that of
the Applications Release 12 OracleAS 10.1.2 home, for the following reason. Historically, it was
always safest to avoid moving a form from from a later patchset version to an earlier version. This
applied to both the source (.fmb) as well as the generated form (.fmx). In contrast, Forms 10.1.2
supports moving the .fmb to an earlier patchset version (but not to an earlier major release). However,
it is still advisable to avoid moving the .fmx to an earlier patchset: if such a need arises, we
recommend you move the .fmb and recompile. (We advise you to recompile in the runtime
environment anyway). And to complete this discussion, there is no problem moving to a later
patchset, where forms can be run without being regenerated.

Refer to OracleMetaLink Note 437878.1 for details of the latest AS 10.1.2 patchset certified for Oracle
Applications use. Note that Oracle Applications Development performs additional certification for the
DS 10.1.2 environments, over and above that done by Application Server Development.

Why compile forms with compile_all=special?

compile_all=special was originally introduced as a workaround for a bug that was fixed some time
ago. The main reason it is still recommended for Oracle Applications is due to the way attached
libraries are inherited from other attached libraries, and the difficulties in subsequently removing them
if added by mistake. For example, if a new library is attached to CUSTOM.pll, that library also
becomes directly attached to every form or library that has CUSTOM.pll attached, once the higher
level object has been re-compiled. With compile_all=yes, the new library would end up attached to
both the source and generated objects, and removing it would be extremely difficult: as well as
removing it from CUSTOM.pll, you would have to remove it from every library or form that had
CUSTOM.pll attached.

With compile_all=special, the source is not updated, and only the generated files (.plx and .fmx) have
the new library attached. In the case where someone has mistakenly attached a library to
CUSTOM.pll, (for example when they do not follow Oracle customization standards, and attach an
Applications product library), you simply need to delete it from CUSTOM.pll, regenerate all the forms
and libraries, and it will be gone. If you never customize, or if you follow the standards documented in
the Oracle Applications Developer's Guide, the use of compile_all=yes should never cause this kind of
problem, but we still recommend that you use compile_all=special.

If you open and save a form or library in the builder, it will inherit any new library attachments from its
sub-libraries in the same way as if it was generated with compile_all=yes.

Why do forms need to be recompiled in the runtime environment, even if they were developed
on the same platform?

When you generate a form or library with compile_all=yes or compile_all=special, it recompiles all the
client side PL/SQL. This is significant because it is at this time that calls to both client-side and server-
side packages (as well as to %type and %rowtype datatypes) are resolved. You are likely to
encounter problems unless you are certain that the specification of the client and server PL/SQL
packages and data objects are the same in the both the development and runtime environments. This
cannot be guaranteed unless both the environments are identical, with no additional patches applied.
In the long run, you will avoid problems by simply regenerating the form. (Note that with the three-tier
architecture, the "client" PL/SQL actually runs on the middle tier.)

Why do I get "FRM-18108: Failed to load the following objects"?

When trying to compile an applications form, the following (or similar) errors are seen, followed by
other compilation errors.
FRM-18108: Failed to load the following objects.
.
Source Module:INVSTAND
Source Object: INV_MVT_RECORD_GROUPS
Source Module:INVSTAND
Source Object: INV_ALERTS
Source Module:INVSTAND
Source Object: INV_PARAMS
Source Module:INVTTESR
Source Object: SERIAL_ENTRY
Source Module:INVTTELT
Source Object: INV_LOT_ENTRY
Source Module:APPSTAND
Source Object: STANDARD_FOLDER
Source Module:INVSTAND
Source Object: INV_STANDARD_PC
Source Module:APPSTAND
Source Object: STANDARD_PC_AND_VA
Source Module:APPSTAND
Source Object: STANDARD_TOOLBAR
Source Module:APPSTAND

The above errors occur when the referenced forms either cannot be found, or cannot be opened. In
the above example, the problem is with APPSTAND.fmb and INVSTAND.fmb. This will occur if
FORMS_PATH has not been modified, and $AU_TOP/forms/US has not been added as described
earlier.

If you have modified FORMS_PATH and still see the problem, check the following:

1. Make sure you have exported the environment variable FORMS_PATH: start a new shell and
confirm that the output from the command "echo $FORMS_PATH" still shows the new setting.
2. Confirm you have read permissions on the referenced forms, such as
$AU_TOP/forms/US/APPSTAND.fmb.
3. Check that you do not have any old versions in your current working directory, as these will
be picked up by Forms before it searches through the directories listed in FORMS_PATH.
4. Ensure you can open the referenced forms in the builder
5. If all else fails, use OS tracing (truss or strace as applicable) to determine why the referenced
forms cannot be found or opened.

Why is the builder picking up an old version of a referenced form or attached library instead of
the version under $AU_TOP?

Both the Forms builder and compiler search for referenced forms and attached libraries in the
following sequence:

1. Search directories listed in $ORACLE_PATH (this variable should be unset in an Oracle

Applications environment).
2. Search the current working directory ($PWD).
3. Search the directories listed in $FORMS_PATH.

If $ORACLE_PATH is set, or you have old versions of the referenced forms (.fmb) or libraries (.pll) in
the current working directory these will be loaded instead.

When running the builder on Linux, why do I see a lot of apparently random problems?

Oracle Applications Development experienced problems in their own internal Linux development
environments. In some case the property palette became corrupted and the item type changed in the
display. At other times, double-clicking a program unit to open it in the PL/SQL editor resulted in FRM-
11513: TRIGGER ALREADY SHOWN IN ANOTHER WINDOW errors.

This was fixed by removing "noexec=off" from the Linux kernel parameters. You can check whether it
is set by running the command "cat /proc/cmdline" and looking for the text "noexec=off".

Section 8: Related Documentation

• Note 437878.1 - Upgrading Forms and Reports 10g in Oracle Applications Release 12

Change Record

Date Description of Change

Aug 02,  Unsetting of EVENT_10932, DE_DISABLE_PLS_512 needed for all
2010 Reports builder Versions.
 Added under section 6 for converting custom 6i Reports/Reports
PL/SQL libraries to 10G.
Sep 03, Made some minor final updates and published document.
2007
Aug 23, Added related documentation section.
2007
Aug 13, Incorporated review recommendations and added Windows examples.
2007
July 23, Made editing pass in readiness for publication.
2007
July 10, Created document.
2007

Copyright © 2007 Oracle Corporation

Metalink Note 444248.1

Copyright © 2007 Oracle. All rights reserved. Oracle is a registered trademark of Oracle.
Various product and service names referenced herein may be trademarks of Oracle. All other
product and service names mentioned may be trademarks of their respective owners.

Disclaimer: This document is provided for information purposes only and the contents hereof
are subject to change without notice. Oracle does not warrant that this document is error-free,
nor does it provide any other warranties or conditions, whether expressed orally or implied in
law, including implied warranties and conditions of merchantability or fitness for a particular
purpose. Oracle specifically disclaims any liability with respect to this document and no
contractual obligations are formed either directly or indirectly by this document. This
document may not be reproduced or transmitted in any form or by any means, electronic or
mechanical, for any purpose, without the prior written permission of Oracle.