In Forms 12c, there has been a random occurrence where trying to access Forms (or even a non-Forms resource) with OAM using a webgate that the following error will be presented:

“Internal Server Error”

If this occurs even after clearing the Web browser cache, you will need to perform the following steps to fix the problem:

  1. Go to $DOMAIN_HOME/servers/ohs1/cache
  2. Back up everything in the folder and move the backup elsewhere
  3. Delete everything in the cache folder

After applying the steps above, the error should disappear.

For Oracle Forms 11gR2 and 12c protected by OAM using WebGate, there are known reports where users may encounter errors after being logged into the application for 60 minutes:

FRM-92091: Unexpected fatal error in client-side Java code


FRM-92102: A network error or server failure has occurred

The reason for these errors is because the “Token Validity Period” is being reached. This is a setting configured in the webgate agent. By default, this parameter is set to 60 minutes or 1 hour. This means that regardless if the end user has been using Forms for a full hour or if the user has left his or her Forms session idle for an hour, a timeout will occur. To solve this problem, the Token Validity Period setting in the webgate agent will need to be increased to a value (in minutes) where end users will not encounter these errors (i.e. 480 minutes (8 hours) or 540 minutes (9 hours)). You will need to determine the amount of time before this timeout occurs.

NOTE: When you update the Token Validity Period for the webgate, you will need to redeploy the WebGate files generated in the $OAM_DOMAIN_HOME/output/<WebGateAgentName> directory into the OHS home’s webgate/conf folder as well as restart OHS.

After making the change above, the errors should no longer occur once 60 minutes has passed.

Source: Oracle Support Document ID 2178936.1

