Copyright (c) 2023, Oracle. All rights reserved. Oracle Confidential.

Using the OracleAS 10.1.2 Forms and Reports Builders with Oracle Applications Release 12 (Doc ID
444248.1)

Using the OracleAS 10.1.2 Forms and Reports Builders with Oracle Applications Release 12
Last revised: June 12, 2012 2:05 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. Forms and Reports builders in 10G also are not supported
with UTF8 settings in Linux and Solaris. You may have to change NLS_LANG and LANG environment variables to non UTF8
characterset. Builders on Windows can be used if required to work with UTF8.

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.

Running Forms Builder with environment variable $LANG having any of UTF8 characterset may create problems . You should set env
variable $LANG without any characterset. For example 'export LANG=en_US' when echo of $LANG returned en_US.UTF-8. You can also
add below lines in a local copy of $ORACLE_HOME/bin/frmbld.sh that you can use to launch forms builder.
## Check LANG variable for UTF character set
if echo $LANG | /bin/grep -i '\.utf.*8' > /dev/null
then
export LANG=`echo $LANG | /bin/sed 's#\.[u|U][t|T][f|F].*8.*##'`
fi

After modifying it will look like

## Check LANG variable for UTF character set

if echo $LANG | /bin/grep -i '\.utf.*8' > /dev/null
then
export LANG=`echo $LANG | /bin/sed 's#\.[u|U][t|T][f|F].*8.*##'`
fi
$ORACLE_HOME/bin/frmbld $*

Launch the builder by running the following command:

frmbld.sh &

You must use the frmbld.sh script, under $ORACLE_HOME/bin. You can also make a copy of this frmbld.sh to use it, if there are some
changes that you want to run each time with frmbld.sh. 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.

Oracle Developer Suite 10g (10.1.2.0.2) (including Forms and Designer) Software can be obtained through media request from Oracle
Support. Patchset upgrades on such an install can be done using patches mentioned in Note 437878.1, although not mandatory.

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

You could 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
Note 459029.1 - How to configure, manage and secure user access to the Linux X server
Bug 13885805 - APPS6: PROPERTY PALETTE LOV TEXT GETS CLEARED ON R12.2 64BIT OS WITH MOUSE CLICK
Bug 2205994 - FRM-91111,FRM-10039 WHEN START FORMS BUILDER WITH NLS_LANG=JAPANESE_JAPAN.UTF8

Change Record

Date Description of Change

Jun 12, 2012 Added suggestions of bug 14178368
Jun 11, 2012 Corrected link for Install Guide in Section4.
Apr 04, 2012 Added lines to take care of limitation of Bug 13885805 as per bug 13919225.
Jan 03, 2012 Added a Note 459029.1 reference.
Aug 02, 2010 Unsetting of EVENT_10932, DE_DISABLE_PLS_512 needed for all Reports builder Versions.
Added under section 6 for converting custom 6i Reports/Reports PL/SQL libraries to 10G.
Sep 03, 2007 Made some minor final updates and published document.
Aug 23, 2007 Added related documentation section.
Aug 13, 2007 Incorporated review recommendations and added Windows examples.

July 23, 2007 Made editing pass in readiness for publication.

July 10, 2007 Created document.

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.

REFERENCES
BUG:2205994 - FRM-91111,FRM-10039 WHEN START FORMS BUILDER WITH NLS_LANG=JAPANESE_JAPAN.UTF8
NOTE:437878.1 - Upgrading OracleAS 10g Forms and Reports in Oracle E-Business Suite Release 12
NOTE:444248.1 - Using the OracleAS 10.1.2 Forms and Reports Builders with Oracle Applications Release 12
BUG:13885805 - APPS6: PROPERTY PALETTE LOV TEXT GETS CLEARED ON R12.2 64BIT OS WITH MOUSE CLICK
NOTE:459029.1 - How to configure, manage and secure user access to the Linux X server
Didn't find what you are looking for?