There is a known issue where the standalone reports server can fail to start in OPMN. If this is the case, check in $ORACLE_INSTANCE/diagnostics/logs/ReportsServerComponent/$NAME_OF_REPORTS_SERVER/rwserver_diagnostic.log for the root cause of the error. If you see the following error appear and you are working with the DISPLAY environment variable if set in your environment:

[REP-56105] [oracle.reports.server] [tid: 11]
[ecid: ###################] EngineManager:manage
Engine rwEng-0 died with error: {1}.REP-0004: User preference file
cannot be opened.[[
REP-0004: User preference file cannot be opened.

You may need to have the REPORTS_DEFAULT_DISPLAY variable set to YES inside of reports.sh.  Normally it is set to YES, but in case it is set to NO, you may follow these steps to fix the problem:

1. Go to $ORACLE_INSTANCE/config/reports/bin

2. Make a backup of reports.sh

3. Open up reports.sh in a text editor.

image

4. Scroll down to near the end of the file until you see the variable REPORTS_DEFAULT_DISPLAY. Change the value from NO to YES.image

5. Save and close the file6. Restart WLS_REPORTS

After applying the steps above, you should be able to successfully start up the standalone reports server.

NOTE: This will also work if you experience the same issue with the in-process reports server.

Source: Oracle Support note 1421439.1

By default, when Oracle WebLogic Server uses HTTPS for secure connections such as for Forms and Reports, SSL (Secure Socket Layer) v3.0 and TLS (Transport Layer Security) v1.0 are configured. SSL is the original protocol used for secure connections via HTTPS where TLS is the newer, more secure protocol. In recent months, a security vulnerability known as Poodle, “Paddling Oracle On Downgraded Legacy Encryption”, was discovered to be. In summary, Poodle is a “man-in-the-middle” exploit which can allow hackers to view encrypted information. More information on Poodle can be found on Oracle’s website: http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html

The vulnerability exists with SSL v3.0, which is commonly used as the secure protocol used for HTTPS connections with using Oracle WebLogic Server. However, the TLS protocol does not contain this vulnerability. If WebLogic is configured for both (it is by default) and the end-user’s Web browser has SSL v3.0 and TLS v1.0 both enabled, there is a possibility that the WebLogic connection via HTTPS may be done using SSL v3.0 instead of TLS v1.0. A WebLogic connection is defined by any connection going to an application (JSP, Forms & Reports, ADF, Discoverer, etc.) which is deployed in Oracle WebLogic Server.

The best approach is to configure WebLogic to only use TLS v1.0. With this, all end-users will be forced to use TLS 1.0 on all HTTPS connections to the WebLogic server whether it is used for running deployed JSP applications, Oracle Forms and Reports applications, Oracle ADF applications, or other Oracle Fusion Middleware applications. The changes are quick and easy to deploy. Also, no new SSL/TLS certificates will need to be created. Implementing TLS v1.0 only for WebLogic can be done with these steps:

1. Log into the WebLogic Administration Console (Example: http://server.domain:7001/console)

2. Log in with the weblogic username and password

3. Go to Environment –> Servers

image

4. Select a WebLogic server where SSL has been set up. We’ll use WLS_FORMS as an example.

image

5. In the top-left corner, click “Lock & Edit”.

image

6. Make sure the Configuration tab is enabled. Select the “Server Start” sub-tab.

image

7. In the Arguments section, type in the following parameter:

-Dweblogic.security.SSL.protocolVersion=TLS1

NOTE: This will force the WebLogic server to use TLS instead of SSL.

When finished, click the “Save” button.

image

8. For any other WebLogic servers using SSL/TLS, repeat steps 4-7 (except for step 5 as you will be in “Lock & Edit” mode already).

9. In the top-left corner, click “Activate Changes” to apply all changes.

image

10. If any WebLogic servers which had the changes applied are currently running, they will need to be restarted using the Admin Console. If this includes the AdminServer, you will need to use WLST to start up the AdminServer as you will not be able to use the Admin Console if the AdminServer is down.

Now that WebLogic is configured for TLS v1.0, all end users will need to make sure that TLS 1.0 is enabled in their Web browsers:Internet Explorer:NOTE: It is likely that TLS 1.0 is enabled in Internet Explorer, but it is recommended to check anyway.Go to Tools –> Internet Options (or simply Internet Options from the menu in the top-right corner)In the Advanced tab, scroll down to the Security section. Make sure “Use TLS 1.0” is enabled.

SNAGHTMLaf2c8f

Mozilla Firefox and Google Chrome:All current releases of Firefox and Chrome have at least TLS 1.0 already enabled.After applying the steps above, you should be using TLS when running anything on the WebLogic server (JSP applications, ADF applications, Forms, etc.) using the HTTPS protocol.

Source: Oracle Support note 1936300.1

By default, when Oracle HTTP Server (OHS) 11g uses HTTPS for secure connections such as for Forms and Reports, SSL (Secure Socket Layer) v3.0 and TLS (Transport Layer Security) v1.0 are configured. SSL is the original protocol used for secure connections via HTTPS where TLS is the newer, more secure protocol. In recent months, a security vulnerability known as Poodle, “Paddling Oracle On Downgraded Legacy Encryption”, was discovered to be. In summary, Poodle is a “man-in-the-middle” exploit which can allow hackers to view encrypted information. More information on Poodle can be found on Oracle’s website: http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html

The vulnerability exists with SSL v3.0, which is commonly used as the secure protocol used for HTTPS connections with using OHS. However, the TLS protocol does not contain this vulnerability. If OHS is configured for both (it is by default) and the end-user’s Web browser has SSL v3.0 and TLS v1.0 both enabled, there is a possibility that the OHS connection via HTTPS may be done using SSL v3.0 instead of TLS v1.0.

The best approach is to configure OHS to only use TLS v1.0. With this, all end-users will be forced to use TLS 1.0 on all HTTPS connections to that OHS environment whether it is used for running deployed Web applications, Oracle Forms and Reports applications (whether using the embedded OHS server which comes with Oracle Forms and Reports or using a WebGate for organizations using OAM for SSO), Oracle Discoverer, or other Oracle Fusion Middleware applications. The changes are quick and easy to deploy requiring minimal downtime (only minutes). Also, no new SSL/TLS certificates will need to be created. Implementing TLS v1.0 only for OHS 11g can be done with these steps:

1. Go to %ORACLE_INSTANCE%\config\OHS\ohs1 ($ORACLE_INSTANCE/config/OHS/ohs1 in Unix environments)

2. Make a backup of ssl.conf

SNAGHTMLa8ef22

3. Open up ssl.conf in a text editor

4. Locate the SSLProtocol parameter. Notice that it reads: SSLProtocol nzos_Version_1_0 nzos_Version_3_0

image

5. Comment out this line and add the following entry in the next line below:

SSLProtocol nzos_Version_1_0

NOTE: This is the parameter to specify only TLS v1.0

image

6. Save and close the file

7. Restart OHS using either OPMN or Enterprise Manager

Examples:

Windows: %ORACLE_INSTANCE%\bin\opmnctl restartproc ias-component=ohs1

Unix: $ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs1

Now that the OHS server is configured for TLS v1.0, all end users will need to make sure that TLS 1.0 is enabled in their Web browsers:

Internet Explorer:

NOTE: It is likely that TLS 1.0 is enabled in Internet Explorer, but it is recommended to check anyway.

Go to Tools –> Internet Options (or simply Internet Options from the menu in the top-right corner)

In the Advanced tab, scroll down to the Security section. Make sure “Use TLS 1.0” is enabled.

SNAGHTMLaf2c8f

Mozilla Firefox and Google Chrome:

All current releases of Firefox and Chrome have at least TLS 1.0 already enabled.

 

After applying the steps above, you should be using TLS when running anything on the OHS server (Web pages, Forms, etc.) using the HTTPS protocol.

NOTE: OHS 11g (e.g. 11.1.1.7.0) is currently only supported to use TLS 1.0. Only OHS 12c (12.1.x) can use TLS 1.1 or higher which is currently not usable for Oracle Forms and Reports 11gR2.

Source: Oracle Support note 1936300.1

Starting with Oracle Forms and Reports 11.1.2.2.0, the latest version of Oracle Forms available, support with Java Runtime 8 update 5 or higher has been added per the Oracle Forms 11.1.2.2.0 certification matrix (More information can be found in the Client tab in the certification matrix) http://www.oracle.com/technetwork/es/middleware/docs/oracle-forms-111220certmatrix-2087910.xls?ssSourceSiteId=otnen.

However, if your Forms application is using SSL (https), you may encounter the following error in your Java Console:

network: Connecting https://server.domain/forms/java/icons.jar with proxy=DIRECT

javax.net.ssl.SSLException: Received fatal alert: close_notify

network: Connecting http://server.domain:443/ with proxy=DIRECT

                at sun.security.ssl.Alerts.getSSLException(Unknown Source)

                at sun.security.ssl.Alerts.getSSLException(Unknown Source)

The Forms application will no longer work. According to the “Security Enhancements” page in the JRE 8 documentation http://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html, the TLS 1.1 and TLS 1.2 options were enabled in the Java Control Panel found on every client PC which connects to the Oracle Forms application. Previously in JRE 6 and 7, these options were either disabled or not present; however, it was enabled in JRE 8.

To fix the problem, in the client PC, you will need to perform these steps:

1. Open up the Java Control Panel (can be found in the Windows Control Panel under “All Control Panel Items”.

2. Click the “Advanced” tab and expand the “General” section.

3. You will see that “Use TLS 1.1” and “Use TLS 1.2” are selected. Unselect both checkboxes and click “OK”.

4. Close out of all browser windows and relaunch the application.

 

After completing the steps above, you should be able to run your Forms application using JRE 8.

Source: Oracle Support note 1675195.1

Normally in Enterprise Manager for Forms, you are able to associate and disassociate your Oracle Forms environment to/from OID. However, if OID is no longer there like in a situation where OID was deinstalled, you will be presented with the following error when you try to disassociate Forms from the old OID environment (such as if you are trying to associate Forms with the new environment):

“FRM-60205: error removing the Forms J2EE application formsappf9c-9652-30540462a11e footprint from OID host”

You can disassociate the old OID environment from Forms by performing these steps:

1. Shutdown all WebLogic servers in the Forms domain.

2. Navigate to the DOMAIN_HOME of your Forms domain.

3. You will need to edit the file FormsOIDConfig.xml in two locations. Make backups of these files:

a. $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2/config/FormsOIDConfig.xml

b. $DOMAIN_HOME/servers/WLS_FORMS/tmp/_WL_user/formsapp_11.1.2/<random_string>/config/FormsOIDConfig.xml

4. Open the file in each location using a text editor.

5. Remove all entries in the file until you have the following:

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no”?>
<!DOCTYPE properties SYSTEM “http://java.sun.com/dtd/properties.dtd”>
<properties>
</properties>

6. Save and close the file.

7. Repeat steps 4-6 for the other file. NOTE: For the second location, it may already appear as it should in step 5.

8. Start up the WebLogic environment for Forms.

9. In EM, the old OID environment should no longer appear. You may proceed with associating Forms with a new OID environment.

 

Source: Oracle Support note 1130053.1

In order to run your Oracle Forms application utilizing the WebUtil functionality, the Forms and Reports environment must be properly set up:

1. You must use the webutil.olb and webutil.pll that came with the Forms install. You should NOT copy any versions from other platforms. For example, if you are deploying your application in Linux after developing some forms in Windows, you should not copy any WebUtil library from Windows to Linux (or vice-versa). Basically, make sure the webutil.pll you compiled is one that came with the Forms installation. Otherwise, you may encounter strange issues such as FRM-40735/ORA-06502 or ORA-06508.

2. Make sure that the WebUtil libraries (olb, pll, and plx) are not in more than one location in the FORMS_PATH.

3. Inside formsweb.cfg in each application section(s), it/they will need to at least have:

baseHTMLjpi=webutiljpi.htm
baseHTML=webutilbase.htm
WebUtilArchive=frmwebutil.jar, jacob.jar
WebUtilLogging=off
WebUtilLoggingDetail=normal
WebUtilErrorMode=Alert
WebUtilDispatchMonitorInterval=5
WebUtilTrustInternal=true
WebUtilMaxTransferSize=16384

4. In $ORACLE_HOME/forms/webutil/win32, the file jacob-1.14.3-x86.dll needs to be present

5. In $ORACLE_HOME/forms/webutil/win64, the file jacob-1.14.3-x64.dll needs to be present

6. In $ORACLE_HOME/forms/java, jacob.jar must be present there. If you are using Java Runtime Environment (JRE) 7u51 or higher, it will need to be signed with trusted code-signing certificates or your application may get blocked when running in the web browser.

7. Make sure that a public synonym WEBUTIL_DB has been created in your Oracle Database and is granted on execute to public (GRANT EXECUTE ON WEBUTIL_DB TO PUBLIC;)

8. Make sure in $ORACLE_INSTANCE/config/FormsComponent/forms/server/webutil.cfg that the following parameters are set to what they are below (these parameters are found close to the very bottom of the file):

transfer.database.enabled=TRUE
transfer.appsrv.enabled=TRUE
transfer.appsrv.workAreaRoot=
transfer.appsrv.accessControl=FALSE

That should be everything that is required in the environment for WebUtil to work in Forms.

Source: Oracle Support note 1093985.1 (How to Configure Webutil in Forms 11g)

By default in every Oracle Forms and Reports 11g (and 11gR2) deployment, the application(s) look for the TNS connection details inside the tnsnames.ora file located in %ORACLE_INSTANCE%\config ($ORACLE_INSTANCE/config in Unix). An example location could be C:\Oracle\Middleware\asinst_1\config. If you need to deploy the tnsnames.ora in a separate location such as a network drive or in the same location as your Oracle database (only if one is installed in the same environment as WebLogic), you will need to follow these steps to configure this deployment:

System Environment Variables

For Windows:

1. Go to your Computer Properties (Right-click on Computer and select Properties)

2. Select “Advanced system settings”

3. Select “Environment Variables…”

4. If not set already, create a new System Environment variable called TNS_ADMIN. For the value, please specify the directory you wish to deploy tnsnames.ora. NOTE: If the directory is in a network drive, please map the network drive to a disk drive such as S:\ for example.

5. Click OK three times to save the changes.

For Linux/Unix:

1. Go to $HOME and open up .bash_profile in a text editor

2. If not present already, create a new environment variable called TNS_ADMIN. For the value, please specify the directory you wish to deploy tnsnames.ora. NOTE: Make sure you export this environment variable.

3. Save and close the file.

4. To start using the new variable, close your terminal (SSH) window and start a new terminal window.

Forms

1. Navigate to %DOMAIN_HOME%\config\fmwconfig\servers\WLS_FORMS\applications\formsapp_11.1.2\config ($DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2/config in Unix) and open up any environment files (.env) you are using for your application.

2. Look for the environment variable TNS_ADMIN. For the value, please specify the directory you wish to deploy tnsnames.ora.

3. Save and close the file.

NOTE: You do NOT need to restart the WLS_FORMS WebLogic server.

Reports

IMPORTANT: Before running steps 5-7, make sure nobody is logged into the Forms and Reports application(s).

1. Navigate to %ORACLE_INSTANCE%\config\OPMN\opmn ($ORACLE_INSTANCE/config/OPMN/opmn in Unix) and open up opmn.xml (NOTE: Please make a backup first.)

2. Look for the environment variable TNS_ADMIN. For the value, please specify the directory you wish to deploy tnsnames.ora.

3. Save and close the file.

4. Open up Command Prompt and navigate to %ORACLE_INSTANCE%\bin ($ORACLE_INSTANCE/bin in Unix).

5. Reload OPMN: opmnctl reload

6. Stop OPMN: opmnctl stopall

7. Start OPMN: opmnctl startall

 

To test, remove (but do not delete) the tnsnames.ora from %ORACLE_INSTANCE%\config ($ORACLE_INSTANCE/config). Try running a form and report from your application(s) to make sure that you do not get any TNS errors. If your application runs successfully, the above configurations have been applied successfully.

Configuring JVM Controllers for  generating PDF reports from Oracle Forms is definitely recommended for optimizing system resources. However, if you are trying to generate PDF reports when using the WebUtil functionality, the WebUtil jar file (signed and provided by Oracle with every 11g installation) needs to be in the classpath of the JVM controller. Otherwise, you will encounter the following error in the Java Console:

WUT-134 [WEBUTIL_CORE.checkJava] frmwebutil.jar not in the application server Classpath

To fix this error, you can configure the following:

  1. Go to $ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm
  2. Make a backup of jvmcontrollers.cfg
  3. Open up jvmcontrollers.cfg using a text editor
  4. Add the full path to frmwebutil.jar to the classpath variable. The classpath should look similar to the following:
    1. Windows example: classpath=%ORACLE_HOME%\jlib\zrclient.jar;%ORACLE_HOME%\reports\jlib\rwrun.jar;%ORACLE_HOME%\forms\java\frmwebutil.jar
    2. Unix example: classpath=$ORACLE_HOME/jlib/zrclient.jar:$ORACLE_HOME/reports/jlib/rwrun.jar:$ORACLE_HOME/forms/java/frmwebutil.jar
    3. NOTE: Please type out the entire path of $ORACLE_HOME.
  5. Save and close the file
  6. Restart the JVM controller

After applying the steps above, you should have no problem using WebUtil when generating reports from the Oracle Forms application using WebUtil.

Source: Oracle Support note 1529264.1

ORACLE FORMS & REPORTS 11.1.2.2 INFORMATION AND FINDINGS

UPDATED: June 3, 2014

INTRODUCTION

Oracle has just recently released an updated version of Oracle Forms 11gR2 versioned as 11.1.2.2. For what we have seen on Oracle’s website and Oracle Support, the following has been updated in the latest version of Oracle Forms 11gR2 (11.1.2.2):

·         Many bugs have been fixed (See Oracle Support ID 1612530.1 for a list of the bugs fixed)

·         Only Oracle WebLogic Server (WLS) 10.3.6 is supported

·       The operating system support is the same as 11.1.2.1 except for the following:

o   AIX 6.1 must be Update Level 7 or higher

o   AIX 7.1 must be Update Level 1 or higher

o   Windows XP is no longer supported with Forms 11.1.2.2

o   NOTE: Currently no support for Oracle Forms (any release) with Windows 8

·       JDK support:

o Using Java 6 – JDK 1.6.0_35+

o Using Java 7 – JDK 1.7.0_40+

·         Internet Browser support:

o   Internet Explorer: 8, 9, 10, 11 (IE 11 is only supported if Oracle Patch 18277370 is applied)

o   Firefox: 24+

o   Google Chrome: 29+

o   Safari: 5.x

·         Database support (No changes from Forms 11.1.2.1):

o   10.2.0.4+

o   11.1.0.7+

o   11.2.0.1+

o   12.1.0.1+

·          OAM support (No changes from Forms 11.1.2.1):

o   Oracle SSO 10gR3 (10.1.4.3+)

o   Oracle Access Management 11gR1 (11.1.1.5+)

o   Oracle Access Management 11gR2 (11.1.2.0.0)

o   Oracle Internet Directory (OID) 11gR1 (11.1.1.5+)

o   Oracle Virtual Directory (OVD) 11gR1 (11.1.1.5+)

·          This version is released as both a base installation and a patchset (Oracle patch 17882900) installation meaning that Oracle Forms 11.1.2.2 can either be installed as a separate installation or as a patch to an existing 11.1.2.0 or 11.1.2.1 installation.

·          On the Oracle Forms download page, there are no more downloads for Forms 11.1.2.0 or 11.1.2.1. Only Forms 11.1.2.2 can be downloaded from OTN.

For more information regarding Oracle Forms 11.1.2.2 certifications, please review Oracle’s certification matrix for Forms and Reports 11.1.2.2: http://www.oracle.com/technetwork/es/middleware/docs/oracle-forms-111220certmatrix-2087910.xls?ssSourceSiteId=otnen

SIMILARITIES/DIFFERENCES TO FORMS 11.1.2.1

After successfully installed and configured Oracle Forms & Reports 11.1.2.2 in both our Windows 7 64-bit and Oracle Linux 6.4 64-bit test environments, we found that there are no major functionality changes that we could detect. In our test installations, we worked with Oracle WebLogic Server 10.3.6 using JDK 1.7.0_45 (this was the latest JDK available for download as of January 8, 2014 when the test installs were performed). Based off the installation and configuration, we have noticed the following:

1.       The installation of Oracle Forms and Reports 11.1.2.2 (as well as running config.bat/sh) is identical to installing 11.1.2.1. The same steps are involved.

2.       Environment files and formsweb.cfg work the same. In order to use the latest JRE (since we were using JDK 7 in our test), we had to configure the jpi parameters in formsweb.cfg.

3.       Similar to Forms and Reports 11.1.2.1, we still receive the “REP-52262: Diagnostic output is disablederror when we try to run reports. In previous releases of Oracle Forms & Reports 11gR1 and 11gR2 (11.1.2.0), using the default setting in rwservlet.properties would allow anyone to access anything related to rwservlet such as getjobid, showjobs, showenv, etc. For some reason in 11.1.2.1 and 11.1.2.2, the default settings act the same as using <webcommandaccess>L0</webcommandaccess> in the file. To fix this, we had to manually add the parameter <webcommandaccess>L2</webcommandaccess> into rwservlet.properties and restart WLS_REPORTS before we could view generated reports. NOTE: If this was fixed manually in Forms 11.1.2.1 and you patch the install to 11.1.2.2, you do not have to redo this. URL: https://pitss.com/us/2012/12/20/running-reports-in-formsreports-11-1-2-1-generates-rep-52262-with-default-settings/

4.       Patching your Forms 11.1.2.1 installation to 11.1.2.2 requires little effort. All that is required is to shut down all WebLogic servers associated with Forms 11.1.2.1, OPMN, and Node Manager. Running the patchset install and starting everything up afterward is all that is required.

a.       NOTE: When running the installer, make sure to select “Install Software – Do Not Configure”.

b.      NOTE: If you have an Oracle Database installed on the same PC/server where you are upgrading Forms and Reports, the database, TNS listener, and DB Console will need to be shut down as well in order to prevent a possible error during the upgrade.

5.       The OHS bug which occurred in many Oracle Forms 11.1.2.0 installations that was fixed in 11.1.2.1 is also fixed in 11.1.2.2. The bug was the case where you had to rollback and re-apply an Oracle patch to fix an issue where OHS would lose connectivity with the WLS_FORMS server after a report was run. URL: https://pitss.com/us/2012/10/08/how-to-fix-apache-bridge-error-bug-in-forms-11gr2/

6.       The Reports Builder bug where it crashes when viewing the Data Model in 64-bit machines has NOT been fixed with Forms and Reports 11.1.2.2. Fortunately, applying the fix as mentioned in https://pitss.com/us/2012/10/10/reports-builder-11gr2-crashes-when-viewing-data-model/ will still fix the problem. NOTE: If this was fixed manually in Forms 11.1.2.1 and you patch the install to 11.1.2.2, you do not have to redo this.

7.       Oracle Forms & Reports 11.1.2.2 is backwards-compatible with Oracle Forms & Reports 11.1.2.1. We tested this by successfully opening up or loading a form in either an 11.1.2.1 Forms Builder or PITSS.CON saved in either Forms Builder or PITSS.CON using Forms 11.1.2.2. This means that if you are working with someone who is using Oracle Forms 11.1.2.2, you are able to use your PITSS.CON or Forms Builder using Forms 11.1.2.1 without any problems. NOTE: Forms 11.1.2.2 is not backwards-compatible with Forms 11gR1.

8.       In Oracle Forms 11.1.1.6, 11.1.2.0, and 11.1.2.1, there was a bug where you were unable to edit any configuration files or logging information for OHS within Enterprise Manager as mentioned in https://pitss.com/us/2013/10/18/unable-to-edit-ohs-configuration-files-in-enterprise-manager-for-forms-11-1-1-6-or-11gr2/. This bug has been fixed in Forms 11.1.2.2 (as well as 11.1.1.7 if you are using Forms 11gR1).

9.       All Oracle jar files (frmall.jar, frmwebutil.jar, and any other jar file which starts with “frm”) have been updated with the permissions and codebase manifest attributes needed for the later Java JDK and JRE updates. Before you decide to upgrade your JDK and JRE to the latest version (Java 7u45 or higher) in your Forms and Reports 11.1.2.0 and 11.1.2.1 environment, it is best to upgrade to Forms and Reports 11.1.2.2 first (and WebLogic 10.3.6 if you are using 10.3.5). For any custom jar files used in Forms and Reports, they will still need to contain the permissions and codebase manifest attributes (and signed with trusted certificates). Please see https://pitss.com/us/2013/10/24/how-to-modify-custom-jar-files-with-permissions-and-codebase-attributes/ for more information.

10.   Like earlier releases of Oracle Forms and Reports 11gR2 (11.1.2.0 and 11.1.2.1), WebUtil for Forms 11.1.2.2 uses Jacob 1.14.3. No changes to the Jacob DLLs are required.

11.   If you have Forms and Reports integrated with Oracle Access Manager (OAM) 11g, no changes are required on the OAM or OID side. Simply upgrading Forms from 11.1.2.1 (or 11.1.2.0) to 11.1.2.2 is all that is needed to log into your Forms application using OAM.

12.   When configuring Oracle Forms and Reports 11.1.2.2 (using config.bat or config.sh) and you are integrating with OAM, you will still get an error when connecting to the OAM domain even if all information is entered correctly. This bug that was first seen in Forms 11.1.2.1 and 11.1.1.7 has NOT been fixed in 11.1.2.2. You will need to run config.bat or config.sh using the –novalidation flag to work around this error. NOTE: Be very careful when running the configuration wizard if you use the –novalidation flag as the wizard will NOT perform any tests or checks to see if anything entered is valid or invalid. More information can be found at https://pitss.com/us/2013/04/12/forms-and-reports-11gr2-configuration-fails-at-access-control-step-with-oam-2/.

 

Other than what we mentioned above, we did not notice any other major differences. We also setup a test PITSS.CON 12.2.2 environment to run in Oracle Forms & Reports 11.1.2.2. The newest PITSS.CON version, 12.2.2 (as of January 8, 2014), works well with Forms 11.1.2.2. Everything works the same as it did in Oracle Forms 11.1.2.1.

Oracle WebLogic and Forms 11g Setup Prerequisites for IBM-AIX on POWER Systems

 

1.     Minimum System Requirements

1.1.    Supported Operating Systems:

1.1.1. IBM AIX 5.3 UL8+

1.1.2. IBM AIX 6.1 UL7+

1.1.3. IBM AIX 7.1 UL1+

1.2.    RAM: 8GB+

1.3.    HDD Partitioning:

*Software Mount: One file system mount with at least 50GB of free space to store the software and temporary file storage for servers.

TEMPFS Space: 4GB+ (Minimum: 1GB+)

*SWAP: 8GB+

1.4.    OS User Access Requirements:

1.4.1. OS User will need to own the software mount.

1.4.2. Root user access must be accessible for the installation.

*RAM and File System Mount Specifications: For production systems, please consult PITSS or Oracle on sizing recommendations. The amount of RAM, HDD Space for SWAP and Software Mounts will vary depending on end-user usage and application characteristics. If you will be running reports heavily, use at least 20GB of SWAP.

2.     Other AIX OS Requirements

2.1.    Open File Limits:

“soft nofile” should be atleast 4096
“hard nofile” should be atleast 4096 (65535 is recommended)

3.     Required Packages

3.1.1.  IBM AIX 5.3 64-bit

The minimum versions of the packages below will need to be installed before the Forms 11g installation can begin:

 

 

Package Name

bos.adt.base

bos.adt.lib

bos.adt.libm

bos.perf.libperfstat

bos.perf.perfstat

bos.perf.proctools

rsct.basic.rte

rsct.compat.clients.rte

bos.mp64 (version 5.3.0.56)

bos.rte.libc (version 5.3.0.55)

xlC.aix50.rte (version 8.0.0.7)

xlC.rte (version 8.0.0.7)

X11.motif.lib (version 2.1.30)

gpfs.base (version 3.2.1.8) (Only if using Oracle RAC)

 

3.1.2.  IBM AIX 6.1 64-bit

The minimum versions of the packages below will need to be installed before the Forms 11g installation can begin:

 

Package Name

bos.adt.base

bos.adt.lib

bos.adt.libm

bos.perf.libperfstat

bos.perf.perfstat

bos.perf.proctools

rsct.basic.rte

rsct.compat.clients.rte

xlC.aix50.rte (version 11.1.0.4)

xlC.rte (version 11.1.0.4)

X11.motif.lib (version 2.1.30)

gpfs.base (version 3.2.1.8) (Only if using Oracle RAC)

 

For more information from Oracle on required packages please go to: http://download.oracle.com/docs/html/E18558_01/fusion_requirements.htm#BABIDAAA

 

3.1.3.  IBM AIX 7.1 64-bit

The minimum versions of the packages below will need to be installed before the Discoverer 11g installation can begin:

Package Name

bos.adt.base

bos.adt.lib

bos.adt.libm

bos.perf.libperfstat

bos.perf.perfstat

bos.perf.proctools

rsct.basic.rte

rsct.compat.clients.rte

xlC.aix50.rte (version 10.1.0.0)

xlC.rte (version 10.1.0.0)

IZ89165 (Only if using Oracle BI)

For more information from Oracle on required packages please go to: http://download.oracle.com/docs/html/E18558_01/fusion_requirements.htm#BABIDAAA

 

4.     Database Requirements

4.1.    Supported Database Versions:

10.2.0.4+

11.1.0.7+

11.2.0.1+

12.1.0.1+

4.2.    A database user with DBA/SYS privileges accessible.

4.3.    The file tnsnames.ora containing the SID of the database will need to be placed in the server/client in the same location as the other prerequisites.

 

5.     Software Requirements

5.1.    IBM JDK 7 (SR3 or higher)

5.2.    Webutil and JACOB

5.2.1. Please contact PITSS at 248-740-0935 or support@pitssamerica.com for download instructions.

 

5.3.    For an 11g Forms installation you will need to download the following software:

5.3.1. WebLogic 10.3.6

5.3.1.1.              Can be downloaded from: http://www.oracle.com/technetwork/middleware/ias/downloads/wls-main-097127.html

5.3.1.2.              After accepting the license agreement, scroll down to Oracle WebLogic Server 10.3.6. Do NOT install 12c. You will see a plus box next to “Oracle WebLogic Server 10.3.6”. Click the plus box next to “See all files” and more options will be available.

clip_image002[4]

5.3.1.3.              The ‘Oracle WebLogic Server 11gR1 (10.3.6) Coherence – Package Installer’ is the recommended installer of choice.

5.3.1.4.              Please download the file that corresponds to your system OS.  Note for 64-bit AIX, the “Generic” Installer will need to be downloaded.

 

clip_image004[4]

5.3.2. Forms 11.1.1.2

5.3.2.1.              Oracle Forms 11.1.1.2.0 is no longer available on OTN. It can only be downloaded from the Oracle E-Delivery page at:

https://edelivery.oracle.com

5.3.2.2.              Once there, search for the Product Pack “Oracle Fusion Middleware” on Platform “IBM AIX on POWER Systems (64-bit). Next, click on the description link for “Oracle Fusion Middleware 11g Media Pack for IBM AIX on POWER Systems (64-bit).” It will take you to a new page.

 

5.3.2.3.              Scroll down until you see the six downloads highlighted in the screenshot below. Please download the setup files that correspond to your system OS:

clip_image006[4]

5.3.3. Forms 11.1.1.7

The following steps will help guide you through Oracle’s Support website to find the Forms 11.1.1.7 Patch set. This is the only Oracle Website location where the Forms 11.1.1.7 Patch set can be downloaded.

 

5.3.3.1.              Go to support.oracle.com

5.3.3.2.              Login with your Oracle OTN Login that has your organization’s “oracle support identifier” that lets you download “Patches & Updates”

5.3.3.3.              Click on “Patches & Updates

clip_image008[4]

5.3.3.4.              In the Patch search, type in the patch number 16471668. Click the + button to the right to expand.

5.3.3.5.              For Platform, select “IBM AIX on POWER Systems (64-bit)”. Once checked, click “Search”.

clip_image010[4]

5.3.3.6.              The Patchset will appear. Click on the patch number.

clip_image012[4]

5.3.3.7.              Click “Download”.

clip_image014[4]

5.3.3.8.              Click on the links to download. The patch set is approximately 2.1 GB in file size, thus the files may take a decent amount of time to download.

clip_image016[4]

If you have any questions on the above, please contact PITSS for questions.