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

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:

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


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


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


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


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

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

When finished, click the “Save” button.


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.


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.


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

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.



If you are unable to start your AdminServer in WebLogic due to the following error:

“java.lang.ClassCastException: com.octetstring.vde.backend.BackendRoot cannot be cas t to com.octetstring.vde.backend.standard.BackendStandard. This may indicate a problem with the data files for the Embedded LDAP Server. If the problem is with the data files and it can not be corrected, backups of previous versions of the data files exist in /myDomain/servers/AdminServer/data/ldap/backup.>”

There is a possibility that the LDAP data for the WebLogic server is corrupted. To fix the problem, you will need to follow these steps:

1. In %DOMAIN_HOME%\servers\AdminServer\data\ldap\ldapfiles ($DOMAIN_HOME/servers/AdminServer/data/ldap/ldapfiles in Unix), check to make sure that the user who installed WebLogic has full control permissions (or read/write/execute permissions in Unix) on the file “EmbeddedLDAP.tran”.

2. Go to %DOMAIN_HOME%\servers\AdminServer ($DOMAIN_HOME/servers/AdminServer). Zip up the folders “cache” and “tmp”.

3. Delete everything inside both folders (but do not delete the actual folders).

4. Go to %DOMAIN_HOME%\servers\AdminServer\data ($DOMAIN_HOME/servers/AdminServer/data) and zip up the “ldap” folder.

5. Delete the ldap folder completely.

6. Restart the AdminServer


After applying the steps above, you should be able to start up the WebLogic server normally.

Source: Oracle Support note 1525307.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 “”>

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


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

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


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.mp64 (version

bos.rte.libc (version

xlC.aix50.rte (version

xlC.rte (version

X11.motif.lib (version 2.1.30)

gpfs.base (version (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









xlC.aix50.rte (version

xlC.rte (version

X11.motif.lib (version 2.1.30)

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

For more information from Oracle on required packages please go to:

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









xlC.aix50.rte (version

xlC.rte (version

IZ89165 (Only if using Oracle BI)

For more information from Oracle on required packages please go to:

4.     Database Requirements

4.1.    Supported Database Versions:

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 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              Can be downloaded from:              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]              The ‘Oracle WebLogic Server 11gR1 (10.3.6) Coherence – Package Installer’ is the recommended installer of choice.              Please download the file that corresponds to your system OS.  Note for 64-bit AIX, the “Generic” Installer will need to be downloaded.


5.3.2. Forms              Oracle Forms is no longer available on OTN. It can only be downloaded from the Oracle E-Delivery page at:              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.              Scroll down until you see the six downloads highlighted in the screenshot below. Please download the setup files that correspond to your system OS:


5.3.3. Forms

The following steps will help guide you through Oracle’s Support website to find the Forms Patch set. This is the only Oracle Website location where the Forms Patch set can be downloaded.              Go to              Login with your Oracle OTN Login that has your organization’s “oracle support identifier” that lets you download “Patches & Updates”              Click on “Patches & Updates

clip_image008[4]              In the Patch search, type in the patch number 16471668. Click the + button to the right to expand.              For Platform, select “IBM AIX on POWER Systems (64-bit)”. Once checked, click “Search”.

clip_image010[4]              The Patchset will appear. Click on the patch number.

clip_image012[4]              Click “Download”.

clip_image014[4]              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.


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

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.

When installing Oracle Forms and Reports, if most or all of the prerequisite checks fail due to a common error “Not executed”, check the install logs. Inside the log, if you receive the following errors according to Oracle Support note 468051.1:

“Checking operating system requirements … Check complete. The overall result of this check is: Not executed <<<< OUI-15038: Unable to execute rule ‘CertifiedVersions’ from ruleset ‘OSChecks’. The underlying test ‘oracle.sysman.oip.oipc.oipcz.OipczOSChecks.checkCertifiedOSVersions’ has thrown an unhandled exception [For input string: “18446744073709551615”]. If the exception results in a failure of the test and the exception needs to be propagated, then encapsulate the exception in the result object and return the result.”

You may need to edit the SHMMAX setting in Linux. The input string shown in the error “18446744073709551615” is the current SHMMAX setting. The maximum value it can be is 4294967295 (or FFFFFFFF). You can fix this error by the following:

  1. As the root user, go to /etc/
  2. Open the file sysctl.conf using a text editor
  3. Add a new line at the end of the file as follows: kernel.shmmax=4294967295
  4. Save all changes and exit the file
  5. Activate the new setting by: /sbin/sysctl –p
  6. Run the Forms installer again (as oracle). The errors should not appear.