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

FORMS_DATETIME_LOCAL_TZ=GMT

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:

FORMS_DATETIME_SERVER_TZ=GMT

Source: Oracle Support document ID 2139346.1

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: https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?parent=DOCUMENT&sourceId=2113628.1&patchId=22184867

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

IMPORTANT: Downloading JDK and JRE 7 from My Oracle Support requires an account with My Oracle Support.

As of July 14, 2015, JDK 7 and JRE 7 are no longer available for public download. Although the latest version of Oracle Forms, version 11.1.2.2.0 (11gR2) is supported to use JRE 8, it is currently NOT supported to use JDK 8 for Oracle Forms and Reports 11gR2 as well as for other Fusion Middleware products such as ADF (11g and 12c) and OHS (11g and 12c). However, as public downloads for Java 7 are no longer available, there are only two options to download JDK 7.

One method (requires an Oracle account) is to use the Oracle Java Archive: http://www.oracle.com/technetwork/java/archive-139210.html

The second method involves downloading the JDK and JRE from My Oracle Support. The following steps will explain how you can download the latest JDK and JRE 7 from My Oracle Support:

  1. Log into https://support.oracle.com using your My Oracle Support account.
  2. Go to Patches & Updates
  3. Search for the following patches:
    1. JDK/JRE 7u79: 20418638
    2. JDK/JRE 7u80: 20418657
    3. Specify the OS platform of your server environment
    4. image
  4. Select the Patch number on the left side of the table
    1. image
  5. Click “Download”
    1. image
  6. Click the name of the zip file to download it.

Once the JDK and JRE are downloaded, you should be able to find both the JDK and the JRE for the particular OS you selected.

image

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 11.1.1.6.0, 11.1.1.7.0, 11.1.2.1.0 and 11.1.2.2.0 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 (https://support.oracle.com). 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.

image

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

image

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

image

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

image

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.

image

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

When running the Oracle Forms 11gR2 (11.1.2.2.0) Patchset Upgrade to upgrade an older version of Oracle Forms 11gR2 (11.1.2.0.0 or 11.1.2.1.0) in Windows, there is a random possibility that the following error may be encountered about halfway through the upgrade:

“Error in writing to file ‘%ORACLE_HOME%\bin\oraldapclnt11.dll’. [%ORACLE_HOME%\bin\oraldapclnt11.dll (The process cannot access the file because it is being used by another process)]”

Forms upgrade error with DB

Per the error message, the oraldapclnt11.dll is being used by another process. Before clicking “Retry”, make sure that:

1. Your WebLogic servers for the Forms and Reports environment are shut down.

2. OPMN is shut down for the Forms and Reports environment.

3. The Node Manager is shut down for the Forms and Reports environment.

4. If an Oracle Database is locally installed (meaning on the same PC/server where Forms and Reports is being upgraded), it should be shut down as well (the DB instance, the TNS listener, the DB console, etc.).

5. If any Oracle Enterprise Manager Grid/Cloud Control Agents are deployed on the PC/server, they should be shut down as well.

 

If you click “Retry” and the error still appears, apply these steps to fix the problem:

1. Make a backup of the entire Middleware home. You can do this by zipping up the entire Middleware directory.

2. Go into %ORACLE_HOME%\bin.

3. Rename the file “oraldapclnt11.dll” as “oraldapclnt11.dll.bak”.

4. Click “Retry”. The error should not appear again. The upgrade will create a fresh copy of the DLL.

NOTE: You may experience the same error with the following DLLs where you may need to apply the same steps as above (except for the Middleware backup as that would have been done already):

  • orannzsbb11.dll
  • orazt11.dll
  • oraztkg11.dll

ORACLE FORMS & REPORTS 11.1.2.2 INFORMATION AND FINDINGS

UPDATED: June 3, 2014

INTRODUCTION

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

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

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 11.1.2.1):

o   10.2.0.4+

o   11.1.0.7+

o   11.2.0.1+

o   12.1.0.1+

·          OAM support (No changes from Forms 11.1.2.1):

o   Oracle SSO 10gR3 (10.1.4.3+)

o   Oracle Access Management 11gR1 (11.1.1.5+)

o   Oracle Access Management 11gR2 (11.1.2.0.0)

o   Oracle Internet Directory (OID) 11gR1 (11.1.1.5+)

o   Oracle Virtual Directory (OVD) 11gR1 (11.1.1.5+)

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

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

For more information regarding Oracle Forms 11.1.2.2 certifications, please review Oracle’s certification matrix for Forms and Reports 11.1.2.2: http://www.oracle.com/technetwork/es/middleware/docs/oracle-forms-111220certmatrix-2087910.xls?ssSourceSiteId=otnen

SIMILARITIES/DIFFERENCES TO FORMS 11.1.2.1

