Beginning April 18, 2017, Oracle now considers any jar files signed with MD5 to be unsigned due to the security vulnerabilities with MD5 signatures. Starting with Java Runtime Environment (JRE) 1.8.0_131 (Java 8 Update 131), when it is used for running Oracle Forms (all versions), any jar files signed with MD5 will be blocked:

More information from Oracle on this may be found at https://blogs.oracle.com/java-platform-group/oracle-jre-will-no-longer-trust-md5-signed-code-by-default.

For any of your custom jar files, they will need to be re-signed without MD5 (MD5withRSA). It is recommended to use SHA-256 (or SHA-2).

As for the jar files which come installed with Oracle Forms (frmall.jar, frmwebutil.jar, etc.), if you are using Forms 12c (12.2.1.0.0 or higher), you will have no problem running the application because the jar files are not signed with MD5. However, if you are running Oracle Forms 11gR2 or older (including 11.1.2.2.0), you will get this warning upon launching your application which will result in the application not launching at all. To fix this problem, you will have the following options to choose from:

  1. Upgrade to Oracle Forms 12c
  2. Apply Patch 19933795 to your Oracle Forms environment (see steps below to apply the patch).
    1. NOTE: This patch is only available for Oracle Forms versions 11.1.1.7.0 and 11.1.2.2.0. If you are using a version older than these, you will need to upgrade to either these versions or to 12c.
  3. Run a JRE older than 8u131 (not recommended due to increased security risks)
  4. Add your Forms site to the Exception Site List in each end user’s Java Control Panel (not recommended due to the fact that this will need to be done for every user’s PC)

If you decide to apply Patch 19933795 to your Forms environment after downloading it from My Oracle Support, you will need to run these steps:

  1. Shut down everything in your Oracle Forms environment (all WebLogic servers, Node Manager, and anything running within OPMNCTL).
  2. Extract the zip file containing the patch.
  3. Go into the extracted folder and then inside the 19933795 folder.
  4. Open up Command Prompt as an administrator and change the directory to the 19933795 folder.
  5. Set ORACLE_HOME to your Forms Oracle Home. Example: set ORACLE_HOME=C:\Oracle\Middleware\Oracle_FRHome1
  6. Append the PATH to include the OPatch folder inside %MW_HOME%\oracle_common. Example: set PATH=%PATH%;C:\Oracle\Middleware\oracle_common\OPatch
  7. Run opatch version to make sure that OPatch is working.
  8. Run opatch apply to apply the patch. Making sure that the Middleware home is the correct home for your Forms environment, type in y when it asks if the local system is ready for patching.
  9. When the patch is applied successfully, start up everything in the WebLogic environment.

After running the steps above, Oracle Forms should run normally.

NOTE: If you are using PITSS.CON for Forms 12c, although none of the PITSS.CON jar files will be blocked (they are not signed with MD5), the bundled frmwebutil.jar will still be using the MD5-signed jar file. Please contact PITSS Support at us.support@pitss.com, and PITSS can provide you an updated jar file which is not signed with MD5 as a part of your maintenance agreement.

PITSS.CON’s module, Source Code Analytics, is a powerful tool which is able to fully analyze your application and provide information such as how many lines of code are in your application. In PITSS.CON version 16.2.2, there is a known bug where no results will appear when running the Source Code overview in Source Code Analytics against a pool. However, if you do not run this against a pool, the results will appear normally.

Fortunately, this will be fixed in the next release. In the meantime, a patch is available to fix the bug. Contact PITSS Support, pitssam-support@pitss.com, to obtain the patch. Once you receive the patch, you will need to run it (it is a .wrp file which is run similarly to a SQL script) with the MIG user. The script will create a package body in the MIG user which will fix the problem. NOTE: You must be licensed with the Source Code Analytics module in PITSS.CON in order to receive the patch.

Once the patch is applied, you will be able to see the results against a pool.

NOTE: This bug has only been reported with version 16.2.2. It has not been reported with older versions of PITSS.CON.

