Published Release Notes

Data schema error on z/OS split schema upgrades from versions before Pega 7.1.8

When upgrading to a split schema on Pega 7.x with IBM DB2 for z/OS, you see an error during the data schema upgrade when the system tries to drop the PRPC_Updatescache procedure. Because triggers on rules tables use PRPC_Updatescache, you must use the ZOSDisableTriggerScripts to disable these triggers before you update the data schema.

1. Follow the instructions in the Pega 7 Platform Upgrade Guide to upgrade the rules schema, but stop immediately before you upgrade the data schema with the upgrade.bat or upgrade.sh script. The Pega 7 Platform Upgrade Guide is on the Support > Deployment Guides page.
2. Copy the contents of the <distribution>\ResourceKit\ZOSDisableTriggerScripts directory into the <distribution>\scripts\ directory.
3. Run fixZosTriggers.bat or fixZosTriggers.sh with the following arguments:
   --action preupgrade
--dataschema <data schema name>
   --oldrulesschema <old rules schema name. If you are upgrading from a single-schema system, this is the data schema name.>
   --newrulesschema <new rules schema name>
   --automaticddl <Optional. Set to true to automatically apply the disable trigger SQL scripts.>

   For example:
   fixZosTriggers --action preupgrade --dataschema pegadata --oldrulesschema pegarules --newrulesschema newrules --automaticddl false

4. If you did not set --automaticddl to true in the previous step, run the <distribution>\schema/disable.sql script to manually disable the trigger SQL scripts.
5. Run the data schema upgrade as described in the Pega 7 Platform Upgrade Guide.

Upgrade changes system name

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.

DB2-LUW database logfile size increase

To avoid running out of logfile space due to large transaction sets during the rule base load of a Pega 7.1.x install, upgrade, or maintenance level update, systems supported by a DB2-LUW database platform should increase the LOGFILSIZ parameter to at least 4096 pages from the default size of 1000 pages.

After the size has been increased, restart the database to ensure that the new setting is loaded into the database correctly.

Unable to drop triggers for frameworks with custom rule tables

For PostgreSQL and z/OS systems, if your deployment includes a framework or application with custom rule tables (such as CPM or any applcation built on CPM), upgrading to Pega 7.1.x causes the DDL application to fail when it tries to drop the following stored procedures:

• z/OS
  • SPPR_RULE_VW_UPDATE
  • PRPC_UPDATESCACHE
• PostgreSQL
  • sppr_base_uc_del.sql
  • sppr_base_uc_ins.sql
  • sppr_base_uc_upd.sql
  • sppr4_fv_ins
  • sppr4_fv_upd

During an upgrade, a number of stored procedures must be dropped and re-added. If the framework or application has custom dependencies that call the stored procedure, this problem is likely to occur.

To correct this issue, drop the framework’s custom dependencies before upgrading and add back the dependencies following the upgrade.

For instructions about how to drop and add the dependencies for your framework and database when this problem occurs, see Troubleshooting: PRPC 7.1.6 upgrade does not drop PRPC_UPDATESCACHE stored procedure.

Existing collections are deprecated

The original implementation of the Collection form is deprecated. Legacy instances in your application remain functional; however, any new instance you create uses the redesigned Collection form. Use the Decision category in the Records Explorer to view all collections available to you.

For guidance on upgrade limitations, see the Deprecated Collection form.

Need to run script before updating Multitenant systems

When updating or upgrading a Multitenant system from Pega 7.1.5 or 7.1.6 to Pega 7.1.7, if that system uses either an Oracle or a PostgreSQL database, you may encounter the error:

“Table must be empty to add column.”

The Multitenant architecture requires an additional column on a number of the PRPC database tables (“pzTenantID”). In Pega 7.1.7, two additional PRPC tables were tenant-qualified: pc_schedule_task and pr_index_schedule_task. The Multitenant column is added to these tables by the update/upgrade process. However, Oracle and PostgreSQL do not allow the addition of a non-null column to an existing table unless the table is empty, so updating or upgrading systems on those databases displays the error detailed above.

To avoid this error, before beginning the update or upgrade, it is necessary to run a script:

• Oracle — OracleMTupgrade.sql
• PostgreSQL — PostgresMTupgrade.sql

For updates, these scripts are located in the /scripts/ddl directory.

For upgrades, these scripts are located in the /Resourcekit/AdditionalUpgradeScripts directory.

Messages are rule resolved by class

As part of the Message form redesign, a class key part was introduced. While this key part is automatically handled as part of an upgrade or migration, it does change the available options you see in message SmartPrompts and how Rule-Message instances are rule resolved.

See Upgrade considerations for existing messages for more information.

Update Existing Applications wizard will run for every upgrade

The upgrade process from a PRPC 5.x or 6.x system to Pega 7.1.7 now automatically runs the Update Existing Applications wizard. This may extend the time that the upgrade process takes to complete, depending on the version you are upgrading from and the number of rules in your application.

Upgrading to Pega 7.1.7 with an Oracle database requires new role permissions

When upgrading or updating from a prior version to Pega 7.1.7, if your system uses an Oracle database, an additional role is required to support the Reversability functionality. In addition to the Oracle privileges specified in the Install Guides, the role SELECT_CATALOG_ROLE is required. Verify that this role is present before beginning the upgrade or update.

Add additional columns to customized work history tables

The standard work history table, pc_history_work, contains two new columns that return the latitude and longitude coordinate location of the action that prompted the history. Mobile devices can display this location as a street address. If you have a customized work history table, add these two columns to it:

• <decimal name="pxLatitude" size="19" scale="9"/>
• <decimal name="pxLongitude" size="19" scale="9"/>