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)

Oracle Forms 12c is the first version of Forms to be supported with the new Java Web Start functionality. This allows you to launch your Forms application using any certified browser including Google Chrome. PITSS.CON can also be configured to run with Java Web Start. To implement this functionality with PITSS.CON, you will need to run these steps:

  1. Open up formsweb.cfg located in %DOMAIN_HOME%\config\fmwconfig\servers\WLS_FORMS\applications\formsapp_12.2.1\config.
  2. Within your config section(s) for PITSS.CON, add the following parameters inside it:
    1. basejnlp=webutil.jnlp
  3. Save and close the file.
  4. Go to %ORACLE_HOME%\forms\java and open up extensions.jnlp in a text editor (make a backup of this file first).
  5. Look for <!– <jar href=”jacob.jar”/ –>. Uncomment this line. It should look like this: <jar href=”jacob.jar”/>
    1. NOTE: This fixes a Forms startup issue when using Java Web Start. Source: Oracle Support note 2083540.1
  6. Add the following lines for each of the PITSS.CON jar files (this will allow all jar files for PITSS.CON to be used while running Java Web Start):
    1. <jar href=”/forms/PitssJava/pitssicon.jar”/>
      <jar href=”/forms/PitssJava/pitssE.jar”/>
      <jar href=”/forms/PitssJava/pitssH.jar”/>
      <jar href=”/forms/PitssJava/pitssFS.jar”/>
      <jar href=”/forms/PitssJava/pitssCFS.jar”/>
      <jar href=”/forms/PitssJava/pitssLE.jar”/>
      <jar href=”/forms/PitssJava/FileLastModified.jar”/>
      <jar href=”/forms/PitssJava/pitss_calendar.jar”/>
      <jar href=”/forms/PitssJava/pitssXSL.jar”/>
      <jar href=”/forms/PitssJava/classes12.jar”/>
      <jar href=”/forms/PitssJava/PitssFileUtils.jar”/>
      <jar href=”/forms/PitssJava/BarChart.jar”/>
      <jar href=”/forms/PitssJava/colorpicker.jar”/>
      <jar href=”/forms/PitssJava/jcommon-1.0.16.jar”/>
      <jar href=”/forms/PitssJava/jfreechart.jar”/>
      <jar href=”/forms/PitssJava/PieChart.jar”/>
      <jar href=”/forms/PitssJava/OGD.jar”/>
    2. The file should look like this:
    3. Java Web Start PITSSCON
  7. Save and close the file.
  8. Clear your Java cache on your PC where you plan to launch PITSS.CON.
  9. Launch PITSS.CON.

After completing the steps above, you should be able to use PITSS.CON using Java Web Start.

There is a known issue where running tree reports from PITSS.CON 15.4.2 installed in a Forms 12c environment where the error “Error when running report” appears when attempting to create a PDF tree report. This happens to not be a bug with the latest PITSS.CON release. To get tree reports to generate in PITSS.CON, a new configuration is required in Forms and Reports 12c to run PITSS.CON tree reports in 12c.

First, make sure that all environment files (.env) have the new COMPONENT_CONFIG_PATH environment variable set up. For more information, you may check out our knowledge base article on setting up this environment variable here:

Once the variable is set up, you will also need to set up two environment variables for your Reports 12c environment. This should be set up in rwserver.conf. If you are using a standalone reports server, the file is located in %DOMAIN_HOME%\config\fmwconfig\components\ReportsServerComponent\%RptSvr%; if you are using the in-process reports server, the file is located in %DOMAIN_HOME%\config\fmwconfig\servers\WLS_REPORTS\applications\reports_12.2.1\configuration. Before modifying this file, please make a backup. Inside the file after the <engine> tag containing the id=”rwEng” line, add the following lines (you may use the screenshot below as a guide):

<environment id=”pitss”>
<envVariable name=”REPORTS_PATH” value=”C:\pitsscon\tool;c:\pitsscon\%PITSS_USER%\rdf;c:\pitsscon\%PITSS_USER%\olb;” />
<envVariable name=”TNS_ADMIN” value=”%DOMAIN_HOME%\config\fmwconfig”/>