There is a known issue in PITSS.CON where reinstalling Source Control (also referred to as Version Control) causes Source Control to no longer appear as an option within PITSS.CON. This has been seen after you have upgraded from an older release to either 16.1 or 16.2.1. Users who upgrade from 15.4.2 or older to 16.2.2 (or users who are using 15.4.2 or older) will not experience the problem. This is only encountered after an upgrade and Source Control is reinstalled (not upgraded). Fixing the problem will require several steps to restore Source Control functionality in PITSS.CON.

  1. Upgrade your PITSS.CON (all users) to version 16.2.2. Do not worry about the Version Control user as we will reinstall it again.
  2. Once all users are upgraded to PITSS.CON 16.2.2, install Version Control again.
  3. In the PITSS.CON 16.2.2 installer, go into the “script_install” folder and locate the script, user_grants.sql. Create a copy of the script and open it in Notepad.
    1. VC_3
  4. In the copied file, replace “&NEW_USER” with your Version Control user (e.g. “VC”). Save and close the file.
    1. VC_4
  5. Open up Command Prompt, and navigate to the folder with the updated script.
    1. VC_5
  6. Launch SQLPLUS with the MIG user and run the script.
    1. VC_6
  7. Log out of SQLPLUS and navigate to the “script_vc” folder located inside the “version_control” folder in the PITSS.CON setup folder.
    1. VC_7
  8. Log into SQLPLUS with the Version Control user and run the script “pitsscon.sql”.
    1. VC_8
  9. When asked to type in the setup folder path, type in the directory where Version Control was installed and press “Enter” (e.g. C:\pitsscon\vc).
    1. VC_9
  10. If you see the error, “ORA-02291: integrity constraint (MIG.SELF_REF) violated – parent key not found”, run the following SQL commands with the Version Control use
    1. INSERT INTO “MIG”.”PITSS_CON” (ID_TOOL, NAME_TOOL, DESC_TOOL, TYPE_TOOL, COLOR) VALUES (’80’, ‘Source Control’, ‘Application and Development Process Management’, ‘FOLDER’, ‘r56g120b184’);
    2. INSERT INTO “MIG”.”PITSS_CON” (ID_TOOL, NAME_TOOL, DESC_TOOL, TYPE_TOOL, PARENT_ID, FORM_ASOC, ICON) VALUES (‘8010’, ‘Source Control’, ‘Secure, version and track changes to application files and Oracle DB objects.’, ‘TOOL’, ’80’, ‘vers_control’, ‘vc_add_files_wb’);
    3. commit;
    4. VC_10
  11. In the PITSS.CON database, query the MIG_PITSSCON_USERS table, and look up (and write down) the USER_ID attributes of all installed PITSS.CON users except for MIG.
    1. VC_11
  12. Return to your SQLPLUS session (as the Version Control user) and run the following command for each PITSS.CON user other than MIG. The <USER_ID> attribute should be the value of the attribute for the PITSS.CON user you are updating.
    1. INSERT INTO “MIG”.”PITSSCON_USERS_RIGHTS” (USER_ID, TOOL_ID, IS_SELECTED) VALUES (‘<USER_ID>’, ‘8010’, ‘Y’);
    2. VC_12
  13. Commit all changes: commit;
    1. VC_13

After making the above changes, the Source Control button should be available again in PITSS.CON.

VC_14

NOTE: For Forms 12c, when you enter Source Control, and you notice that you are unable to log into your Source Control user other than Administrator, there might have been a corruption when upgrading previously to 16.1 or 16.2.1. A full reinstall of PITSS.CON including the MIG user may be required. Please contact PITSS Support at pitssam-support@pitss.com for instructions on how to reinstall MIG and preserve your PITSS.CON license. This particular issue has currently not been seen when upgrading from PITSS.CON 15.4.2 or older to 16.2.2.

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
      webstart=enabled
  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: https://pitss.com/us/2016/05/06/running-oracle-reports-12c-causes-frm-41214-errors/

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”/>
</environment>

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.

Updated: 3/23/16

In PITSS.CON 15.3.1, there is a known bug where if you check the Module Summary for a particular module (form, menu, library, etc.), the right column will be blank:

pit001

The Module Summary can be accessed by going into the Application Analysis module in PITSS.CON and right-clicking on a form to select “Module Summary”. NOTE: The application must be parsed first.

A bug fix is available for this problem. The newest version of PITSS.CON, version 15.4.2, has this bug already patched. Upgrading PITSS.CON 15.4.2 will fix this problem (version 15.4.1 has this problem still). Please contact PITSS Support for how you can upgrade to the latest version of PITSS.CON. However, if you cannot upgrade right away, you may also contact PITSS Support for the SQL script to patch the PITSS.CON repository. The file is called patch_290915.wrp. Once you have received it, you may follow these steps to apply the patch:

  1. Download the patch to the PITSS.CON server or client.
  2. Log into SQLPLUS as each of your PITSS.CON users (except for MIG). NOTE: Please be in the same directory as the patch when launching SQLPLUS.
  3. Run the command to install the patch: start ‘patch_290915.wrp’
  4. Log out of the PITSS.CON user in SQLPLUS and log into your other PITSS.CON users and repeat the process.
  5. Log out of PITSS.CON and log back in.

After completing the steps above, everything should work normally:

AA works

Even when WebUtil and Jacob have been fully configured in the PITSS.CON server environment as documented in https://pitss.com/us/2014/03/20/forms-and-reports-11g-environment-requirements-for-webutil/, 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.

When running a project for upgrading forms in PITSS.CON such as the project to replace the text_io function with webutil.client_text_io, if you happen to encounter the following error:

Search&Replace Error : ORA-06550: line 1, column 7:

PLS-00306: wrong number or types of arguments in call to ‘SYNCRN’

ORA-06550: line 1, column 7:

PL/SQL: Statement ignored.

image

There is a possibility that you might have encountered a bug with the Oracle Database especially if the database version is 11.2.0.4. It has also been noted that this error also happens when you attempt to delete a form from Module Handling. There are two solutions which can be done to fix the problem:

1. Apply Oracle Patch 17501296 to the Oracle Database (version 11.2.0.4 only). More information is provided in Oracle Support note 1586704.1.

2. Re-create the CTXSYS.SYNCRN procedure. The full SQL commands can be found in Oracle Support note 1586704.1.

After applying either one of the two solutions, the problem should no longer occur.

Source: Oracle Support note 1586704.1

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!

image

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.

It is recommended that all PITSS.CON users have an unlimited quota to the tablespace which each PITSS.CON belongs to. If any of the PITSS.CON users do not have an unlimited quota to the tablespace, the following errors could be presented:Insert…ORA-01536: space quota exceeded for tablespace…https://pitss.com/files/2015/05/image.pngTo fix this, all PITSS.CON users including the MIG user should have the following database privilege granted:grant UNLIMITED TABLESPACE to USER;ORalter user USER quota unlimited on PITSS_TABLESPACE;After applying one of the grants above on each PITSS.CON user (including MIG), the error should disappear.Source: Oracle Support note 1084014.6