Oracle HTTP Server (OHS) can be used to redirect users to a new site when a particular URL is specified. This is useful if you would like to have users go to a new domain or website if they still would like to access an old URL. A RewriteRule can be written in httpd.conf (for HTTP) and/or ssl.conf (for HTTPS) to perform this. This can be implemented in both 11g and 12c. The following steps are written for 12c, but they can also be used for 11g to redirect traffic from the starting OHS page (http://server.domain:<ohs_port>) to another page:

  1. Log into EM Fusion Middleware Control.
  2. Go to the Target Navigation (you may have to click the button in 12c to access the menu), expand HTTP Server, right-click on ohs1, go to Administration –> Advanced Configuration.
    1. Target Navigation
  3. If you are using 12c, click the lock button in the top-right corner, and select “Lock & Edit”. If you are using 11g, you may skip to step 4.
    1. Lock and Edit
  4. Select “httpd.conf” in the drop-down menu and click “Go”.
  5. Scroll to the very bottom of the file. Add the following three lines:
    1. RewriteEngine On
      RewriteCond %{REQUEST_URI} ^/$
      RewriteRule ^(.*)$ http://<server>.<domain>:<OHS_PORT>/newhtml.html [R,L]
    2. NOTE: You may also redirect to a new domain such as <newserver>.<newdomain> using the same rewrite rule parameter.
    3. RewriteEngine
  6. Click “Apply” to save all changes.
  7. If you would like to also perform a redirect when using HTTPS, you may apply the same changes for ssl.conf. If you do not need to do this, please skip to step 9. However, when adding these three lines in ssl.conf, it should be before the closing </ifModule> tag and the rewrite rule should use HTTPS. You may use the screenshot below as an example.
    1. RewriteEngine SSL
  8. Click “Apply” to save all changes.
  9. (Skip to Step 10 if you are using 11g). In the top-right corner, click the lock button and select “Activate Changes”.
  10. Restart OHS.

After applying the steps above, when the index.html page is accessed of your OHS server using http(s)://<server>.<domain>:<OHS_PORT>, the URL will be immediately redirected to the page you specified in the RewriteRule.

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:

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


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


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


6. Save and close the file

7. Restart OHS using either OPMN or Enterprise Manager


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.


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. 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

There have been known issues where if you plan to run Oracle Forms using OHS with SSL/TLS (using the HTTPS protocol) and the OHS HTTP port (8888 by default) is disabled in httpd.conf, connections to the Forms application drop after a small period of time. The error which end users receive is:

FRM-92103: A network error or server failure has occurred. You will need to restart your application.


Look in the ohs1.log located in %ORACLE_INSTANCE%\diagnostics\logs\OHS\ohs1. If you see the following errors inside the log file:

[timestamp] [OHS] [ERROR:32] [OHS-2079] [core.c] [host_id: hostname] [host_addr: ip_address] [pid: ###] [tid: ###] [user: USER] [VirtualHost: hostname.domain:8890]  nzos handshake error, nzos_Handshake returned 29039(server hostname.domain:8890, client ::1)

[timestamp] [OHS] [ERROR:32] [OHS-2171] [core.c] [host_id: hostname] [host_addr: ip_address] [pid: ###] [tid: ###] [user: USER] [VirtualHost: hostname.domain:8890]  NZ Library Error: SSL negotiation error [Hint: too restrictive SSLCipherSuite]

OHS may need to be enabled at least at the loopback address level. If your organization has requirements where the OHS HTTP port has to be disabled for incoming and outgoing connections, configuring it to run only at the loopback level will still satisfy this requirement. To configure this, you will need to follow these steps:

1. Go to %ORACLE_INSTANCE%\config\OHS\ohs1 ($ORACLE_INSTANCE/config/OHS/ohs1 in Unix) and open up httpd.conf in a text editor (make a backup first).

2. Look for the commented “#Listen 8888” parameter. Uncomment the parameter and specify the loopback address:



3. Save and close the file.

4. Restart OHS either from OPMN or Enterprise Manager.

After applying the steps above, the FRM-92103 errors should disappear when running Forms with the OHS HTTPS port.

Source: Oracle Support note 1471204.1


UPDATED: June 3, 2014


Oracle has just recently released an updated version of Oracle Forms 11gR2 versioned as 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 (

·         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 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

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





·          OAM support (No changes from Forms

o   Oracle SSO 10gR3 (

o   Oracle Access Management 11gR1 (

o   Oracle Access Management 11gR2 (

o   Oracle Internet Directory (OID) 11gR1 (

o   Oracle Virtual Directory (OVD) 11gR1 (

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

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

For more information regarding Oracle Forms certifications, please review Oracle’s certification matrix for Forms and Reports


After successfully installed and configured Oracle Forms & Reports 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 (as well as running config.bat/sh) is identical to installing 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, 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 (, using the default setting in would allow anyone to access anything related to rwservlet such as getjobid, showjobs, showenv, etc. For some reason in and, 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 and restart WLS_REPORTS before we could view generated reports. NOTE: If this was fixed manually in Forms and you patch the install to, you do not have to redo this. URL:

4.       Patching your Forms installation to requires little effort. All that is required is to shut down all WebLogic servers associated with Forms, 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 installations that was fixed in is also fixed in 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:

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 Fortunately, applying the fix as mentioned in will still fix the problem. NOTE: If this was fixed manually in Forms and you patch the install to, you do not have to redo this.

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

8.       In Oracle Forms,, and, there was a bug where you were unable to edit any configuration files or logging information for OHS within Enterprise Manager as mentioned in This bug has been fixed in Forms (as well as 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 and environment, it is best to upgrade to Forms and Reports 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 for more information.

10.   Like earlier releases of Oracle Forms and Reports 11gR2 ( and, WebUtil for Forms 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 (or to is all that is needed to log into your Forms application using OAM.

12.   When configuring Oracle Forms and Reports (using config.bat or 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 and has NOT been fixed in You will need to run config.bat or 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


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 The newest PITSS.CON version, 12.2.2 (as of January 8, 2014), works well with Forms Everything works the same as it did in Oracle Forms

In Oracle Reports 11g ( and 11.1.2.x.0 (11gR2)), there is a known issue where all long-running reports that take more than 5 minutes to execute result in the error: “Failure of server APACHE bridge”.

By default in OHS, the Idempotent is turned on in OHS which results in a 5 minute timeout (even if the report job is being executed) by default. The parameters Idempotent and WLIOTimeoutSecs are not configured by default in OHS (within an Oracle Forms and Reports 11g installation). Due to this, Idempotent is turned ON with WLIOTimeoutSecs set to 300 (5 minutes).

To fix this problem, you can apply the following:

  1. Open httpd.conf located in %ORACLE_INSTANCE%\config\OHS\ohs1 ($ORACLE_INSTANCE/config/OHS/ohs1 in Unix). NOTE: Please make a backup first.
  2. Anywhere in the file, add the following two parameters:
    1. Idempotent OFF
    2. WLIOTimeoutSecs 1800 (NOTE: You can configure this for any value in seconds. For example setting this to 1800 represents 30 minutes.)
    3. image
  3. Save and close the file.
  4. Restart OHS using OPMNCTL.

After applying the settings above, you should be able to run the long-running reports jobs that take more than 5 minutes.

Source: Oracle Support note 1122443.1

Log Rotation for WebLogic, Forms, and Reports 11g

1.     About Log Rotation

Log rotation is the process of generating new log files and adding a timestamp to older log files. This helps prevent a log file from growing too large. Log rotation can either be done when a log file gets to a certain size, after a certain time frame, or perhaps both (only available for the standalone reports server). Log rotation can also be configured to have old log files replaced with new log files after a certain amount of rotated log files are generated.

2.     WebLogic Servers for Forms and Reports

By default, the log rotation settings for the WebLogic servers are set to have an unlimited number of log files rotated. The logs are rotated after a log file gets to around 5000 KB.

To change the settings for log rotation, log into the WebLogic Administration Console.

1.       Go to Environment –> Servers


2.       Click on a WebLogic server (such as WLS_FORMS)


3.       Click “Lock & Edit” in the top-left corner


4.       Select the Logging tab and the General subtab.


5.       In the Rotation section, you will see the Rotation type. You can select if you want “By Size” or “By Time”.

a.       By Size – The Rotation file size parameter specifies (in KB) how big the file can get before the log file is rotated. The parameter “Rotation file size” specifies (in KB) how big a log file can get before it is rotated

b.      By Time – The Begin rotation time parameter specifies (in HH:MM of the day) when the log file is rotated. You may also specify a Rotation interval (in hours) for how often a log file is rotated


6.       To limit the number of log files in the directory, select “Limit number of retained files” (unchecked by default).

7.       If you have selected to limit the number of retained files, you can specify in the “Files to retain” parameter how many files to retain in the file system before older log files get overwritten (7 is the default setting).

8.       Click “Save” to save changes


9.       Repeat steps 2-8 for any other WebLogic servers you wish to configure

10.   Click “Activate Changes”


NOTE: If the rotation type (size or time) is unchanged, but the other parameters are updated, no restarts of any WebLogic servers are required. However, if you change the rotation type from “By Size” to “By Time” or vice-versa, any affected WebLogic servers will need to be restarted.

3.     Oracle HTTP Server (OHS)

By default, the log rotation settings for OHS are size-based for up to 10 MB and to only retain 7 log files.

To update the settings, log into the Enterprise Manager for the Forms and Reports environment. Expand Web Tier and select “ohs1”. Once there, click the drop-down menu and go to Administration –> Log Configuration.


The settings are configured in the Rotation Policy. You can either select:

·         No Rotation – No log rotation at all (OHS log files will continue to grow larger)

·         Size Based – Log rotation performed when a file size gets to the limit (Maximum Log File Size (MB))

o   Maximum Files to Retain – The maximum number of files to keep in the server before older log files are overwritten

·         Time Based – Log rotation performed starting at a specified day and time.

o   Rotation Frequency – How often the file is rotated


To save changes, click “Apply”. NOTE: You will need to restart OHS either from Enterprise Manager or OPMN.

NOTE: If you try to access the log configuration for OHS and you get an error “Failed to invoke operation load on MBean”, please review our knowledge base article to update a parameter in admin.conf to fix this error:

4.     Standalone Reports Server

By default, the log rotation settings for the standalone reports server is set to a “size based” log rotation policy where the maximum file size is 10 MB and all log files cannot be more than 100 MB.

Log into the Enterprise Manager for Forms and Reports. Expand Reports and select your standalone reports server name “RptSvr…”. Next, select the drop-down menu and go to Logs –> Log Configuration.


Select the “Log Files” tab and you will see three handlers:

·         rwengine_trace_handler – Logs for the reports server engine(s)

·         rwserver_trace_handler – Logs for the standalone reports server itself

·         zrclient_trace_handler – Logs for the network connectivity for reports

To view the rotation policy, select a handler and select “Edit Configuration”.


In the window that appears, you will see the rotation policy. You can either configure the rotation policy for size-based rotation, time-based rotation, or both:

·         Size Based

o   Maximum Log File Size (MB) – How large a single log file can get before rotating the log

o   Maximum Size of All Log Files (MB) – How large all of the log files total can get before old log files are overwritten

·         Time Based

o   Start Time – What day and time to start rotating logs

o   Frequency – How often to rotate log files (in minutes)


To make any changes, click “OK”. Back in the main window, make any changes to the other handlers if needed and click “Apply” to activate the changes. NOTE: You will need to restart the standalone reports server either with Enterprise Manager or OPMN to deploy the changes.

Updated: July 2, 2014

For Forms versions,, and, if you installed the WebLogic and Forms environment using JDK 7 (NOTE: JDK 7 is not supported with Forms, if you attempt to make any modifications of any OHS configuration files in Enterprise Manager FMW Control, you will be presented the following error message:

“Failed to invoke operation load on MBean,name=ohs1,instance=asinst_1,Location=AdminServer”


To fix this error, go to %ORACLE_INSTANCE%\config\OHS\ohs1 ($ORACLE_INSTANCE/config/OHS/ohs1 in Unix) and open up admin.conf with a text editor (please make a backup of this file before making any edits to this file or any configuration file). Once in the file, look for the parameter “SSLProtocol nzos_Version_3_0”. Change this to: SSLProtocol nzos_Version_1_0 nzos_Version_3_0


After making the change above, save and close the file. Restart OHS from either OPMN or Enterprise Manager. After OHS has been successfully restarted, you should be able to make edits to OHS configuration files in EM.

NOTE: According to Oracle Support, this has been fixed with Oracle Forms

UPDATE (7/2/14): There is also a known issue (also includes Forms where the same error is produced due to a filename containing spaces in %ORACLE_INSTANCE%\config\OHS\ohs1\moduleconf ($ORACLE_INSTANCE/config/OHS/ohs1/moduleconf in Unix).


To fix the problem, rename the file containing spaces so that there are no spaces in it. After the file(s) has been renamed, restart the AdminServer. After doing that, the error should disappear.

Sources: Oracle Support notes 1463846.1 and 1352382.1

Oracle HTTP Server (OHS) can be used as a load balancer between two Oracle Forms and Reports environments. One of our customers had run into a error when using JRE 7 when logging into the Oracle Forms application. They were receiving the following error:

“FRM-93618: fatal error reading data from runtime process

Contact your system administrator.”


The production environment had the following multi-server architecture (NOTE: The error may occur if not using OAM as no errors were detected in the OAM or OID side):

Front-end Server (Point of entry for end-users):

  1. Oracle HTTP Server ( (load balancing occurs here using forms.conf and mod_wl_ohs.conf) – Using SSL

Two Middle-Tier Servers

  1. Oracle Forms and Reports
  2. Oracle WebLogic Server 10.3.6

Back-end Infrastructure Server

  1. Oracle Internet Directory
  2. Oracle Access Manager
  3. Oracle WebLogic Server 10.3.5

The scenario was that the OHS and Forms/Reports environments were upgraded from to in order to support the use of Java 7 (JRE 7) for end users. End-users would log into the front-end and would log into OAM (using single sign-on). After the user is authenticated in OAM, the user would be directed (by a round-robin approach) to one of the two middle-tier servers where the Oracle Forms application is. However, if the user used JRE 6, they could access Forms without a problem. If the user used JRE 7, the FRM-93618 error appeared instead, preventing the user from continuing. Whenever a direct connection to the middle-tier server was performed (again using OAM to authenticate), no errors would occur regardless of the JRE used.


The load balancing in OHS for Oracle Forms is performed using forms.conf (located in %ORACLE_INSTANCE%\config\OHS\ohs1\moduleconf). A parameter called “CookieTracking” needs to be set to “On” within the <Location /forms> tags. In order to apply this, you will need to do the following steps:

  1. Make a backup of forms.conf in the load balancing server
  2. Open up forms.conf in a text editor
  3. Locate <Location /forms>. In between this tag and the </Location> tag, add the following parameter: CookieTracking On
  4. Save and close the file
  5. Restart OHS (the load balancing server)

After applying the above changes, FRM-93618 will no longer appear when using JRE 7. This will work using the Internet Explorer, Firefox, and Chrome browsers.