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.

PITSS.CON users can be reinstalled when needed to whether the user needs to be installed a different group or if installing in a new PC. Normally PITSS.CON users can be reinstalled in an existing group without any issues. However, there can be a time where the following error is presented when a PITSS.CON user is being reinstalled (or even installed) in an existing group:

“Invalid database! Does not fit with Group “GROUP_NAME” connection! Logon denied!


The reason is because the group which the PITSS.CON user is being installed into has an application connect string different from the default “system/*@DB” connect string. You will need to type in the full application database connect string used by the GROUP in the App Connect String field (username/password@DB). If you are unsure what the application connect string is, you can find this out with the MIG user:

1. Log into PITSS.CON with the MIG user.

2. Go to User Access

3. Click on the group name you are installing the new PITSS.CON user.

4. If you look on the right side near the top, you will see the application connect string being used by the group. For security reasons, the password will not be shown here. If you are unsure what the user’s password is, please consult your DBA.

After the App Connect String field is filled in, the (re)installation will proceed like normal.

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

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

3. Open up in a text editor.


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

After a server with WebLogic installed is restarted either normally or abnormally, there is a known issue where the managed WebLogic servers are unable to be started up using the Node Manager inside the WebLogic Administration Console. Errors produced are:

“For server MANAGED_SERVER_NAME, the Node Manager associated with machine MACHINE_NAME is not reachable.”


To solve this problem, please follow these steps below:

1. Make sure all managed WebLogic servers are shut down.

2. Shut down the AdminServer.

3. Stop the Node Manager. In Windows, this can be done by stopping the Windows service (if installed) or closing out of the Command Prompt window running startNodeManager.cmd.

4. In the file system, delete the following files for each managed server:

a. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\%MANAGED_SERVER_NAME%.state

b. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\%MANAGED_SERVER_NAME%.lck

c. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\

NOTE: If any of the above three files do not appear, that will be perfectly fine as that can happen sometimes.

5. Start up the Node Manager.

6. Start the Admin Server using either a startup script or WLST.


After applying the steps above, you should be able to start the managed servers from the Admin Console.

Source: Oracle Support note 1293552.1

In Reports Builder 11g, there is a known issue where copying and pasting items within any of the layout editors in Reports Builder causes Reports Builder to freeze or hang. This has been reported with Reports,, and with Windows 7 64-bit.

To resolve the issue, Oracle has provided a patch for download (NOTE: Access to My Oracle Support (Metalink) is required):

1. Download Patch 17301874 from Oracle Support ( Make sure you specify the version of Forms and Reports you have installed.

2. Extract the patch in your PC or server.

3. Shut down all WebLogic servers and OPMN processes pertaining to your Forms environment.


4. Open up Command Prompt as an administrator.

5. Set the following environment variables:

set ORACLE_HOME=C:\Oracle\Middleware\as_1 (or C:\Oracle\Middleware\Oracle_FRHome1)

set PATH=%PATH%;C:\Oracle\Middleware\oracle_common\OPatch


6. To ensure your OPatch version meets the prerequisites, run: opatch veresion


7. Navigate to where you extracted the Oracle patch and go into the 17301874 folder. Once there, install the patch by running: opatch apply


8. Ensuring that the Oracle Home mentioned matches the one for your Oracle Forms environment and everything in the Oracle Home is shutdown, type ‘y’ when asked if the system is ready for patching.


9. You will receive a success message when the patch is installed successfully.

10. Start up everything from the WebLogic servers to OPMN.

After applying the steps above, the problem should be fixed with Reports Builder.

Source: Oracle Support note 1395965.1

NOTE: All PITSS.CON installations and upgrades performed after January 1, 2015 should not encounter this problem as the updated jar file is already deployed. (Updated February 17, 2015)

When using PITSS.CON 12.3.1, there is a possibility where you may run into the following error when attempting to access the PITSS.CON Help manual by clicking the Help button:

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


Clicking OK will result in PITSS.CON crashing.

The reason for the problem is due to an issue with the jar file “pitssH.jar” usually located in C:pitssconPitssJava. To fix this issue, PITSS has made an update to the jar file. Please contact PITSS today to receive an updated jar file.

Once you receive the jar file, deploy it in C:pitssconPitssJava or the location where all of the PITSS.CON jar files are deployed. After that, restart WLS_FORMS and relaunch PITSS.CON. The PITSS.CON Help manual should now appear again.

NOTE: All PITSS.CON installations and upgrades performed after December 10, 2014 will have the newly-signed jar files deployed already. (Updated February 17, 2015)

Starting with PITSS.CON 12.2.2 and 12.3.1, all jar files associated with PITSS.CON are signed using trusted code-signing certificates to fulfill the latest Java JRE security requirements present in the newer updates of JRE 6 and 7. However, the code-signing certificates expire on December 5, 2014. A new patch is available for PITSS.CON which updates the jar files with newly-signed certificates good for 3 years.

IMPORTANT: To obtain a zip file containing updated PITSS.CON jar files, please contact PITSS.

Once you obtain the zip file containing the updated jar files, please follow the steps below:

1. Extract the zip file (should be called

2. Copy all jar files into C:\pitsscon\PitssJava (NOTE: Depending on your PITSS.CON installation, it may be in a different disk drive.)

3. Copy jacob.jar to %ORACLE_HOME%\forms\java

4. If WLS_FORMS is running, please restart WLS_FORMS.

After applying the steps above, you should be able to run PITSS.CON without seeing any Java security warnings complaining about expired certificates.

NOTE: If you are using PITSS.CON 12.1.3 or older, please contact PITSS to upgrade your PITSS.CON installation to the latest version today!

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

There are many remote desktop applications available in the Internet. NoMachine is a great example of a remote desktop client which can be used to connect from a Windows, Mac, or Linux box to another Windows, Mac, or Linux machine which has NoMachine also installed. By default, the NX Agent will use port 7001 (the value of the DisplayBase set for NoMachine + 6000) running on localhost. As the agent is using port 7001, it can potentially cause a conflict with the AdminServer for any WebLogic environments using port 7001 primarily if using localhost to access the WebLogic Admin Console or anything WebLogic-related running on port 7001.

Error in starting the AdminServer using port 7001:


Port conflict exists due to NoMachine agent using port 7001 on localhost:


NOTE: Although the AdminServer starts up successfully, it is not possible to run anything with port 7001 for anything WebLogic-related using the localhost address (using your actual hostname instead of localhost works fine however):


To fix this problem, you can change the port which NoMachine uses for the NX Agent using these steps below:

NOTE: Admin privileges are required.

1. Go to the file directory where NoMachine is installed (in Windows, it should be C:\Program Files (x86)\NoMachine by default) and go into the etc folder.

2. Open the file server.cfg using a text editor (NOTE: Make a backup first!).

3. Locate the parameter DisplayBase (may be commented out initially). Set the number to a value which does not conflict with other running ports. In this example, I changed the DisplayBase to 2001 (DisplayBase + 6000 = the port number used for the NX Agent) so that the NX Agent uses port 8001, a port which nothing with WebLogic will use. NOTE: Make sure the value is NOT commented!


4. Save and close the file.

5. Open up the Windows Services and locate the service “NoMachine Display Monitor”. Restart the service so the port number changes from 7001 to the port number you set.


6. Now that the service has been restarted, the agent will no longer be using port 7001. In order to associate localhost with your WebLogic AdminServer using port 7001 again, you will need to restart the AdminServer.

After applying the steps above, you should be able to use the localhost address with your WebLogic server environment running port 7001.