Starting with Oracle Forms 12c, it is required to install RCU schemas into an Oracle Database. Without the RCU schemas, it will not be possible to start up the WebLogic servers. It is advised to have the RCU schemas configured to have the passwords to not expire, but if this is not possible due to security restrictions, you will need to remember to reset the password to what was configured when the schemas were installed. The RCU schemas are (the <PREFIX> is the prefix specified during the installation which goes in front of the schemas):


In the event that the above five schemas especially <PREFIX>_OPSS expires, if the Admin Server is started up, it will fail to start due to the error, “ORA-28001: password has expired”. If you reset the password for the five schemas to what was configured previously, the WebLogic server will start up normally.

However, if you either are required to change the password to something different or if you cannot remember the password which was used, you will need to follow these steps to change the RCU password and have the WebLogic domain recognize the new password:

  1. Set the new password for the RCU schemas mentioned above. Make sure the accounts are also unlocked. If the accounts are locked for any reason, you may need to contact a DBA to unlock the users.
    1. Example: alter user FORMS_OPSS identified by <new_password>;
  2. When the five schemas’ passwords are updated, you must run a commit to apply the changes: commit;
  3. The Admin Server will need to be started up. However, we will need to start it up in a different way to avoid it from crashing upon startup. Go to $ORACLE_HOME/oracle_common/common/bin and run (or wlst.cmd in Windows)
  4. In WLST, run the following (you must use forward slashes ‘/’ even for Windows): modifyBootStrapCredential(jpsConfigFile=’/u01/oracle/middleware/user_projects/domains/FormsDomain/config/fmwconfig/jps-config.xml’,username='<PREFIX>_OPSS’,password='<NEW_PASSWORD>’)
    1. NOTE: Your path to jps-config.xml within $DOMAIN_HOME/config/fmwconfig may be different than the example above. Please specify the full path without using environment variables.
  5. Exit WLST: exit()
  6. Start the Admin Server. Although you will still encounter errors regarding the data source, the Admin Server will start up.
  7. Log into the Admin Console.
  8. In the top-left corner of the Admin Console, click “Lock & Edit“.
  9. In the Domain Structure in the left frame of the Admin Console, go to Services –> Data Sources.
  10. Click on the first of four (assuming you have not configured additional data sources beyond the four which come with Forms 12c) data sources.
  11. Go to the Configuration tab and then the Connection Pool subtab.
  12. Type in the new schema password in the Password and Confirm Password fields.
  13. Click Save.
  14. Repeat steps 9-13 for the remaining three data sources.
  15. In the top-left corner of the Admin Console, click “Activate Changes“.
  16. In the top-left corner of the Admin Console, click “View changes and restarts“.
  17. Click the Restart Checklist tab.
  18. Place check marks next to all four data sources, and click “Restart“.
  19. On the confirmation page, click “Yes“.
  20. The data sources will restart. They should be functional again in a few seconds.

After completing the steps above, you should be able to start up the remaining WebLogic servers as well as restart the Admin Server without encountering the errors again.

Source: Oracle Support Document ID 1682942.1

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

There is a known bug in Oracle Forms 12c that the DATETIME item in Forms is set to a different time than what is configured in the Windows or UNIX server. Oracle Support has reported this issue in AIX, but it has been seen in both Windows and Linux as well. The easiest way to work around this bug is to configure the following environment variable to GMT in your env file (e.g. default.env):


NOTE: Normally when you do not set this variable, the system defaults to GMT, but this is necessary in 12c.

This should correct the time issues, but if for any reason any datetime fields are out of sync still, you may also need to set the following variable to GMT:


Source: Oracle Support document ID 2139346.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, if you were to access the showjobs page of your Oracle Reports 11g or 12c environment, any user is able to view the page and open up the reports even if they contain confidential information. There is a way you can configure the showjobs to where only specific users can access this page or any of the Reports admin pages (steps written for 12c but they will also work for 11g):

  1. Open up (make a backup first) located in $DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_12.2.1/configuration.
  2. Locate the line <webcommandaccess>L2</webcommandaccess>. Change L2 to L1.
    1. L1 will only permit end users to use the non-admin rwservlet commands GETJOBID, KILLJOBID, SHOWAUTH, and SHOWJOBID.
  3. Save and close the file.
  4. Open up rwserver.conf (make a backup first) located in $DOMAIN_HOME/config/fmwconfig/components/ReportsServerComponent/$rptsvr.
  5. Near the bottom of the file, look for the line <queue maxQueueSize=”1000”/>. Immediately after this line, add the following line:
    1. <identifier encrypted=”no”>username/password</identifier>
    2. NOTE: After you restart WLS_REPORTS and rep_server1, the credentials will be encrypted. Also, you may create any username/password combination you like. It does not need to be what is configured in weblogic or in the database.
    3. rwserver.conf update
  1. Save and close the file.
  2. Restart both WLS_REPORTS and the standalone reports server.
  3. Try to access showjobs normally. You should be presented with the following error:
    1. REP-52262: Diagnostic output is disabled
    2. REP-52262
  1. Now, add “?authId=username/password” to the end of the URL. Notice how the showjobs page appears.
    1. showjobs working
  1. If you were to reopen rwserver.conf, notice how the credentials are encrypted:
    1. rwserver.conf encrypted

Source: Oracle Support document 1242614.1 (Steps in the Oracle Support document are written for 11g)

There is a bug in Forms 12c where the Forms application crashes with FRM-93652 errors when calling any forms where data from a record group is populated. Oracle has created a patch to fix this problem. These steps should be followed to fix this problem:

