Skip to main content

Published Release Notes

Find release notes for the selected Pega Version and Capability

Browse resolved issues for Platform releases.

This documentation is for non-current versions of Pega Platform. For current release notes, go here.

Supported JDBC drivers

Valid from Pega Version 7.1.1

Pega 7.1.1 supports Java 6 and Java 7 SDKs only. Ensure that the JDBC driver you are using supports those versions of Java. See your database installation or upgrade documentation for additional information.

DatabaseJava 6Java 7
Oracleojdbc6.jarojdbc7.jar
MSQLsqljdbc4.jarsqljdbc4.jar
DB2 LUWdb2jcc4.jardb2jcc4.jar
DB2 z/OS*db2jcc4.jar or jdb2jcc.jar**db2jcc4.jar
PostgreSQLpostgresql-9.1-903.jdbc4.jar***postgresql-9.1-903.jdbc4.jar

* JDBC drivers are only available from the DB2 for z/OS product. Additionally, you need db2jcc_license_cisuz.jar in the same directory as db2jcc4.jar.

** The db2jcc.jar has been deprecated and may not be supported in future releases.

*** This .jar file is required for PostgreSQL version 9.1.x.

Remove JVM settings from prior installations

Valid from Pega Version 7.1.1

JVM memory settings ​defined in the setupDatabase.properties file to support a prior installation need to be removed. 

Memory settings are now handled by the installation program. Duplicating these settings may cause installation or upgrade failures. 

Split schema upgrade instructions missing properties

Valid from Pega Version 7.1.3

If you upgraded from 5.x, 6.x, or 7.x using the instructions in previous versions of the upgrade guide, you may have neglected to set the properties below in your migrateSystem.properties file when you migrated your upgraded schema to the source system:

 

pega.rules.objects.generate=true

pega.rules.objects.apply=true

 

If these properties were not set during an upgrade that splits the schema, your environment does not have the indexes, triggers, and primary keys on the rules tables.

 

To check for this issue, see if the pr4_base and pr4_rule rules tables in your existing rules schema are missing primary keys. If they are, use the SQL scripts in the ResourceKit\MigrationRecoveryScripts directory of the release to cleanup duplicate rules that were created due to this issue. Follow the steps below to run the scripts.

To run the scripts on Microsoft SQL, Oracle, or PostgreSLQ

  1. Take down any app servers using the affected schema.
  2. Backup your database.
  3. Replace all instances of @RULES_SCHEMA in <database>_cleanDups.sql with the name of the schema that contains the pr4_base table.
  4. Run the <database>_cleanDups.sql script on the database with vendor tools (sqlPlus, SQL Server Management Studio, etc).
  5. Replace all instances of @RULES_SCHEMA in <database>_fix_vw_table.sql with the name of the schema that contains the pr4_base table.
  6. Run the <database>_fix_vw_table.sql script on the database with vendor tools (sqlPlus, SQL Server Management Studio, etc).
  7. Generate and apply the ddl using the command line generateDDL command. Check the installation guide for your database or the upgrade guide for details about how to use the generateDDL command line script.
  8. Rebuild the indexes for the tables in your rules schema using vendor tools. This is necessary so that your system runs at an optimum speed.
  9. Optionally upgrade to the latest release, at this point your database is ready to be upgraded or used depending on your needs.

      

To run the scripts on DB2 for LUW or z/OS

  1. Take down any app servers using the affected schema.
  2. Backup your database.
  3. Run the <database>_cleanDups.sql script on the database with vendor tools (UDB CLP, Data Studio, etc) to create the CLEANSE_RULES_DUPS stored procedure.
  4. Run the query Call CLEANSE_RULES_DUPS(‘<rulesSchema>’); where <rulesSchema> is the name of schema that contains the pr4_base table.
  5. After the previous step is complete drop the CLEANSE_RULES_DUPS procedure.
  6. Replace all instances of @RULES_SCHEMA in <database>_fix_vw_table.sql with the name of the schema that contains the pr4_base table.
  7. Run the <database>_fix_vw_table.sql script on the database with vendor tools (UDB CLP, Data Studio, etc).
  8. Generate and apply the ddl using the command line generateDDL command. Check the installation guide for your database or the upgrade guide for details about how to use the generateDDL command line script.
  9. Rebuild the indexes for the tables in your rules schema using vendor tools. This is necessary so that your system runs at an optimum speed.
  10. Optionally upgrade to the latest release. At this point your database is ready to be upgraded or used depending on your needs.