NOTE: This assumes that PITSS.CON is installed in C:\pitsscon as it uses paths such as C:\pitsscon\tool and C:\pitsscon\%PITSS_USER%\rdf. Also, %PITSS_USER% should be your PITSS.CON user. If you have more than one PITSS.CON user, please specify the RDF and OLB paths for all PITSS.CON users here. For the TNS_ADMIN variable, the fully-written path for %DOMAIN_HOME%\config\fmwconfig should be filled inside the value attribute.

rwserver.conf for PITSS.CON

After the update is made, save and close the file. Once the file is updated, you will need to restart your reports server (the standalone reports server if you configured the standalone reports server or WLS_REPORTS if you configured the in-process reports server).

After restarting your reports server, you should be able to run a tree report in PITSS.CON.

After upgrading Oracle Forms and Reports from a previous version (e.g. 10g or 11g) to 12c, there is a known issue where running Oracle Reports in 12c with the RUN_REPORT_OBJECT built-in causes the following error:

“FRM-41214: Unable to run report”

Starting in Forms 12c, a new environment variable, CONFIGURE_COMPONENT_PATH, has been created. This should be placed in your environment file (.env) used by your Forms application. The variable should be mapped to the location of your ReportsToolsComponent. You may either edit the file manually or create a new variable under Environment Configuration for the Forms instance in EM FMW Control.

Example: CONFIGURE_COMPONENT_PATH=%DOMAIN_HOME%\config\fmwconfig\components\ReportsToolsComponent\reptools1


NOTE: If you use EM FMW Control to create or modify your environment variables for Forms, it is highly recommended to continue to use EM FMW Control.

In addition, make sure that the CLASSPATH variable has the full path to rwrun.jar (%ORACLE_HOME%\reports\jlib\rwrun.jar), as this jar file is required to generate reports from Oracle Forms.

After you have made the changes, re-launch the Forms application. You should now be able to run a report.

Source: Oracle Support note 2074841.1

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.

When updating forms to a live production environment, if a form is updated when end users have the form open, users may encounter odd errors. Although a form can be copied over an open form in Unix, it is not possible to copy over an open form in Windows.

One recommendation is to implement two deployment locations: the actual location where all of the production forms are deployed and a temporary location for new deployments which is specified earlier in the FORMS_PATH. New or updated forms are deployed in the temporary location and then moved over to the main location during a time when no one will be using the application.

Example FORMS_PATH entry:


C:\app\forms_new would be an example of a temporary location where new and updated forms would go and C:\app\forms would be an example of the current live forms.

In this example, forms are deployed under C:\app\forms. When a new form needs to be deployed during working hours when the app is being heavily used, it is deployed under C:\app\forms_new. As new users connect or reconnect to a form, they connect to the new form under forms_new since it is earlier in the FORMS_PATH. Eventually no one is using the form under C:\app\forms, and during off hours, the form can be moved from C:\app\forms_new to C:\app\forms.

By default in every Oracle Database, you can have up to 200 total data files (.DBF files) in each Oracle Database instance as indicated by the value of the parameter “db_files” (you can check the value by running “show parameter db_files” in your database. If you need to create more data files than what the db_files parameter will allow, you will need to increase the value of db_files. If this is not done, you will receive the following error when you either create a new data file for an existing tablespace or create a new tablespace:

ORA-00059: maximum number of DB_FILES exceeded

To increase the db_file parameter, you will need to complete these steps:

NOTE: A restart of the database instance will be required.

1. Log into the database using SYS

2. Increase the value of the db_files parameter to a higher value (slightly higher than the number of data files you expect to create):

alter system set db_files=# scope=spfile; (where # is the new value of db_files)

3. Restart the database:

shutdown immediate;


4. Confirm that the parameter has been increased by running “show parameter db_files”.

After completing the steps above, you should be able to create additional tablespaces and/or data files as needed.

Source: Oracle Support note 1589201.1