NOTE: This problem is currently only seen in Unix environments (Linux, Solaris, AIX, etc.). It has not been reported in Windows.

  1. Download Oracle Patch 21534616 from My Oracle Support. Make sure to download the version for your server’s OS. NOTE: The patch is technically an Oracle Database patch, version, but this will be used to patch the DB client which comes with the Forms 12c installation.
  2. Extract the patch in your server. Once it is extracted, navigate into the 21534616 folder.
  3. Make sure the following environment variables are set (this assumes the Oracle home is installed in /oracle/middleware/as_1 but it may be different for your environment)
    1. export ORACLE_HOME=/oracle/middleware/as_1
    2. export PATH=/oracle/middleware/as_1/bin:$PATH:/oracle/middleware/as_1/OPatch
  4. Run opatch prereq CheckConflictAgainstOHWithDetail -ph ./ to make sure there are no conflicts or errors. FRM-93652 1                      FRM-93652 2
  5. Shut down all instances inside the Forms 12c domain (all WebLogic servers, OHS, the standalone reports server, and Node Manager).
  6. Run opatch apply to install the patch.                                                                                                                                                                                   FRM-93652 3
  7. Make sure the Middleware Home is the Oracle Home for Forms 12c. If it is, type y to proceed.                 FRM-93652 4
  8. When it asks if the local system is ready for patching, type y and press Enter.                                            FRM-93652 5
  9. You should receive a message that the patch was successfully applied. There will be some warnings, but you may ignore these warnings.
    1. FRM-93652 6
  10. Go to $ORACLE_HOME/forms/lib and run: make -f frmweb_install                                                     FRM-93652 7
  11. If you see the output shown in the following screenshot, the step was run successfully.                         FRM-93652 8
  12. Start up your Forms 12c environment.
  13. Recompile all forms, menus, and libraries.

After applying the steps above, you should no longer encounter FRM-93652 errors when opening up any 12c forms where data from a record group is populated.

NOTE: There is a possibility that you may encounter the error FRM-41337 in the same forms. If you do, you will need to apply another Oracle patch as indicated in

For forms which have been upgraded to 12c from an older version (6i, 9i, 10g, and 11g), there is a known bug where forms using the POPULATE_LIST built-in (the same code used from 6i to 11g) is producing the following error:

“FRM-41337: Cannot populate the list from record group.”

To fix this bug, Oracle has provided a patch, 22184867, which is available to download from My Oracle Support. You must have an active account with My Oracle Support to be able to download patches:

NOTE: The patch is only available for Linux, Solaris on SPARC, and Windows (all 64-bit). If you are experiencing the problem on platforms other than what is listed, please submit an SR to My Oracle Support.

Source: Oracle Support note 2113628.1

In new installs of Oracle Forms and Reports 12c, there is a known report where running Oracle Forms in Internet Explorer for the first time is causing the following error:

“Windows has blocked this software because it can’t verify the publisher.

Name: forms/

Publisher: Unknown Publisher”

Forms Runtime Error

This is because the Java Runtime Environment (JRE) download is being blocked by security settings in Internet Explorer. To bypass this error, you will either need to manually install a 32-bit JRE or have your system administrator install a 32-bit JRE for you. Unless the Forms environment’s formsweb.cfg is configured to use a specific JRE version, you should use the latest version of JRE which is version 8 update 77 as of April 2016.

After extending a domain with Oracle Forms and Reports with an additional Forms and Reports managed server, WLS_FORMS1 and WLS_REPORTS1, in a cluster, there is a known issue (this may or may not occur) where the standalone reports server of the original installation is unable to communicate with the EM Agent associated with the AdminServer for the Forms domain. For example, if you log into the Enterprise Manager (EM) Fusion Middleware (FMW) Control associated with your Forms domain, if this problem occurs, you will see the warning “Targets not being monitored due to invalid configuration”. If you click on this warning message, it will take you to the Agent-Monitored Targets page (you may also access this page by right-clicking the domain farm name in the left panel and selecting “Agent-Monitored Targets”). On this page, you may notice that one of the “Oracle Reports Server” targets needs an agent configured:

Agent-Monitored Targets

However, if you click to configure the agent for the target and you click OK after all fields entered are correct, you will get an error saying that there is no agent available.

To fix this problem, when you are in the Configure Target page, click the button “Change Agent”. The agent URL next to the Change Agent button will become a drop-down, and you should be able to select the correct agent associated with your standalone reports server:

Agent-Monitored Targets

After the agent is selected, click “OK” to save your changes. After completing this step, the target will be able to contact the agent successfully.

Even when WebUtil and Jacob have been fully configured in the PITSS.CON server environment as documented in, there have been known issues where users (on the first use of PITSS.CON) are unable to log in due to the following error:

NoClassDefFoundError – com/jacob/com/ComFailException

No Jacob

The reason for this error is because the Java cache may be interfering with properly finding the Java classes associated with jacob.jar. Clearing the Java cache should fix the problem:

  1. Open up the Control Panel on the end user’s PC
  2. Go to All Control Panel Items and click “Java”
  3. With the General tab highlighted in the Java Control Panel, click “Settings…”Java Control Panel
  4. Click “Delete Files…”Delete Temporary Java Files
  5. In the new pop-up window, have only “Trace and Log Files” and “Cached Applications and Applets” selected and click “OK”.Clearing Java cache
  6. After the window closes, click “OK” twice to close all windows in the Java Control Panel.
  7. Close all web browser windows and try launching PITSS.CON.

After completing the steps above, PITSS.CON should launch without any problems.