Required DB2 settings for LUW and z/OS

Valid from Pega Version 7.1.1

Installations on DB2 databases for LUW and z/OS require a minimum logging file size (4096) and a default table space page size (32K).

To set the table space page size to 32K:

  1. Stop the system.
  2. Rename one table (“TableX”) to backup (“TableXBackup”).
  3. Create a new table space that uses a 32K page size.
  4. Copy “TableXBackup” to “TableX” in the new table space.
  5. Restart the system and test to verify there are no issues.
  6. Drop the backup table (or keep it for future reference).

Additional information is available in the "Adjusting the log space size in upgraded databases" article: https://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.qb.upgrade.doc%2Fdoc%2Ft0023289.html

No direct upgrade to multitenant setup

Valid from Pega Version 7.1.1

It is not possible to upgrade directly to a multi-tenant setup. A Pega 7 application may be exported and then imported into a multi-tenant system, with the administrator making the decision as to whether this then becomes a tenant system or a shared system.

 

Applications developed in versions prior to Pega 7 must be upgraded to a Pega 7 standard system, and then exported and imported into a multi-tenant system. See the Multitenancy Administration Guide for full details.

Upgrade changes system name

Valid from Pega Version 7.1.1

As of Pega 7.1.7, the following renaming behavior no longer occurs.

The upgrade process renames your system to “PRPC” and modifies any custom requestor rules in your application to use this name. After the upgrade completes, you must apply these changes to revert your system:

  1. Identify all custom requestor rules (browser, batch, app, portal) with access groups that point to prior versions of PRPC.
  2. Open the relevant access groups (for example, PRPC:Unauthenticated and PRPC:Agents) and update the name and version fields to point to the current PegaRULES application.
  3. Reset your system name to its original value. You can set the Dynamic System Setting prconfig/identification/systemName/default or use the Designer Studio > System > Settings > System Name landing page.
  4. Restart the system.

Run cleanup.bat/sh script only before upgrading

Valid from Pega Version 7.1.1

Prior to upgrading the rulebase, you can optionally run the cleanup.bat/sh script to remove older rules from the database.

Run this script before you upgrade your rulebase, or the script may delete needed rulesets. For more information about running the cleanup.bat/sh script, refer to the Upgrade Guide specific to your release version.

Batch database processing improvements

Valid from Pega Version 7.3

Batch database processing has been enhanced to ensure that a constraint violation does not occur when you save transactions to a table with a foreign key dependency. Because batch processing changes the order of save operations, it is disabled for transactions with foreign key dependencies. Disabling batch processing ensures that a record with a foreign key dependency on another record will not be written before the record on which it is dependent.

For more information about how batch database processing works and how to enable and disable it, see Batch processing during database write operations.

Improve cluster security by limiting concurrent operator sessions

Valid from Pega Version 7.3

You can increase the security of a Pega® Platform cluster by limiting the number of concurrent sessions allowed for each operator. Because operators typically do not require multiple concurrent sessions for performing their work, limiting the number of sessions reduces the chance that an unknown or untrusted person could access systems in the cluster. Use the new setting Number of concurrent sessions allowed for each operator on the Production tab of the System Data Instance form to configure the number of concurrent sessions for operators. You must restart your system when you change this setting. You can also create a list of operators by using the presence/maxsessions/operators/whitelist Dynamic System Setting, to which the maximum number of concurrent sessions setting will not apply.

For more information, see System form - Completing the Production tab.

New System Queue Management landing page

Valid from Pega Version 7.3

You can manage your system queues from the new System Queue Management landing page. You can use this landing page to quickly and efficiently debug applications without exiting Designer Studio. In addition to viewing items in a queue, you can defer, remove, and requeue items in a queue, stop items in progress, and view an item's XML.

As a result of this enhancement, the Broken Queue landing page has been removed.

For more information, see System Queue Management landing page.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us