Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

INC-167311 · Issue 646477

Updated upgrade handling for migrating work objects

Resolved in Pega Version 8.3.6

After upgrading from Pega 6.2 to 8.3, the work migrated work objects were missing SLAs due to missed entries in the assignment tables (PC_ASSIGN_WORKLIST/ PC_ASSIGN_WORKBASKET) . The SLA was firing, but the processing failed due to the fact the runtime could not resolve a 'AddHistoryPage' library function. In this case, multiple upgrades of the application dating back to Pega 4 resulted in the runtime context containing older ruleset versions in higher ruleset versions, hiding the underlying Pega 8 version of the rule. For releases prior to Pega 7.3, Rule-Application was stored in pr4_rule and will be migrated to pr4_rule_application during upgrades. However, since Context Upgrade is run before Optimize Newly Exposed Columns, the pyDependsOnName won't always be populated. To resolve this, the system will filter based on the value in the blob rather than the exposed column so there will be a value regardless of the upgrade-from version.

INC-172675 · Issue 649451

Configuration added for extending queue processor timeout

Resolved in Pega Version 8.3.6

Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.

SR-119963 · Issue 176108

Corrected record imports in multitenant environment

Resolved in Pega Version 7.1.8

In the multitenant environment, reimporting an operator record using application -> import was causing an 'IntegrityConstraintViolationException' exception. This was caused by the query not being properly tenant-qualified for the environment, and has been corrected.

SR-121277 · Issue 181001

Deployment user privileges updated for upgrades

Resolved in Pega Version 7.1.8

When attempting to upgrade some installations, the upgrade script was failing while trying to determine the current PRPC version. This was caused by the deployment user lacking the DBA privileges to read/write the tables in the rules and data schema, and has been updated.

SR-121709 · Issue 179068

New default directory setting added to DDL generation

Resolved in Pega Version 7.1.8

If the DDL for a new PRPC installation was generated without using the optional parameter for the file location, the file was created in the root directory. To avoid this, a default gen_dir setting (./schema/generated) has been added to generateDDL.sh to handle cases when the parameter has not been set.

SR-122215 · Issue 180037

Resolved installation errors for DB2 Z/OS with WebSphere

Resolved in Pega Version 7.1.8

A problem was encountered while installing split schema on a DB2 z/OS system with WebSphere. This was caused by an erroneous system setting where the ports to the DB2 database were not open in this environment. While the Admin could correct the environment to open the ports and allow the application server node to connect to the DB2 database, this has been changed in the software to default to the correct settings.

SR-122292 · Issue 182878

Operators and Access Groups are now automatically force re-indexed during import

Resolved in Pega Version 7.1.8

If a number of new OperatorIDs were created and added to two workgroups and then the changes were exported, the new OperatorIDs were present when the file was imported to other environments but a query run against the table PR_INDEX_OPERATOR_WORKGROUP did not incorporate the new IDs. While there was a workaround of manually forcing a re-index during import to fully incorporate the new IDs, the Operators and Access Groups are now automatically force re-indexed during import to ensure data is up to date.

SR-122314 · Issue 178491

Resolved installation errors for DB2 Z/OS with WebSphere

Resolved in Pega Version 7.1.8

A problem was encountered while installing split schema on a DB2 z/OS system with WebSphere. This was caused by an erroneous system setting where the ports to the DB2 database were not open in this environment. While the Admin could correct the environment to open the ports and allow the application server node to connect to the DB2 database, this has been changed in the software to default to the correct settings.

SR-122591 · Issue 183772

Addressed migrate.bat file datetime format issue

Resolved in Pega Version 7.1.8

The script 'migrate.bat' sets up a logfile name based on the current time/date. However, the script was only working when using United States/English as the locale where the format of the '%date%' variable was MM/DD/YYYY, and failed with an obscure error in locales using the DD/MM/YYYY format. There was a local change of hardcoding the 'TIMESTAMP' variable, but this has been resolved by adding the use of a local insensitive datetime from the WMIC utility on Windows systems for the install.bat, upgrade.bat, resume.bat and migrate.bat scripts. The WMIC utility (Windows Management Interface Cmdline) is supported in XP and beyond.

SR-123076 · Issue 186001

Resolved update script error for indexes

Resolved in Pega Version 7.1.8

An update script encountered an error when trying to drop an index, PR4_RULE_VW_PK. This was caused by the DDL being split when an upgrade is being performed, with all drop statements being executed first and then the rest of the statements are run. This changes the order that the DDL needs to run in for changing primary keys, where the table needs to be altered to drop the constraint first, and then have the index dropped. To fix this, all "drop constraints" have been moved to the start, followed by "drops" and "alter" DDLs.

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