After successfully installed and configured Oracle Forms & Reports 11.1.2.2 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 11.1.2.2 (as well as running config.bat/sh) is identical to installing 11.1.2.1. 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 11.1.2.1, 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 (11.1.2.0), using the default setting in rwservlet.properties would allow anyone to access anything related to rwservlet such as getjobid, showjobs, showenv, etc. For some reason in 11.1.2.1 and 11.1.2.2, 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 rwservlet.properties and restart WLS_REPORTS before we could view generated reports. NOTE: If this was fixed manually in Forms 11.1.2.1 and you patch the install to 11.1.2.2, you do not have to redo this. URL: https://pitss.com/us/2012/12/20/running-reports-in-formsreports-11-1-2-1-generates-rep-52262-with-default-settings/

4.       Patching your Forms 11.1.2.1 installation to 11.1.2.2 requires little effort. All that is required is to shut down all WebLogic servers associated with Forms 11.1.2.1, 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 11.1.2.0 installations that was fixed in 11.1.2.1 is also fixed in 11.1.2.2. 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: https://pitss.com/us/2012/10/08/how-to-fix-apache-bridge-error-bug-in-forms-11gr2/

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 11.1.2.2. Fortunately, applying the fix as mentioned in https://pitss.com/us/2012/10/10/reports-builder-11gr2-crashes-when-viewing-data-model/ will still fix the problem. NOTE: If this was fixed manually in Forms 11.1.2.1 and you patch the install to 11.1.2.2, you do not have to redo this.

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

8.       In Oracle Forms 11.1.1.6, 11.1.2.0, and 11.1.2.1, there was a bug where you were unable to edit any configuration files or logging information for OHS within Enterprise Manager as mentioned in https://pitss.com/us/2013/10/18/unable-to-edit-ohs-configuration-files-in-enterprise-manager-for-forms-11-1-1-6-or-11gr2/. This bug has been fixed in Forms 11.1.2.2 (as well as 11.1.1.7 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 11.1.2.0 and 11.1.2.1 environment, it is best to upgrade to Forms and Reports 11.1.2.2 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 https://pitss.com/us/2013/10/24/how-to-modify-custom-jar-files-with-permissions-and-codebase-attributes/ for more information.

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

12.   When configuring Oracle Forms and Reports 11.1.2.2 (using config.bat or config.sh) 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 11.1.2.1 and 11.1.1.7 has NOT been fixed in 11.1.2.2. You will need to run config.bat or config.sh 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 https://pitss.com/us/2013/04/12/forms-and-reports-11gr2-configuration-fails-at-access-control-step-with-oam-2/.

 

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

There is a known issue where if you try to launch Reports Builder 11g in Windows 7 (32-bit or 64-bit), the Reports Builder will not launch. However, the icon for it appears in the Windows taskbar. Opening it presents the error:

“REP-50125: rwbuilder.conf:java.lang.NullPointerException”

To fix the problem, follow these steps:

1.       Go to C:\Oracle\Middleware\asinst_1\config\FRComponent\frcommon\tools\admin

2.       Make a backup of cauprefs.ora

3.       Look for these entries:

Reports.root_x = “#####”

Reports.root_y = “#####”

image

4.       Replace the numbers (represented by #####) with 0 so that they look like this:

Reports.root_x = 0

Reports.root_y = 0

image

5.       Save and close the file

6.       Launch Reports Builder. Reports Builder should work successfully.

NOTE: If you open up Reports Builder at a later date and the problem reoccurs, open up cauprefs.ora and modify the same parameters again with the following:

Reports.root_x = 80
Reports.root_y = 30
Reports.root_y = 76

After applying the settings above, Reports Builder should open successfully.

Source: Oracle Support note 1478627.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

clip_image001[4]

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

clip_image003[4]

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

clip_image004[4]

4.       Select the Logging tab and the General subtab.

clip_image006[4]

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

clip_image008[4]

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

clip_image010[4]

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

10.   Click “Activate Changes”

clip_image011[4]

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.

clip_image012[4]

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

clip_image014[4]

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: https://pitss.com/us/2013/10/18/unable-to-edit-ohs-configuration-files-in-enterprise-manager-for-forms-11-1-1-6-or-11gr2/

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.

clip_image015[4]

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

clip_image017[4]

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)

clip_image018[4]

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.

There are times where if PITSS.CON crashes when modules are being loaded, the following error will appear when you try to start loading modules again:

image

You can do the following to fix the problem:

  1. Go to Administration –> Batch Jobs
    • image
  2. In the Batch Jobs menu, you will see “Load Forms” on the left side of the window. As you can see, it is not a “green light”. Right-click on “Load Forms”.
    • image
  3. Click on “Reset Batch Procedure”
  4. The traffic light symbol next to “Load Forms” should be green again.
    • image
  5. Try loading a module again.

Modules should load successfully now.

Updated: July 2, 2014

For Forms versions 11.1.1.6.0, 11.1.2.0.0, and 11.1.2.1.0, if you installed the WebLogic and Forms environment using JDK 7 (NOTE: JDK 7 is not supported with Forms 11.1.2.0.0), 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 oracle.as.management.mbeans.register:type=component,name=ohs1,instance=asinst_1,Location=AdminServer”

image

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

image

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

UPDATE (7/2/14): There is also a known issue (also includes Forms 11.1.2.2.0) 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).

image

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