Pega 7.1.8 Upgrade Guide for DB2-z/OSl DB2-z/OS: db2zos--dbSchema rules.schema.name Inasingleschema environmentsets theRulesSchema andDataSchema. Inasplit-schema environment,sets theRulesSchema

Pega 7.1.8Upgrade Guide DB2-z/OS

Copyright and trademark noticesCopyright

Copyright © 2015 Pegasystems All rights reserved.

Trademarks

For Pegasystems trademarks and registered trademarks, all rights reserved. Other brand or productnames are trademarks of their respective holders.

Consult the 718thirdpartylicense.pdf file on the installation media for information about the softwaredelivered with the product.

Notices

This publication describes and/or represents products and services of Pegasystems It may contain tradesecrets and proprietary information that are protected by various federal, state, and international laws,and distributed under licenses restricting their use, copying, modification, distribution, or transmittal inany form without prior written authorization of Pegasystems.

This publication is current as of the date of publication only. Changes to the publication may be madefrom time to time at the discretion of Pegasystems This publication remains the property of Pegasystemsand must be returned to it upon request. This publication does not imply any commitment to offer ordeliver the products or services described herein.

This publication may include references to Pegasystems product features that have not been licensed byyou or your company. If you have questions about whether a particular capability is included in yourinstallation, please consult your Pegasystems services consultant.

Although Pegasystems strives for accuracy in its publications, any publication may contain inaccuraciesor typographical errors, as well as technical inaccuracies. Pegasystems may make improvements and/orchanges to the publication at any time.

Any references in this publication to non-Pegasystems websites are provided for convenience only and donot serve as an endorsement of these websites. The materials at these websites are not part of thematerial for Pegasystems products, and use of those websites is at your own risk.

Information concerning non-Pegasystems products was obtained from the suppliers of those products,their publications, or other publicly available sources. Address questions about non-Pegasystemsproducts to the suppliers of those products.

This publication may contain examples used in daily business operations that include the names ofpeople, companies, products, and other third-party publications. Such examples are fictitious and anysimilarity to the names or other data used by an actual business enterprise or individual is coincidental.

Pega 7.1.8 Upgrade Guide DB2-z/OS WebSphere DB-z/OS 2

This information is the property of:

Pegasystems

One Rogers St.

Cambridge, MA 02142-1209

USA

Phone: (617) 374-9600

Fax: (617) 374-9620

www.pega.com

Updated: Tuesday, July 07, 2015


http://www.pega.com/

ContentsCopyright and trademark notices 2

Copyright 2

Trademarks 2

Notices 2

Using Pegasystems documentation 1

Online resources 1

Differences between updates and upgrades 1

Planning your upgrade 3

Single and split-schema systems 3

In-place and out-of-place upgrades 4

Upgrade methods 4

Transport-layer encryption 5

Business Intelligence Exchange (BIX) and Pega 7 product versions 5

Triggers in Pega 7.1.8 5

Typical Enterprise Application upgrade process 6

Application elements and split-schemas 7

Environment considerations 8

System requirements 9

Installation and Upgrade Assistant (IUA) 9

Application server 9

Enabling support for stored procedures 11

Enabling support for User-Defined Functions 12

ZPARM setting recommendations 13

Managing code page translations 14

Database users 15

Deployment user 15

Runtime users 16

Configuring site-dependent properties 16


Allocating space to storage groups 19

Backing up the Pega 7 system and database 19

Optional: removing old rulesets (command-line method) 20

Removing rules automatically 20

Removing rules manually 20

Upgrading from PRPC 5.5 SP1: changing pxAssemblyCacheKey column length 20

Upgrading from PRPC 6.1 SP2 and earlier: running additional scripts 21

Upgrading from PRPC 6.1 SP2 and earlier: moving system settings 22

Editing the setupDatabase.properties file 22

Common properties 23

Additional upgrade properties 24

Editing the file 26

Manually generating and applying DDL 26

Applying schema changes 27

Editing setupDatabase.properties to bypass DDL generation 27

Performing a single-schema upgrade 29

Upgrading the schema 29

Installation and Upgrade Assistant (IUA) 30

Upgrading the Rules Schema from the command line 38

Using JCL 39

Upgrading from a single-schema to split-schema configuration 42

Important notes about migration 43

Migrate script 43

Common properties 44

Custom properties 45

Migration directory properties 45

Operational properties 45

Rules Schema object properties 46

Upgrading with one database 46


Migrating the rules tables with one database 46

Upgrading the migrated Rules Schema 48

Generating Rules Schema objects 52

Upgrading with two databases 53

Creating two new physical schemas on two databases 54

Migrating the rules tables with two databases 54

Upgrading the Rules Schema with two databases 56

Migrating and generating Rules Schema objects 60

Upgrading the Data Schema from the command line 62

Next Steps 63

Upgrading a split-schema configuration 64

Important notes about migration 65

Creating two new physical schemas on two databases 65

Migrating the existing Rules Schema in a split-schema upgrade 66

If accessing one database at a time 68

Upgrading the migrated Rules Schema 68

Using the Installation and Upgrade Assistant to upgrade the migrated Rules Schema 68

Next Step 69

Upgrading the Rules Schema from the command line 69

Using JCL 70

Migrating to the new Rules Schema 72

If accessing one database at a time 74

Upgrading the Data Schema from the command line 74

Next Steps 75

Post-upgrade configuration 76

Creating JNDI binding identifiers 76

WebSphere 76

WebSphere: Deploying the Pega 7 applications 77

Deploying the System Management Application and on-line help 79


Starting the Pega 7 applications 80

Logging in to Pega 7 80

Cleaning up unused tables 81

Next Step 81

Redeploying applications 82

Next Step 83

Configuring Pega 7 84

Logging in to Pega 7 to perform final steps 84

Enabling developer help and the System Management Application 85

Locking and rolling ruleset versions 87

Running the Final Rules Conflict Report 89

Upgrading Pega-supplied applications 90

For Upgrades from Pega 7.1.6 and earlier: Manually building Elasticsearch indexes 90

Completing the post-upgrade configuration 92

Appendix A: setupDatabase.properties 94

Preparing your application server 100

Synchronizing hardware clocks 100

Configuring ports 100

Configuring Web SSO with encrypted assertions 101


Using Pegasystems documentationThis guide describes how to upgrade an existing instance of PRPC version 5.x, 6.x, or 7.x to Pega 7.1.8.

To install a new version of Pega 7.1.8, see the Pega 7.1.8 Installation Guide for your database andapplication server platform. To update from Pega 7.1.x, see the Pega 7.1.8 Update Guide.

Online resourcesThe Pega Discovery Network (PDN) at https://pdn.pega.com is Pegasystems' online documentation andinformation site. To access the latest documentation, navigate to the Support & Resources tab.

l Platform Support Guide: The Platform Support Guide lists the databases, drivers and applicationservers supported for this release. Review the Platform Support Guide before you upgrade Pega 7to verify that your database and application servers are supported.

l Deployment guides: The PDN includes the latest installation, upgrade, and update guides.

l Release notes: Review the important information in the release notes before you continue. Pega7.1.8 introduces new features and functionality which may cause compatibility issues with yourexisting application. You may need to take certain actions before upgrading.

l Updated help files: Download the current prhelp.war file from the Resources & Support tab ofthe PDN, or use the online version: https://pdn.pega.com/sites/pdn.pega.com/files/help_v71/procomhelpmain.htm.

Differences between updates and upgradesAn update is a new distribution kit that contains cumulative fixes and enhancements to the product sincePega 7.1.0; it is not a full product release. In contrast, upgrades are full product releases. The followinglist identifies the major differences between updates and upgrades. Contact Pegasystems GlobalCustomer Support to determine if you can update, or if you need the full upgrade:

l Updates are smaller and faster than upgrades.

l Because a update distribution only contains the cumulative changes since Pega 7.1.0, thedistribution is approximately 50% smaller than a typical full upgrade distribution. Most of thedifference is due to the rules in the PRPC_Rules.jar file.

l Both the update and upgrade consist of a series of ANT targets, executed in sequence.However, the update process omits 3 ANT targets:

l ImportPreupgradeRuntime – this step is only required to run the newest engine, whichis already present on Pega 7.

l UpgradeJavaSyntax - This step upgrades snippets of Java code to be compatible withPega 7.


l RemapDatabaseTables – This step maps some Data-Admin-DB-Tables to PegaDATA,which is not necessary for Pega 7.

l For smaller databases (less than 10 GB), the update process can be up to 25% faster than anupgrade, because there are fewer rules to process and fewer ANT targets to execute. Forlarger databases (greater than 100 GB), the update process is up to 10% faster, because theperformance benefits are diminished by other long-running processes. The performancevaries greatly depending on the size and structure of your database.

l Updates manage superseded hotfixes: The update process contains specialized error handlingfor superseded hotfixes. If your Pega 7 system contains a hotfix that is newer than the hotfixprovided in the update, the update automatically exits. Contact Pegasystems Global CustomerSupport if you need to force the update.

l Many Updates can be reversed. You can reverse an out-of-place, split-schema update on adevelopment system with Oracle, MSSQL, or PostgreSQL. Upgrades and other updates cannot bereversed.

l Updates do not include updated help: The prhelp.war file is not included in an update. You candownload the file from the update page of the PDN or use the online version.

l Updates do not include IAC or BIX: You must upgrade if your system includes IAC or BIX.


Planning your upgradePega 7 supports a run-time mode and a variety of deployment topologies that can impact the choices youmake at different stages of the upgrade. Before beginning, read this section thoroughly.

Note: If you are making changes in your environment as part of the upgrade, do them before upgrading.

Single and split-schema systemsThere are two configuration types for Pega 7:

l Single schema: One schema contains all rules and data objects.

l Split schema: There are two schemas on the same database:

l a Rules Schema – contains Rules tables and associated data and objects

l a Data Schema – contains transaction data, including Work objects

Split-schemas allow you to conduct an in-place upgrade in one environment and then migrate theupgraded objects to other environments. Split-schema configurations are best practices,particularly in critical development environments such as QA, STAGE and PROD.

The following diagram illustrates the difference between a single-schema system and a split-


schema system.

In-place and out-of-place upgradesIn an in-place upgrade, there are no new schemas created. Because in-place upgrades require changesto the schemas in production, they can require significant downtime.

Out-of-place upgrades require a temporary Upgrade Schema which can reside either on the productiondatabase or on a second temporary database. The upgrade scripts run on the temporary schema. Afterthe upgrade is complete, a script moves the updates to the schemas in production. This requiressignificantly shorter down times to the production system. Split-schema systems require out-of-placeupgrades.

Note: An out-of-place upgrade requires that the source and target database vendor and version areidentical. If you plan to update your database, do it either before or after you upgrade Pega 7.

Upgrade methodsYou can upgrade Pega 7 either automatically or manually. This guide includes instructions for bothmethods.


n Automatically – Use the UI-based Installation and Upgrade Assistant (IUA) to automaticallyupgrade either the rulebase or the rulebase and the schema. The IUA leaves intact anycustomizations to the database schema. You can run the IUA once to update both the databaseschema and the rulebase, or manually update the schema and then run the IUA to update only therulebase. The IUA runs on any Windows, Unix, Linux, or zLinux system with Java 6 or higher.

n Manually – Configure the setupDatabase.properties file with your site-specific properties.Then run scripts to upgrade and optionally generate DDL. If you generate DDL, have your DatabaseAdministrator apply the DDL to your schema.

Both methods use a batch process to load the rulebase. Due to the magnitude of rules and other dataobjects which must be loaded, Pegasystems strongly encourages you to run the upgrade on the samenetwork as the database server. If this is not possible, run the upgrade on a machine with fast directaccess to the database server. Do not attempt to run the upgrade on a virtual private network (VPN) or amulti-hop wide area network (WAN).

Transport-layer encryptionPegasystems recommends that you use a strong transport-layer encryption (for example, TLS1.2) tosecure Pega 7 web applications. This requires that you create and install TLS/SSL digital certificates onyour web application server for Pega 7. For more information, see the documentation for your applicationserver.

Business Intelligence Exchange (BIX) and Pega 7product versionsRelease versions of the Business Intelligence Exchange (BIX) product are synchronized with releaseversions of Pega 7. To use the BIX product once you have obtained a license, the version of BIX must bethe same as the version of Pega 7. BIX is included in the full distribution for Pega 7.1.8. See the Pega7.1.8 BIX User Guide for information about installing BIX.

Triggers in Pega 7.1.8Pega 7.1.8 handles triggers differently than previous versions. Triggers that reference the updates cacheand rule view tables will drop when Pega 7.1.8 opens for the first time. Pega 7.1.8 now maintains thesetables. If you have custom triggers that only maintain these tables, do not recreate the trigger. If youhave custom triggers that depend on these tables or are defined on these tables and these triggers alsohave other logic you want to keep, contact Pegasystems Global Customer Support for instructions on howto proceed.


Typical Enterprise Application upgrade processIn this example, a project is initiated to upgrade and enhance an existing PRPC enterprise application torun on Pega 7.1.8. The project requires three environments, each of which with slightly different sizingand uptime requirements:

l Development— a small instance targeted at the development team for rule development and unittesting, with small amounts of transaction data

l User Acceptance Testing (UAT) — a moderate instance which contains a representative sample ofproduction-like data where system and performance testing can be completed to certify theapplication readiness for production

l Production — the full-size deployment that manages the production user population and productiontransaction volumes.

By employing a different upgrade approach for each type of system, you minimize the critical productionoutage window and reduce overall migration risk by ensuring that only tested and proven rules aremoved into production. The basic process design is:

1. Prior to upgrade, ensure that the Development system reflects Production.

2. Upgrade the Development system using the standard in-place upgrade process.

3. Conduct unit testing in Development and correct any issues. Exploit new capabilities that will needto roll into Production.

4. Set up the UAT system as a copy of the Production rulebase with a suitable subset of thetransaction data.

5. When development is complete, upgrade the UAT system:

a. Replace the rulebase with the one from Development; copy the appropriate tables and otherdatabase objects.

b. Replace the base engine classes with those from Development.

6. Test the system and verify that the UAT system executes correctly. Fix any problems inDevelopment and re-upgrade UAT periodically using the same table-copy technique. After testing,the Development and UAT contains identical rulebases.

7. Complete the Production upgrade using the using the same table-copy to replace the PRPC baseengine classes.

At this point, Development becomes the Production Support system, and you can create a newdevelopment system to commence build-out of new capabilities for subsequent release.


Application elements and split-schemasThe heterogeneous upgrade approach made possible by split-schema takes advantage of thefundamental structure of Pega 7 application elements.

A Pega 7 application can be viewed as a collection of logical system components: Pega 7 Rules, storedas rows within a series of database tables plus a series of Base Pega 7 Classes distributed as jar orear files for deployment within an application server. The Pega 7 Rules, Pega-supplied applicationsRules and Customer Rules constitute the rulebase and are represented by a small number of databasetables.

Rules tend to be volatile in a development environment and mostly stable in a production environment.The Rules tables do not grow very large, as they tend to contain tens of thousands of rows, rather thanmillions or billions of rows as in Transaction tables. Upgraded versions of Pega 7 and Pega-suppliedapplications replace the existing PRPC and Framework Rules entirely, leaving Customer Rules intact butrestructured to reflect additional properties or internal format changes required by the new release.

The Pega 7 Engine accesses rules at execution time to dynamically generate Java code which is thenassembled and compiled into Java Generated Classes. As rules are changed, these classes may bediscarded and replaced. The generated classes are stored as rows within database tables and on theapplication server’s file-system using the classpath. Upgrading replaces the base engine classes;generated classes are automatically recreated on demand (First Use Assembly) at execution time.

The transaction information upon which the application executes to do Work -- objects such as cases,correspondence and history –- is contained in separate database tables. Transaction tables and data tendto be small in development and test systems where only sample data is used and often very large inproduction systems. Upgrades seek to avoid changes in the format of transaction data. If a formatrevision is introduced, it is versioned and designed for backward compatibility.

The split-schema technology in Pega 7.1.8 allows Rules and Transaction data to reside in separateschema.


Environment considerationsConsider the following questions.

n Are you changing the supporting systems environment?

If you are updating the version, or changing the vendor of your database server or applicationserver, complete and verify those changes before upgrading Pega. If you upgrade the supportingsoftware at the same time as you upgrade Pega 7, it becomes very difficult to isolate the cause ofany problems that might occur.

n Do you use any Pega-supplied applications as part your application?

If you are using any Pega-supplied applications, confirm whether your Pega-supplied applicationsare supported for this version of Pega 7. You may need to upgrade your versions of the Pega-supplied applications to work with the new version of Pega 7.

n Have you customized the Pega 7 database?

If your site made changes to the Pega 7 schema, you must incorporate those changes into thedatabase after the Upgrade Schema is applied. In particular, you should merge any changes totriggers, views, or stored procedures that you made in the previous version, and review anycustom rules or work tables that you created. The upgrade procedure leaves tables you have addedto the schema in place, but you may need to modify the tables to match changes in Pegasystems'schema.

For example, the upgrade does not change customer rule or work tables. However, if the upgradehas added new columns to rule or work tables, you may need to do the same.

Also verify that schema references in triggers, stored procedures, and views correctly reflect thenew schema names.

n Do you use third-party or custom libraries?

If you have integrated third-party or custom libraries into your system, make sure you have a copyof them before upgrading. The upgrade may overwrite your deployed libraries.

n Does your organization have special requirements for your site?

Your site may have special deployment, integration, or security requirements. Be sure to schedulean early review of the upgrade procedure with the appropriate System and DatabaseAdministrators.


System requirementsBefore you upgrade, check the supported versions of your application server and database. See thePlatform Support Guide on the PDN for a list of supported versions. Ensure that your system meets theminimal requirements describes in this section.

Installation and Upgrade Assistant (IUA)

The minimum systems requirements to run the Installation and Upgrade Assistant (IUA) are:

n Windows or Linux operating system

n 1.25 GB minimum available memory

n 10 GB minimum disk space and at least 8 GB available space in the temporary directory of the rootfile system

n Java Platform, Standard Edition Development Kit (JDK). Set JAVA_HOME to the root directory of theJDK. For Java 8, you may need to remove from the PATH any references to a Java shortcut.

Application server

l 10 GB minimum free disk space

Note: Allocate enough storage to accommodate debugging and other logging requirements.Configure logging to avoid writing logs to the directory that contains the application server run-time components.

Application server memory requirements

Pega 7 runs in memory on Java Virtual Machines (JVMs). This memory is called a “heap”. In general, allactivity is distributed over multiple JVMs (nodes) on the application server.

l Standard suggested development system heap size is 4GB.

l Standard suggested production heap size is 8GB.

l Larger heaps may be advisable if a system is to run applications designed to allow a high numberof concurrent open tasks per session or to cache a large collection of transaction or reference data.

IBM JDKs use a compression option to minimize the cost of large heaps. The option is labeledCompressedRefs. Compression is effective up to 28 GB.

In current 64 bit JVMs, compression is enabled by default. Do not deploy Pega 7 in an environment wherecompression is disabled or where the heap size exceeds the vendor-specific effectiveness limit.


The host application server memory size must be at least 4 GB larger than the Pega 7 heap size. Theadditional 4GB is recommended to allow for Java native memory (stack space, classes, class loaders,and so on), operating system and monitoring tools, and operating system network and file buffering.

The minimum host application server memory size is 8 GB:

4 GB heap + 4 GB for native memory, operating system, and buffering


Enabling support for stored proceduresPega 7 uses native stored procedures, not external stored procedures. Make sure your site supports SQL-based stored procedures.


Enabling support for User-Defined Func-tionsTo support User-Defined Functions (UDF) installed by Pega 7, provide a dedicated Java-enabled WorkLoad Manager (WLM).

n Define the WLM application for Pega 7 to the system WLM with the MVS WLM utility tool.

n Ensure that the new MVS WLM application is part of the MVS WLM Policy that is in effect on theZ/OS L-Par for Pega 7.

You will specify this WLM as the #WLMUDF property in the DB2SiteDependent.properties file found inthe directory <PRPC_HOME>/scripts/config/db2zos. You must refresh this WLM application after theUDFs have been loaded. You can do this from the z/OS console or from a tool like SDSF.


ZPARM setting recommendationsPegasystems recommends the ZPARM settings below. Review these settings with your z/OS systemprogrammer for applicability to your environment.

n CACHEDYN=YES

n CMTSTAT MAY BE INACTIVE OR ACTIVE

n DESCSTAT=YES. (Mandatory)

n IDBACK=200 (Minimum)

n IDFORE=200 (Minimum)

n IDTHION=300 (Minimum if CMTSTAT=INACTIVE)

n LOBVALA=10240 (minimum)

n LOBVALS=2048 (minimum)

n NUMLKTS=5000 (Minimum)

n NUMLKUS=30000 (Minimum)

n OPTIOWGT=ENABLE

n OPTIXOPREF=OFF

n OPTXQB=OFF (TEMPORARY A/O 5/09 DUE TO IBM APARS)

n STATCLUS=ENHANCED

n SKIPUNCI=YES


Managing code page translationsIf you are installing to a UNICODE database, ensure that the appropriate code page translation isconfigured across all tools used on the platform, including FTP, TSO, IBM Data Studio, and SPUFI.


Database usersThis guide refers to the following database users:

l Deployment user: the user who runs the upgrade. After the upgrade, you can remove this user.

l Run-time users: These users perform actions on Pega 7 after the upgrade. In a dual userconfiguration, an Admin user is granted full privileges, and a Base user is granted a smallersubset. Pegasystems recommends the dual user configuration :

l Base user: the user who will run Pega 7. For most run-time operations, Pega 7 uses theBase user and associated data source. The Data Schema should be the default schema forBase users.

l Admin user: an optional user provided to Pega 7 that is preferentially used by certainfeatures that require creating, modifying, or dropping database schema objects includingSystem Management facilities and certain decisioning operations.

Pegasystems recommends that you create the Admin user separate from the Base user, however,you can create a single Base user with both sets of privileges. If there is no separate Admin user,Pega 7 automatically attempts to use the Base user.

Deployment userPega 7 requires z/OS credentials to create the DB2 database and to access it once created. You providethe Deployment user name in the DB2SiteDependent.properties file. You need both the Deploymentusername and associated password to configure data access for Pega 7 in your application server.

These credentials need to have permissions to perform the following actions:

n Log onto IBM’s Time Sharing Option (TSO)

n Run z/OS batch jobs

n Allocate Datasets (both z/OS and zFS)

n Log onto IBM’s Unix System Services (USS)

n Update OMVS (USS) memory size to 2 GB (RACF example ASSIZEMAX 2147483647)

n Grant DB2 database CREATE, DROP and ALTER authority (at the database level and for all objectswithin the database)

n Grant DB2 database INSERT, UPDATE and DELETE authority.

n Grant DB2 database access to create and execute stored procedures and user-defined functions.


Runtime usersEnsure that you have two users, Base and Admin, whose only difference is the database authoritygranted.

n Admin user: The database owner, #DBOWNR, with permissions to issue SQL CREATE, DROP andALTER commands against the Pega 7 database instance.

n Base user: The database user, #DBUSER, with permissions to issue SQL INSERT, DELETE,UPDATE, and SELECT statements.

Configuring site-dependent propertiesUsing the table of recommended values below as guidance, update the DB2SiteDependent.propertiesfile with the correct values for your site. This file is located in the following folder:

<PRPC_HOME>/scripts/config/db2zos

Note the following:

n #DBNAME is the database name assigned by your DBA.

The value you select here will be substituted everywhere in the target libraries that DB2 expects avalid database name. Pega 7 has no special requirements for this name other than that it beacceptable to DB2. This installation procedure assumes that the entire database can be droppedand recreated. Carefully consider placing any non-PEGASYSTEMS related database objects in thisschema.

n #DBOWNR will be the database owner for the libraries copy of the Pega 7 database.

This installation procedure assumes that #DBOWNR has DBADM on #DBNAME either directlythrough a grant or indirectly by processing a Secondary Authorization ID. The application serverscan log on to this database using #DBOWNR. The installation procedure described here will createa PLAN_TABLE owned by #DBOWNR.

n #DBUSER will be the ID of the user who accesses Pega 7 database. If your site strictly enforcessegregation of duties, this userid can be used to run the Pega 7 applications. #DBUSER can onlyissue DML (select, insert, delete, update) commands while #DBOWNR can issue DDL as well asDML.

By default, the Pega 7 installer will take the following actions:

n Disable the lock escalation feature.


If you prefer to enable lock escalation, configure #BLBLCM and #TSPLCM to a non-zero positiveinteger before tailoring the libraries. Refer to your DB2 for z/OS manuals for details on settingthese properties.

n Assign separate storage groups for table spaces, index spaces, and LOB table spaces.

Should you wish to keep all three object types in a single storage group, set #BLBSTG, #IDXSTG,and #TSPSTG to the same value.

n Segregate each object type into its own buffer pool.

For the LOB buffer pools, set Deferred Write Threshold DWQT to zero. By default, the upgradedefines all LOB table spaces as LOG YES.

n Use the #DBOWNR userid to connect to the database.

Variable with default value Your choice Description

LOB Parameters

#BLBBFP=BP32K1 Blob 32 K Blob buffer pool. This must be different from thetable space.

#BLBLCK=LOB Blob lock size

#BLBLCM=0 Blob lock maximum

#BLBLOG=YES Blob logging

#BLBPRI=14400 Blob primary allocation in pages

#BLBSEC=7200 Blob secondary allocation in pages

#BLBSTG=Blob.Storage.Group.Name Blob DB2 storage group

Index Parameters

#IDXBP=BP2 Index buffer pool

#IDXPRI=7200 Index primary allocation in pages

#IDXSEC=7200 Index secondary allocation in pages

#IDXSTG=Index.Storage.Group.Name Index DB2 storage group

Table Space Parameters

#TSPLCK=PAGE Table space lock size

#TSPLCM=0 Table space lock maximum

#TSPPRI=14000 Table space primary allocation in pages

#TSPSEC=7200 Table space secondary allocation in pages

#TSPSTG=Table.Storage.Group.Name Table space storage group

#TS32BP=BP32K Table space 32K buffer pool. This must be different from theBlob buffer pool.

Database Access Parameters


Variable with default value Your choice Description

#CCSID=EBCDIC EBCDIC or UNICODE

#DBNAME=PEGDB Database name

#DBOWNR=PEGDBDBO Database owner

#DBUSER=PEGDB Pega 7 database user

#WLMUDF Name of the dedicated Java-enabled Work Load Manager(WLM) for UDFs


Allocating space to storage groupsIdentify the database space requirements for an initial install.

n Ensure that the Storage Groups and Buffer pools selected for use by Pega 7 are created, andpermission is granted to the #DBOWNR userid to use them.

n Allocate a minimum of 5 GB to the database and allow the database to grow. This minimum sizeallows you to load the initial Pega 7 rulebase and do simple development.

Backing up the Pega 7 system and databaseBefore upgrading, be sure to back up the existing database, your applications and the system itself:

Note: The upgrade procedure modifies both the Data schema and the Rules data; make sure you use abackup procedure that preserves both.

1. Verify that all rules are checked in.

2. Shut down the Pega 7 application server.

3. Use your database utilities to back up the Pega 7 database.

4. If you have edited any of the following Pega 7 configuration files in the APP- INF\classes directoryof an EAR deployment or the WEB-INF\classes directory of a WAR deployment, include these in thebackup:

l prbootstrap.properties

l prconfig.xml

l prlogging.xml

l web.xml

l pegarules.keyring or any .keyring files with other names

Note: For upgrades from PRPC 6.1 SP2 or earlier if you have added System Settings to yourprbootstrap.properties or prconfig.xml files, convert them to Dynamic-System-Settings Data-instances. See Upgrading from PRPC 6.1 SP2 and earlier: moving system settings.

5. Back up any third-party or custom JAR files that you installed. Redeploying the Pega 7 applicationsmay delete these from your application server.


Optional: removing old rulesets (command-linemethod)Prior to upgrading the rulebase, you can optionally remove older rules from the database. In most cases,removing older rules decreases the overall upgrade time. Once configured, the process permanentlyremoves rules older than n, where n is the current major-minor version that you are upgrading from. Forexample, if you are upgrading from 6.2 SP2 (06-02-20) to 7.1.8, this feature removes rules of version06-01-99 and older.

Run the rulebase cleanup process from the command line automatically or manually.

Removing rules automatically1. Perform these steps as the Deployment user.

2. In the setupDatabase.properties file, set the property run.ruleset.cleanup=true.

3. Run the cleanup.bat/.sh script. When the cleanup script runs, it generates and applies the SQL toyour database.

Removing rules manually1. Perform these steps as the Deployment user.

2. In the setupDatabase.properties file, set the property run.ruleset.cleanup=false.

3. Run the cleanup.bat/.sh script. When the cleanup script runs, it generates a SQL script that youcan apply to your database using native database vendor tools.

4. Apply the SQL to your database.

CAUTION: Running this command after you complete the upgrade may delete needed Rulesets.

Upgrading from PRPC 5.5 SP1: changingpxAssemblyCacheKey column lengthIn PRPD 5.5 SP1, the pr4_log_rule_usage_details table includes the column pxAssemblyCacheKey of typevarchar2(2048). The upgrade process adds an index to this column. On DB2-z/OS, the combined length ofthe column and index is too long.

Check the size of the pxAssemblyCacheKey column. If it is not 255 characters, you must change the sizeof the column to avoid an upgrade error. The method depends on whether or not the data in this table isused for licensing:


l If the data in the pr4_log_rule_usage_details table is not needed for licensing:

1. Truncate the contents of the pr4_log_rule_usage_details table.

2. Alter the pxAssemblyCacheKey column to be 255 characters.

l If the data in the pr4_log_rule_usage_details table is needed for licensing:

1. Copy the contents of the pr4_log_rule_usage_details table to a new table, pr4_log_rule_usage_details_temp.

2. Recreate the pr4_log_rule_usage_details table and set the pxAssemblyCacheKey columnsize to 255 characters.

3. Reload the data from the pr4_log_usage_details_temp table into the pr4_log_rule_usage_details table, truncating the content of the pxAssemblyCacheKey column to fit into255 characters.

Upgrading from PRPC 6.1 SP2 and earlier: runningadditional scriptsWhen upgrading from any release prior to PRPC 6.2, you must run additional scripts to update the rulesetcolumns:

1. Navigate to ResourceKit\AdditionalUpgradeScripts and locate the scripts for your database:

l <database>_rulesetversion_columns_data.sql

l <database>_rulesetversion_columns_rule.sql scripts

where <database> is your database

2. Run the scripts:

l For single schema environments, run both scripts.

l For split schema environments:

l Run <database>_rulesetversion_columns_data.sql against the Data Schema.

l Run <database>_rulesetversion_columns_rule.sql against the Rules Schema.

Depending upon the database platform and the size of the database these scripts may require significanttime and resources to execute.


Upgrading from PRPC 6.1 SP2 and earlier: movingsystem settingsIf you are upgrading from 6.1 SP2 or earlier, move any System Settings you may have added to theprconfig.xml or prbootstrap.properties configuration files to Dynamic System Settings (Data-Admin-System-Settings). Settings in env elements in your current prconfig.xml orprbootstrap.properties files continue to work, and this task can be done at any time.

Pegasystems provides a utility to move the settings automatically from the configuration files to Data-Admin-System-Settings instances. See "Upgrading Configuration Settings from Prior Versions to Version6.2" in the Configuration Settings Reference Guide on the PDN for details. Note that the instructions onhow to run this utility are the same for Pega 7.1.8 as they are for Version 6.2.

Moving these settings to the database has several advantages.

l Since the settings are stored as Data- instances, they can be read from the database by all nodesrunning your installation. All nodes will have the same setting values, unlike the values in theprconfig.xml file, which apply only to the node where that file is located.

l The values of the Dynamic System settings can be viewed and modified from Designer Studio.Values stored in the configuration files must be changed by editing the file, which sometimesrequires restarting the application nodes.

Editing the setupDatabase.properties fileSkip this section if your deployment meets both these criteria:

l You will use the IUA to upgrade.

l You will allow the upgrade process to automatically apply the schema changes.

If your deployment does not meet both these criteria, follow the steps in this section to edit thesetupDatabase.properties file. Follow these instructions if you plan to use the command line scripts toupgrade or if you plan to use the generateddl script to generate a DDL file of schema changes. TheDeployment user should perform these actions.

The setupDatabase.properties file is used by the scripts that update the database schema and therulebase. These scripts use the setupDatabase.properties file:

l The upgrade.bat/sh script deploys the most recent version of Pega 7.

l The generateddl.bat/sh script generates a SQL file to manually apply schema changes.

See Appendix A: setupDatabase.properties for a sample edited file.


Common properties

These properties specify the settings needed to connect to the database:

l The script arguments column lists the arguments for the generateddl.bat/sh script.

l The setupDatabase.properties column lists the corresponding file property.

generateddl script argu-ment setupDatabase.properties Description

--dbType pega.database.type

Database vendortype. Enter thecorrect databasevendor:

l DB2-z/OS:db2zos

--dbSchema rules.schema.name

In a single schemaenvironment setsthe Rules Schemaand Data Schema.

In a split-schemaenvironment, setsthe Rules Schemaonly.

--dbDataSchema data.schema.name

Optional: Spe-cified for a splitschema envir-onment only. Setsthe Data Schema forthe environment.

--mtSystem multitenant.system

Is this a MultitenantSystem? true/false

DB2-z/OS does notsupport MultitenantSystems.

--dbuser pega.jdbc.username User name of theDeployment user.

--dbpassword pega.jdbc.password

Password of theDeployment user. Ifyou plan to useencryptedpasswords, leavethis blank.

--dburl pega.jdbc.urlDatabase jdbc url


generateddl script argu-ment setupDatabase.properties Description

--driverJar pega.jdbc.driver.jar

Path and file nameof the the followingjar files:d-b2jcc4.jar anddb2jcc_license_cisuz.jar

--driverClass pega.jdbc.driver.class Class of the jdbcdriver

--tempdir user.temp.dir

Optional: the loc-ation of the temp dir-ectory. If you leavethis blank, Pega 7uses the default.Pegasystems recom-mends that you setthis to C:\TEMP.

pega.zos.properties z/OS site specific properties file.

The full path andfile name to thepega.zos.propertiesfile.

Additional upgrade properties

The following table describes additional properties in the setupDatabase.properties file that you mayneed to edit later in the process. Do not modify these properties now.

Property Description

user.temp.dirThe temporary directory for theDeployment user. The default isused if this property is left blank.

bypass.pega.schema

Setting this property to true willbypass the creation of the UpgradeSchema and implies that theupgrade DDL has already beenapplied.Leaving this property blank or set-ting it to false will generate andapply the Upgrade Schema.

bypass.udf.generation

Generate UDF will be skipped if thisproperty is set to true. Leave thisproperty blank if you need to gen-erate the UDF.

run.assembler

Generate the assembled javaclasses during the upgrade pro-cess. Defaults to false. Theassembled classes are imported aspart of the standard upgrade pro-cess.

import.assembled.classes Load Assembled Java classes. Trueor false value.



rebuild.indexes

Rebuild Database Rules Indexesafter Rules Load to improve Data-base Access Performance. It can beexecuted manually by running thestored procedure SPPR_REBUILD_INDEXES. The default valuedepends on the database.

system.name

The system name uniquely iden-tifies a single Pega 7 system. Sincemultiple systems may reference thesame database, it is important thateach system has a unique name inorder to distinguish them from eachother.

production.level

The installation or upgrade processgenerates the above system nameand a production level. Valid valuesinclude integer values (1-5):

l 5 = production;

l 4 = preproduction;

l 3 = test;

l 2 = development;

l 1 = experimental

update.existing.applications

Specifies whether to run the updatewizard after upgrade. Default valueis false. Regardless of the setting,update.existing.applications runsfor all upgrades of systems prior toPega 7.1.0.

Update wizard can be run fromupgrade scripts, prpcUtils, or bydirectly launching in Pega 7 afterupgrade.

import.codeset.nameimport.codeset.version

Determines whether the systemloads Hotfixes as part of theupgrade. The Hotfix path can be asingle file, multiple comma delim-ited files or a directory. Files can beloaded through prpcUtils or by dir-ectly launching in Pega 7 after theupgrade. The path must be relativeto the /scripts directory.

build.conclusions Pre-build the Pega Conclusions.

db2zos.udf.wlm Workload manager to load UDFs intodb2zos.

run.ruleset.cleanup

Run RuleSet Cleanup. Generate andexecute a SQL script to clean oldrulesets and their rules from thesystem. If you would like to only gen-



erate the script, not execute it, seecleanup.bat or cleanup.sh script.

generate.benchmarksbenchmark.warning.threshold.valuebenchmark.kill.threshold.value

Uncomment to generate timingbenchmarks.

reversal.schema.file.name Schema file name to be used forreversal

Editing the file

To edit the setupDatabase.properties file:

1. Open the file setupDatabase.properties for editing. This file is located in the scripts folder ofyour distribution.

2. Specify the properties for your system. For each property, add the appropriate value after theequals sign.

3. Save and close the file.

Manually generating and applying DDLSkip this section if you do not need to generate a DDL file or if you plan to use the JCL to generate aDDL file.

A generateddl script is provided for Windows (generateddl.bat) and Linux (generateddl.sh) in the<PRPC_HOME>\scripts directory. This script automatically renders the platform-specific DDL andwrites the output to a file. You can then view and edit the file or directly apply it using native or third-party database management tools. Both scripts work identically and accept the arguments noted inEditing the setupDatabase.properties file.

Use the following convention:

generateddl.bat --action upgrade --arg1 [value] --arg2 [value] ..... --argn [value]

Note: You must supply the --action parameter to the script. You can also supply an --outputDirectoryparameter. If no additional arguments are passed to the script, the script defaults to the values of theproperties set in the setupDatabase.properties file. See Appendix A: setupDatabase.properties for asample edited file.

To use the script:

1. Perform these steps as the Deployment user.

2. If you have not already done so, edit the setupDatabase.properties file. See Editing the


setupDatabase.properties file.

3. Open a command prompt and navigate to the scripts directory.

4. Type generateddl.bat or generateddl.sh passing in the required --action upgrade parameter.For example:

l Single-schema: #generateddl.bat --action upgrade --dbSchema <Rules Schema>

l Split-schema: #generateddl.bat --action upgrade --dbSchema <Rules Schema> --dbDataSchema <Data Schema>

If you do not pass another value for --outputDirectory, the script writes the output to the followingdirectory:

<PRPC_HOME>\schema\generated

Note: The output directory is deleted and recreated each time the generateddl script executes. To savea copy of the DDL, rename the directory before you run the script.

Applying schema changes

Before you continue, have your DBA apply the schema changes.

Editing setupDatabase.properties to bypass DDL generation

After your DBA applies the changes to your database, set the property bypass.pega.schema=true inthe setupDatabase.properties file. Then, when you run upgrade.bat/sh, the system does not try to applya schema that is already present. Doing so would cause the upgrade to fail.


Performing a single-schema upgradeThis section describes how to perform a single-schema upgrade from PRPC Version 5.x, 6.x, or 7.x toPega 7.1.8 after you have prepared the database. Each of these steps is described in detail later in thisguide.

1. If you plan to use the manual command-line method, and you have not yet done so, edit thesetupDatabase.properties file. See Editing the setupDatabase.properties file.

2. Ensure that the application server is down.

3. Allocate space to storage groups.

4. Optionally generate DDL and have your Database Administrator manually apply the changes toyour database. See Manually generating and applying DDL.

5. Upgrade the database and the rulebase. See Upgrading the schema.

6. Upgrade the applications:

a. Review the application server configuration described in the Pega 7.1.8 Installation Guide foryour application.

b. Undeploy the current Java applications:

l prweb.war or the prpc_*.ear file appropriate to your application server

l prsysmgmt.war

l prhelp.war.

c. Deploy the new Pega 7 applications

7. Configure Pega 7; log into the system and complete the upgrade configuration steps.

Upgrading the schemaYour existing schema needs to be updated to be compatible with Pega 7.1.8. The schema can be updatedin one of three ways. Each method is designed to preserve any prior customization to the database.

n Automatically – the UI-based Installation and Upgrade Assistant automatically updates theschema leaving any customizations intact. See Running the Installation and Upgrade Assistant.

n Manually – Use the upgrade.bat/sh command-line script. See Upgrading the Rules Schema fromthe command line.

n JCL – JCL member scripts are provided so that the schema can be generated and applied on thez/OS system itself. See Using JCL.

These methods require a JDBC connection to the database and can be run from any Windows, Unix, Linuxor zLinux computer with Java 6 or higher. The Deployment user should perform these actions.


Note: Prior to loading the rulebase, the Installation and Upgrade Assistant or upgrade script attempts tovalidate that each database table space has a buffer pool size large enough to accommodate thegenerated SQL DDL. The utility will generate a report and terminate if it finds any table space thatrequires an increased buffer pool size. The report identifies all table spaces requiring an increased bufferpool size. Once the DBA corrects the table space buffer pool issues, rerun the tool.

Installation and Upgrade Assistant (IUA)

Because of the large volume of data loaded by the Installation and Upgrade Assistant (IUA), you shouldrun the IUA or command-line scripts on the same network as the database server. If this is not possible,run the tool on a system with fast, direct access to the database server.

The upgrade creates a series of log files in <PRPC _HOME>\scripts\logs. If you encounter a problemwhile running the upgrade, copy the logs to a safe location before re-running the installer. The IUA re-creates this directory each time the upgrade runs.

Note: The <PRPC_HOME>\.checksum directory provides an MD5 checksum for each the file in thedistribution. To verify that the distribution has been downloaded correctly, calculate a checksum usingthe Jacksum tool at www.jonelo.de/java/jacksum/.

For example: if your distribution was unzipped to <PRPC_HOME>:

java -jar jacksum.jar -m -a md5 -r -p -O outputFile.md5 <PRPC_HOME>

Compare outputFile.md5 to the md5 file located in <PRPC_HOME>\.checksum. The checksumvalues should be identical.

Running the Installation and Upgrade Assistant (IUA)

Before running the IUA, make sure that your system meets the requirements.


1. Start the IUA; either double-click the PRPC_Setup.jar file or run the command java –jar -Xmx2048m –jar PRPC_Setup.jar

Note: If JAR files are not associated with Java commands on your system, start the IUA from thecommand-line. In a command-line console, change to the directory containing PRPC_Setup.jar, andtype java -Xmx2048m -jar PRPC_Setup.jar.


The IUA loads and the install icon appears in your task bar.

2. Click Next to display the License Agreement.


3. Review the License Agreement and click Accept.

4. On the Installer Mode screen, choose Upgrade and click Next.


5. Choose your Database Type and click Next.

6. Configure the database connection. The JDBC drivers allow the Pega 7 application to communicatewith the database.


Note: Some of the fields on the Database Connection screen – in particular the JDBC DriverClass Name and the Database JDBC URL - are pre-populated based on the type of database youselected. If you edit these or any other fields on this screen, and then later decide to change thedatabase type, the IUA may not populate the fields correctly. If this occurs, enter the correct fieldvalues as documented below, or exit and re-launch the IUA to select the intended database type.

l JDBC Driver Class Name — Verify that the pre-populated value is accurate:

com.ibm.db2.jcc.DB2Driver

l JDBC Driver JAR Files— Click Select Jar to browse to the appropriate driver files for yourdatabase type and version. See the Platform Support Guide on the PDN for a list of drivers.DB2-z/OS requires two JDBC jar files to establish a connection: db2jcc4.jar and db2jcc_licenseZ_cisuz.jar.

l Site Dependent Properties File — Enter the full path of the site dependent properties fileor click Select File to browse and select the file.

l Database JDBC URL — Verify that the pre-populated value is accurate. Replaceservername and dbname with the values for your system:


jdbc:db2://<servername>:50000/<dbname>

l Database Username and Password— Enter the user name and password you created forthe Deployment user on your database.

l Rules Schema Name — Enter the name of the Rules Schema in the database.

l Data Schema Name — Enter the name of the Data Schema in the database. For single-schema configurations, and all upgrades from PRPC 5.x and 6.x, the Data Schema Name isidentical to the Rules Schema Name.

7. Click Test Connection. If the connection is not successful, review your connection information,correct any errors and retest. When the connection is successful, click Next to choose how to applythe database schema.

8. Specify whether to bypass automatic DDL generation. By default, the IUA is designed toautomatically generate and apply the schema DDL to your database. If you already manuallygenerated the DDL and your Database Administrator has already applied the DDL, select theBypass Automatic DDL Application option. Otherwise, leave the box unchecked. Click Next.


9. Select the Upgrade Options and click Next:

l Check the Run rulebase cleanup box to permanently remove rules older than n, where n isthe current major-minor version that you are upgrading from. For example, if you areupgrading from 6.2 SP2 (06-02-20), this feature removes rules of version 06-01-99 andolder.

l Check Rebuild database indexes if you want the IUA to rebuild the database indexesautomatically at the end of the Rulebase Load process. The IUA rebuilds the databaseindexes to ensure good performance in the upgraded system. The amount of time thisprocess adds to the upgrade procedure depends on the size of your database

10. Click Start to begin the Rulebase Load.


Upgrade logs automatically appear in this window. The log is also stored in the <distributionimage>/scripts/logs directory.

The rulebase load time can last for several hours and will vary widely based on network proximityto the database server. The log window may appear inactive when the IUA is processing largerfiles. When the load is complete, the following screen opens.


If there is an issue, copy the log from the temporary directory to a safe location before exiting theIUA.

11. Click Back to return to the previous screen and then click Exit to close the IUA.

Next Steps

Continue at Post-upgrade configuration.

Upgrading the Rules Schema from the command line

To use the upgrade script, configure the setupDatabase.properties file and run upgrade.bat/sh.

1. If you have not done so already, edit the setupDatabase.properties file. See Editing thesetupDatabase.properties file. Use the Upgrade Schema name for both the rules.schema.name anddata.schema.name.


3. Run upgrade.bat/sh.


The upgrade of the rulebase can take several hours, depending on the proximity of the database to thesystem running the script.

Note: Command line output is automatically written to a file in the <PRPC_HOME>\scripts\logsdirectory. If you encounter any errors or issues when running the script, save the contents of thisdirectory to another location before you re-run the script.

Next Steps


Using JCL

Skip this section if you plan to use the Installation and Upgrade Assistant or the command line scripts toupgrade.

Pega 7 includes JCL scripts to setup the z/OS environment to run the various shell scripts and javaprograms packaged with your distribution. The JCL scripts use IBM’s batch z/OS launchers for runningUnix System Services in z/OS and JZOS (Java on z/OS).

The JCL scripts used to upgrade DB2-z/OS are delivered in the library PEGA.DB2.JCLLIB:

<PRPC_HOME>/scripts/config/db2zos/libraries/PEGA.DB2.JCLLIB

The library includes these members:

l SETUPZOS - This member includes:

n shell script set statements to establish the fully-qualified directory paths for the Java 6 – 64Bit System

n DB2 JDBC Jar members

n IBM’s JZOS system

n DB2 JDBC connection properties

n path to the Pega 7 distribution

l SITEDIRS - Contains the JCL set statements used to establish the fully qualified zFS workingdirectory, the fully qualified zFS directory to the Pega Distribution Root and the MVS fully qualifiedlibrary name of the Pega 7 JCL library that contains these members.

l PU01EXP - This job expands the Pega 7 distribution into the zFS directory specified by theSITEDIRS script.

l PI01DDL - This job creates the SQL DDL statements required to upgrade the DB2 database objects


for the Pega 7 system.

l PI01ENV - This is the environment script for the job PI01DDL. Do not modify this script.

l PI02SQL- This job applies the SQL DLL statements generated by PI01DDL creating the necessarytables, triggers, views, indexes and stored procedures required to upgrade the Pega 7 system.

l PI02ENV - This is the environment script for the job PI02SQL. Do not modify this script.

JCL Procedure

The JCL procedure for Pega 7 uses a combination of both MVS libraries and zFS members.

To follow this procedure, you need a user id with OMVS access, and 5 GB of available storage.

1. If you have not already done so, update the DB2SiteDependent.properties file in the directory<PRPC_HOME>/scripts/config/db2zos. Add these values:

l #WLMUDF - dedicated Java-enabled Work Load Manager (WLM)

l database username - the name of the user with z/OS credentials

l database password

2. FTP the Pega 7.1.8 distribution image to the z/OS server.

3. Sign into the z/OS server from an OMVS terminal.

4. Use either USS services or the ISPF panel to expand the distribution image.

5. Make your current directory the directory that contains the distribution image and run PU01EXP.

6. Allocate an MVS library to hold the 5 library members:

<Pega7_HOME>/scripts/config/db2zos/libraries/PEGA.DB2.JCLLIB

Note: Name the library PEGA.DB2.JCLLIB with the DCB attributes of FB/80/4000. Then, useISPF 3.3 to copy the file into the library as members. If you use another library name, manuallychange the library name in each member to the new name.

7. Using the ISPF editor, review and edit the members SETUPZOS and SITEDIRS one at a time,updating the file paths. The instructions for editing these members are included in the comments.Remember to save the member each time, then Submit.

Note: SETUPZOS contains DSN statements for the JCL. SITEDIRS contains pointers to membersthat the shell scripts will need. These are provided as a common place to set these values.

8. Using the ISPF editor, review and edit the members PI01DDL and PI02SQL one at a time,


updating the comments by the JCL. Remember to save the member each time, then submit.

9. Run PI01DDL.

Note: This member generates the database DDL statements that will be used to create the DB2Pega 7 database. Review the output for accuracy.

10. Run PI02SQL to apply the DDL.

Next Steps



Upgrading from a single-schema to split-schema configurationThis section describes how to upgrade your system from a single-schema to split-schema configuration.To upgrade from a split-schema configuration, see Upgrading from a Split-Configuration.

This section includes an overview of the process, followed by descriptions of the migrate and upgradescripts, and steps for upgrading with one database or two databases.

To upgrade to a split-schema configuration, first conduct an out-of-place upgrade to a temporary,inactive schema that is not actively serving any consumers. Upgrade the temporary schema and migratethe changes to a new Rules Schema and the existing Data Schema. This approach imposes minimaldowntime on the system to be upgraded. This is ideal for customers with strict downtime requirements,especially in Production or other critical environments.

For this discussion, physical database refers to the database location. The database is the logicaldatabase within the physical database.

This upgrade involves three schemas. For example:

l Data Schema - your current schema which includes both rules and data. After the upgrade, thisbecomes just the Data Schema.

l Rules Schema- the new Rules Schema.

l Upgrade Schema - If you have two databases, you also create a temporary schema to stage theupgrade. This can be on your existing database, or on a separate database.

This is the generic process for upgrading to a split-schema configuration:

1. Use the migrate script to migrate the Rules table and associated objects from the existing DataSchema to the temporary Upgrade Schema. Running the migration script creates the newschemas.

2. Upgrade the Upgrade Schema. You can use the Installation and Upgrade Assistant, run theupgrade.bat/sh script, or use JCL.

3. Use the migrate script to migrate the updated rules to the new Rules Schema. This schemacontains only Rules tables and database objects.

4. Upgrade the Data Schema and apply any DDL changes. The Data Schema is now used only forData and Work objects. Rules tables will still exist in this Data Schema, but after the upgrade, theyare no longer used.

5. Discard the Upgrade Schema.

6. Reconfigure the application server to access both Data and Rules schemas.

The diagram below displays the schemas for a two-database upgrade.


Important notes about migrationl Ensure that no rules are developed in your system until after the upgrade has completed. Duringthis process, the original system can still be used, but new rules should not be created. Any rulescreated after the migration will be lost when you switch to the upgraded Rules Schema, but theData Schema retains all new data and work.

l Always maintain a backup of your system, especially before performing an upgrade.

l Except for creating new schemas, it is highly recommended that you use the migration scripts andnot database vendor tools.

l In production environments, upgrades should always be performed on external systems. Ifperformance is not a factor, you can create the "New Rules" schema in the original database.

l The upgrade process requires additional space approximately equal to twice the size of your RulesSchema. Ensure that your database can allocate enough space to perform this upgrade. Someversions of Microsoft SQL Server Express have a 10 GB limit, which may not fit large systems.

Migrate scriptThe scriptmigrate.bat/shmigrates the Rules objects from the Data and Rules Schema in your pre-7.1system to a new Rules Schema, and generates and applies Rules Schema objects after upgrading theRules Schema. Edit themigrateSystem.properties file to configure the migrate script. TheDeployment user performs the migrations.


Note: Pegasystems strongly recommends that you use themigrate.bat/.sh script to perform thesesteps. The use of vendor tools is not recommended.

The Migrate script is designed to automate many aspects of the data movement process, including:

n Export of appropriate tables and data objects from the source system schema;

n Generation and application of DDL to the target system schema;

n Import of appropriate tables and data objects to the target system schema.

Common properties

The following common properties must be configured in themigrateSystem.properties file to log on tothe databases used for each schema. If you are using one database for each schema, these propertieswill be the same for each step. However, if you are using different databases for the Rules Schema andthe Upgrade Schema, these properties will be different, depending on which database the schema ishosted on.

The table below lists the common properties, their descriptions, and valid values. Source propertiesapply to the system being migrated from, and target properties apply to the system being migrated to.Set the properties by adding the appropriate value after the equals sign in the properties file. Set theproperties by adding the appropriate value after the equals sign in the properties file.


pega.source.jdbc.driver.jarpega.target.jdbc.driver.jar

The path to the JDBC jar file. For databases that uses multiple JDBC driverfiles (such as DB2), you may specify semicolon separated values.

pega.source.jdbc.driver.classpega.target.jdbc.driver.class

Valid values are:

l Oracle 10g (Type 4): oracle.jdbc.OracleDriver

l IBM DB/2 Type 4: com.ibm.db2.jcc.DB2Driver

l SQL Server 2008: com.microsoft.sqlserver.jdbc.SQLServerDriver

l PostgreSQL 9.1.4: org.postgresql.Driver

pega.source.database.typepega.target.database.type Valid values are: mssql, oracledate, udb, db2zos, or postgres.

pega.source.jdbc.urlpega.target.jdbc.url

Valid values are:

l Oracle 10g (Type 4):jdbc:oracle:thin:@//localhost:1521/dbName

l IBM DB/2 z / OS: jdbc:db2://localhost:50000/dbName

l IBM DB/2 Type 4:jdbc:db2://localhost:50000/dbName:fullyMaterializeLobData=true;fullyMaterializeInputStreams=true;progressiveStreaming=2;useJDBC4ColumnNameAndLabelSemantics=2;

l SQL Server 2008:jdbc:sqlserver://localhost:1433;selectMethod=cursor;sendStringParametersAsUnicode=false



l PostgreSQL 9.1.4: jdbc:postgresql://localhost:5432/dbName

pega.source.jdbc.usernamepega.target.jdbc.username Deployment user name.

pega.source.jdbc.passwordpega.target.jdbc.password Deployment user password.

Custom properties

The following properties are used during migration to configure custom settings.


pega.source.jdbc.custom.connection.propertiespega.target.jdbc.custom.connection.properties Any custom connection properties.

pega.source.data.schemapega.target.data.schemapega.source.rules.schemapega.target.rules.schema

Used to correctly schema qualify tables in stored procedures, views and trig-gers. These properties are not required if migrating before performing anupgrade.

pega.target.bypass.udf Set this property to bypass udf generation on the system.

pega.target.zos.properties

The location of the db2zos site specific properties file. Only used if the targetsystem is a db2zos database. Set to:

config/db2zos/DB2SiteDependent.properties

Migration directory properties

Set the directories for migration objects.


pega.bulkmover.directoryThe directory where output from the bulk mover will be stored. This directory will be clearedwhen pega.bulkmover.unload.db is run. This property must be set if eitherpega.bulkmover.unload.db or pega.bulkmover.load.db is set to true.

pega.migrate.temp.directory The location where a temporary directory will be created for use by the migrate system utilities.

Operational properties

Use the following properties to migrate Rules objects. Set to true or false.


pega.move.admin.table Set to true if migrating before an upgrade. If true admin tables required for an upgrade aremigrated with the rules tables.

pega.clone.generate.xml Generate an XML document containing the definitions of tables in the source system. It will befound in the schema directory of the distribution image.

pega.clone.create.ddl Create DDL from the generated xml document. This DDL can be used to create copies of rule tablesfound on the source system.

pega.clone.apply.ddl Apply the generated clone DDL to the target system.

pega.bulkmover.unload.db Unload the data from the rules tables on the source system into the pega.bulkmover.directory.



pega.bulkmover.load.db Load the data onto the target system from the pega.bulkmover.directory.

Rules Schema object properties

This table describes operations that should only be run when migrating upgraded rules:


pega.rules.objects.generateGenerate the Rules Schema objects (views, triggers, procedures, and functions). The objects willbe created in the pega.target.rules.schema but will contain references to thepega.target.data.schema where appropriate.

pega.rules.objects.apply Apply the Rules Schema objects (views, triggers, procedures, and functions) to pega.tar-get.rules.schema.

Upgrading with one databaseFollow the instructions in this section to perform an out-of-place upgrade with one database.

You can also perform this upgrade using two different systems and databases. Additionally, if you areupgrading a production system, you may want to use this setup. See Upgrading with two databases fordetails.

Migrating the rules tables with one database

Use the migrate script to migrate the rules tables and other required database objects from the existingschema (the Data Schema in the picture above) to the new schema. You will also use this script later togenerate and apply rules objects after the upgrade. The Deployment user performs the migrations.

To use the migrate script:

1. Use a text editor to edit themigrateSystem.properties. The file is located in the scriptsdirectory of your distribution.

<PRPC_HOME>\scripts\migrateSystem.properties

2. Configure the properties used to access the source system.

l pega.source.jdbc.driver.jar=<source.jar>

l pega.source.jdbc.driver.class=<source.class>

l pega.source.database.type=<Database vendor type>Enter db2zos.

l pega.source.jdbc.url=<source.url>


l pega.source.jdbc.username=<Deployment user name>

l pega.source.jdbc.password=<Deployment user password>

l pega.source.rules.schema=<original data schema name>

3. Configure the properties used to access the target system.

l pega.target.jdbc.driver.jar=<target.jar>

l pega.target.jdbc.driver.class=<target.class>

l pega.target.database.type=<Database vendor type>Enter db2zos.

l pega.target.jdbc.url=<target.url>

l pega.target.jdbc.username=<Deployment user name>

l pega.target.jdbc.password=<Deployment user password>

l pega.target.data.schema=<Original data schema name>

l pega.target.rules.schema=<new rules schema name>

4. If you are upgrading from a 7.1 split schema system to a newer version with split schema, specifythe source Data Schema using the pega.source.data.schema property. See "Upgrading from aSplit-to-Split Configuration" for details.

5. Configure file system directories required by the utility:

l pega.bulkmover.directory=<output directory>

l pega.migrate.temp.directory=<temporary directory>

6. Enable operations to be performed by the utility. It is recommended to set the value for each ofthese properties to true, as shown below.

l pega.move.admin.table=true

l pega.clone.generate.xml=true

l pega.clone.create.ddl=true

l pega.clone.apply.ddl=true

l pega.bulkmover.unload.db=true

l pega.bulkmover.load.db=true


7. Save the script.

8. Open a command prompt, and navigate to the scripts directory.

9. Typemigrate.bat or ./migrate.sh to run the script.


Next Step

Continue at Upgrading the migrated Rules Schema to upgrade the Rules Schema on the Upgrade Schema.

Upgrading the migrated Rules Schema

Next, upgrade the migrated Rules Schema. Use one of these methods:

l Installation and Upgrade Assistant (IUA)

l Command line script upgrade.bat/sh


Using the Installation and Upgrade Assistant to upgrade the migrated Rules Schema

If you prefer a UI-based approach, use the Installation and Upgrade Assistant (IUA). The procedure forrunning the assistant is similar to the one described in Running the Installation and Upgrade Assistantwith one exception:

On the Database Connection screen, you will specify the Upgrade Schema name for both the RulesSchema Name and Data Schema Name fields. For example:


Next Step

Continue at Generating Rules Schema objects.









Next Step

Continue at Migrating to the new Rules Schema.

Using JCL














l PI01DDL - This job creates the SQL DDL statements required to upgrade the DB2 database objectsfor the Pega 7 system.


l PI02SQL- This job applies the SQL DLL statements generated by PI01DDL creating the necessary


tables, triggers, views, indexes and stored procedures required to upgrade the Pega 7 system.


JCL Procedure






l database password










8. Using the ISPF editor, review and edit the members PI01DDL and PI02SQL one at a time,updating the comments by the JCL. Remember to save the member each time, then submit.

9. Run PI01DDL.




Next Steps


Generating Rules Schema objects

Use the migrate script to generate Rules Schema objects so the Rules Schema operates properly. To dothis, you use the samemigrate.bat or migrate.sh script you used to migrate the rules tables from theData Schema to the Upgrade Schema, but you configure the script differently. The Deployment userperforms the migrations.

Note: Pegasystems strongly recommends that you use themigrate.bat/.sh script. The use of vendortools to manage this step is not recommended.

Follow these steps to generate Rules Schema objects:



2. Keep most of the values you used when you migrated the rules tables, except the target DataSchema and the source Rules Schema. In this case, the target is the original Data Schema on yoursingle-schema system and the source is the upgraded rules schema. Change these values:

l pega.target.data.schema=<Data Schema>

l pega.source.rules.schema=<New Rules Schema>

Note: If the target Data Schema is blank, the Rules Schema is used by default.

3. Because you are not migrating the Rules Schema again, set all of the Operational properties tofalse:

l pega.move.admin.table=false

l pega.clone.generate.xml=false

l pega.clone.create.ddl=false

l pega.clone.apply.ddl=false


l pega.bulkmover.unload.db=false

l pega.bulkmover.load.db=false

4. Set the following properties to true to generate and apply rules objects:

l pega.rules.objects.generate=true

l pega.rules.objects.apply=true

5. Save the properties file.




Upgrading with two databasesAs an alternative to the above, you can set up your Upgrade Schema on a different database server, asshown below. In this case, the source and target systems are different, so be sure to configure thecommon properties correctly to access each database.


In this setup, you migrate Rules objects from the Data Schema to another database to be upgraded(called the "Upgrade Schema" in the figure). Then you migrate the updated rules from the UpgradeSchema into a new Rules Schema on the database containing the Data Schema.

Creating two new physical schemas on two databases

To use two databases for an out-of-place upgrade, create a new database and two new schemas, forexample:

l Create the TEMPORARY database of the same type and version as your current database.

l Create the Upgrade Schema in the TEMPORARY database.

l Create the new Rules Schema in your existing PRODUCTION database.

Next Step

Continue at Migrating the rules tables with two databases.

Migrating the rules tables with two databases

Use the migrate script to migrate the rules tables and other required database objects from the existingschema (the Data Schema in the picture above) to the new schema. You will also use this script later togenerate and apply rules objects after the upgrade. The Deployment user performs the migrations.





l pega.source.jdbc.driver.jar=<source.jar>

l pega.source.jdbc.driver.class=<source.class>






l pega.source.rules.schema=<original data schema name>


l pega.target.jdbc.driver.jar=<target.jar>

l pega.target.jdbc.driver.class=<target.class>



l pega.targte.jdbc.username=<Deployment user name>


l pega.target.rules.schema=<new rules schema name>

4. If you are upgrading from a 7.1 split schema system to a newer version with split schema, specifythe source Data Schema using the pega.source.data.schema property. See "Upgrading from aSplit-to-Split Configuration" for details.




6. Enable operations to be performed by the utility. It is recommended to set the value for each ofthese properties to true, as shown below.







7. Save the script.




If accessing one database at a time

If the system can only access one database at a time (for example, if there is a firewall between the twoservers), run the migration script twice: first on a system that can access the source database, and thenwhere it can access the target database.

When exporting from the source database, set the following properties to true:

l pega.move.admin.table

l pega.clone.generate.xml

l pega.clone.create.ddl

l pega.bulkmover.unload.db

When importing to the target database, set only the following properties to true:

l pega.clone.apply.ddl

l pega.bulkmover.load.db

Make sure the system has access to the pega.bulkmover temporary directory and the DDL generatedfrom the source database.

Next Step

Continue at Upgrading the Rules Schema with two databases.

Upgrading the Rules Schema with two databases

Next, upgrade the migrated Rules Schema. Use one of these methods:





Using the Installation and Upgrade Assistant to upgrade the migrated Rules Schema



Next Step

Continue at Migrating and generating Rules Schema objects.









Next Step


Using JCL












l SITEDIRS - Contains the JCL set statements used to establish the fully qualified zFS working


directory, the fully qualified zFS directory to the Pega Distribution Root and the MVS fully qualifiedlibrary name of the Pega 7 JCL library that contains these members.


l PI01DDL - This job creates the SQL DDL statements required to upgrade the DB2 database objectsfor the Pega 7 system.




JCL Procedure






l database password








7. Using the ISPF editor, review and edit the members SETUPZOS and SITEDIRS one at a time,


updating the file paths. The instructions for editing these members are included in the comments.Remember to save the member each time, then Submit.


8. Using the ISPF editor, review and edit the members PI01DDL and PI02SQL one at a time,updating the comments by the JCL. Remember to save the member each time, then submit.

9. Run PI01DDL.



Next Steps


Migrating and generating Rules Schema objects

Use the migrate script to migrate and generate the Upgrade Schema into the Rules Schema. TheDeployment user performs the migrations:

1. Use a text editor to edit the migrateSystem.properties. The file is located in the scripts directory ofyour distribution.



l pega.source.jdbc.driver.jar=<Upgrade Schema jar>

l pega.source.jdbc.driver.class=<Upgrade Schema class>





l pega.source.rules.schema=<Upgrade Schema >

3. Configure the properties used to access the target system. The target system in this step is the


Rules Schema on the system that was used for the initial schema export.

l pega.target.jdbc.driver.jar=<Rules Schema jar>

l pega.target.jdbc.driver.class=<Rules Schema class>





l pega.target.rules.schema=<new Rules Schema name>

4. Configure the target data schema. In this case, the target is the original Data Schema on yoursingle-schema system.

pega.target.data.schema=<Data Schema>

Note: If the target data schema is blank, the Rules Schema is used by default.

5. Configure the temporary file system directories required by the utility.



6. If the system has access to both the PRODUCTION and TEMPORARY databases, enable theoperations to be performed by the utility as shown below..


















When exporting from the source database, set the following properties to true:




When importing to the target database, set only the following properties to true:



l pega.rules.objects.generate

l pega.rules.objects.apply


Upgrading the Data Schema from the command lineTo use the command line option to upgrade the Data Schema:


1. If you have not done so already, edit the setupDatabase.properties file. See Editing thesetupDatabase.properties file.

l rules.schema.name: points to your new Rules schema

l data.schema.name: points to your original Data schema

2. Disable Pega 7 access to the Data schema.


4. Type upgrade.bat or ./upgrade.sh for Linux, passing in the —dataOnly argument and trueparameter. For example:

>upgrade.bat --dataOnly true


Next Steps



Upgrading a split-schema configurationThis section describes how to upgrade your split-schema configuration. The process is similar toupgrading a system from a single- to a split-schema and uses the migration and upgrade utilities for Pega7.

This upgrade involves four schemas. For example:

l Data Schema - your current Data Schema

l Rules Schema - your current Rules Schema

l Upgrade Schema - a temporary schema used for staging the upgrade

l New Rules Schema- the new Rules Schema

The generic process for upgrading to a split-schema configuration can be summarized in the followingsteps:

1. Create two blank schema, for example Upgrade Schema and New Rules Schema.

2. Use the migrate script to migrate the current Rules Schema to the Upgrade Schema.

3. Upgrade the Upgrade Schema. Either use the Installation and Upgrade Assistant or theupgrade.bat/sh script.

4. Use the migrate script to migrate the Upgrade Schema to the New Rules Schema.

5. Upgrade the Data Schema and apply any DDL changes.

6. Discard the Upgrade Schema.

7. Reconfigure the application server.

The diagram below displays the schemas used in this scenario.


Important notes about migrationl Ensure that no rules are developed in your system until after the upgrade has completed. Duringthis process, the original system can still be used, but new rules should not be created. Any rulescreated after the migration will be lost when you switch to the upgraded Rules Schema, but theData Schema retains all new data and work.

l Always maintain a backup of your system, especially before performing an upgrade.

l Except for creating new schemas, it is highly recommended that you use the migration scripts andnot database vendor tools.

l In production environments, upgrades should always be performed on external systems. Ifperformance is not a factor, you can create the "New Rules" schema in the original database.

l The upgrade process requires additional space approximately equal to twice the size of your RulesSchema. Ensure that your database can allocate enough space to perform this upgrade. Someversions of Microsoft SQL Server Express have a 10 GB limit, which may not fit large systems.

Creating two new physical schemas on two data-basesTo use two databases for an out-of-place upgrade, create a new database and two new schemas, forexample:


l Create the TEMPORARY database of the same type and version as your current database.

l Create the Upgrade Schema in the TEMPORARY database.

l Create the New Rules Schema in your existing PRODUCTION database.

Migrating the existing Rules Schema in a split-schema upgradeUse the migrate script to migrate the rules tables and other required database objects from the existingschema to the new schema. You will also use this script later to generate and apply rules objects afterthe upgrade. The Deployment user performs the migrations.





l pega.source.jdbc.driver.jar=<path to your current db2jcc4.jar and db2jcc_license_cisuz.jarfiles>

l pega.source.jdbc.driver.class=<your database driver class>


l pega.source.jdbc.url=<URL of your current database>



l pega.source.rules.schema=<original rules schema name>

l pega.source.data.schema=<original data schema name>



l pega.target.jdbc.driver.class=<your database driver class>



l pega.target.jdbc.url=<URL of the Temporary database>



l pega.target.rules.schema=<Upgrade Schema>

l pega.target.data.schema=< > Leave this blank.

4. If you are upgrading from a 7.1 split schema system to a newer version with split schema, specifythe source data schema using the pega.source.data.schema property. See "Upgrading from a Split-to-Split Configuration" for details.




6. If the system has access to both the PRODUCTION and TEMPORARY databases, enable theoperations to be performed by the utility as shown below.














When exporting from the PRODUCTION database, set the following properties to true:





When importing to the TEMPORARY database, set only the following properties to true:




Upgrading the migrated Rules SchemaNext, upgrade the migrated Rules Schema. Use one of these methods:




Using the Installation and Upgrade Assistant to upgrade themigrated Rules Schema




Next Step










Next Step


Using JCL














l PI01DDL - This job creates the SQL DDL statements required to upgrade the DB2 database objects


for the Pega 7 system.




JCL Procedure






l database password










8. Using the ISPF editor, review and edit the members PI01DDL and PI02SQL one at a time,


updating the comments by the JCL. Remember to save the member each time, then submit.

9. Run PI01DDL.



Next Steps


Migrating to the new Rules SchemaNow that the Rules Schema is upgraded, migrate it back to the original database. Use themigrate.bat/migrate.sh scripts again for this process, but with different properties in themigrateSystem.properties file. The Deployment user performs the migrations.






l pega.source.jdbc.driver.class=<your database driver class>


l pega.source.jdbc.url=<URL of your current database>



l pega.source.rules.schema=<Upgrade Schema name>


l pega.source.data.schema=< > Leave this blank.



l pega.target.jdbc.driver.class=<your database driver class>

l pega.target.database.type=<Database vendor type>Enter udb,mssql, oracledate, or postgres.

l pega.target.jdbc.url=<URL of the PRODUCTION database>



l pega.target.rules.schema=<New Rules Schema name>This schema should be empty.

l pega.target.data.schema=<Original Data Schema>




5. If the system has access to both the PRODUCTION and TEMPORARY databases, enable operationsto be performed by the utility as shown below.














When exporting from the TEMPORARY database, set the following properties to true:





When importing to the PRODUCTION database, set only the following properties to true:



l pega.rules.objects.generate

l pega.rules.objects.apply


Upgrading the Data Schema from the command lineTo use the command line option to upgrade the Data Schema:

1. If you have not done so already, edit the setupDatabase.properties file. See Editing thesetupDatabase.properties file.

l rules.schema.name: points to your new Rules schema

l data.schema.name: points to your original Data schema

2. Disable Pega 7 access to the Data schema.



4. Type upgrade.bat or ./upgrade.sh for Linux, passing in the —dataOnly argument and trueparameter. For example:

>upgrade.bat --dataOnly true


Next Steps



Post-upgrade configurationThis section describes additional tasks to perform after you finish upgrading the system.

Creating JNDI binding identifiersModify the JDNI settings so the data source uses the correct schemas. Create these binding identifiers ifthey do not already exist:

l One that points to the PegaRULES default schema

l One that points to the PegaDATA default schema

l Optional: one that points to PegaRULESdbAdmin

l Optional: one that points to database/databases/PegaDATA/dataSourceAdmin

To use the upgraded Rules Schema, you must reconfigure the Application Server. The process is differentfor each Application Server. At a minimum:

1. Replace all references to the old Rules Schema with the new Rules Schema name (for example,71RULES -> 718RULES)

2. Remove the old Pega 7 application and WAR/EAR file, and replace it with the new WAR/EAR in thearchives directory of the distribution.

When this step is complete, you can start Pega 7 using the new system.

WebSphere

To create new Binding Identifiers:

1. In the Administrative console, select Environment > Naming > Name Space Bindings to display theName space bindings page.

2. Select the correct Scope for your environment and click New.

3. For the binding type, select String and click Next.

4. On the Step 2: Specify basic properties screen, enter the following values:

l Binding identifier: PegaRULESDefaultSchema

l Name in the name space relative to lookup name prefix:prconfig/database/databases/PegaRULES/defaultSchema

l String Value: the schema name of your Pega Database Rules Schema.


5. Click Next.

6. On the Summary panel, click Finish.

7. Click Save in the Messages box at the top of the Name Space Bindings screen.

8. Repeat steps 2 -6 for the Data Schema except: On the Step 2: Specify basic properties screen,enter the following values for the Data Schema.

l Binding identifier: PegaDATADefaultSchema

l Name in the name space relative to lookup name prefix:prconfig/database/databases/PegaDATA/defaultSchema

l String Value: the schema name of your Pega Database Data Schema

9. Click Save in the Messages box at the top of the Name Space Bindings screen.

WebSphere: Deploying the Pega 7 applicationsWebSphere automatically starts the application, prweb.war or prpc_j2ee14_ws.ear, when it is deployed.When the application starts , you may see error messages for missing resources and references. Ignorethese messages. You supply these resources as you complete the installation process. Be sure to stopthe application after deploying.

To deploy the Pega 7 application using the prpc_j2ee14_ws.ear file included in your distribution media:

1. Make sure the WebSphere Application Server is running. Log into the Administration console.

2. From the left frame, select Applications > New Application.

3. Click New Enterprise Application.

4. Click the Browse button and select prpc_j2ee14_ws.ear from the archives directory on yourinstallation media. Click Open and then click Next.

WebSphere displays Preparing for the application installation.

5. Select Detailed - Show me all installation options and parameters.

This option allows you to review all the installation options for the application, including the defaultbindings and resource mappings.

6. Click + to expand Choose to generate default bindings and mappings.

7. Complete this page.


l Check Generate Default Bindings.

l Check Use default virtual host name for Web and SIP modules.

l Leave the other default settings and click Next.

WebSphere displays Application Security Warnings.

8. Scroll to the bottom on this page and click Continue to display a wizard where you can specifyinstallation options.

This security file allows Pega 7 to run when J2EE Security Checking is enabled.

This section of the installation process is a series of steps under the general heading of InstallNew Application.

9. For Step One, accept the defaults and click Next.

10. Continue through the next steps, either accepting the defaults, or customizing for yourorganization, as needed.

11. Locate the step where youMap resource references to resources.

12. In the Map resource references to resources step, there are three rows that include"explicittempdir" in the Resource Reference column. Use the find tool on your browser to find thecorrect rows for:

l EJB EngineCMT bean

l EngineBMT beans

l prweb.war module

13. For each of the three rows, change the value in the Target Resource JNDI Name field to thetemp directory, for example url/initialization/explicittempdir. This maps the location youspecified in the URL provider you created to the corresponding Resource Reference in theapplication, so that the application will use the location for the PegaTempDir. Use the Browsebutton and Apply to change each of the three values.

14. Click Next

Depending on your configuration, you may see a set of warnings related to missing resourcereferences. These warnings are informational. Review the warnings and then continue.

Note: These are resource references that are defined in web.xml, the deployment configurationfiles for the application, but not mapped to resource definitions in your application. In the page,Map resources to references, they are mapped to the Target Resource JNDI Name


url/pega/none, indicating that they are not used. Pegasystems provides these references forJ2EE compliance, but their use is optional. You can continue with the deployment.

15. At the bottom of the Warnings page, click Continue.

16. Click Next as needed to continue through the remaining steps, accepting the defaults, or settingthem to the requirements of your organization.

17. On the Summary page, click Finish.

The system begins installing the EAR file, which can take a few minutes. When the installationcompletes successfully, WebSphere displays a success message similar to thefollowing: "Application Pega 7 installed successfully."

18. Click Save directly to the master configuration.

Deploying the System Management Application and on-line help

In addition to the Pega 7 application, you must also deploy the online help application — prhelp.war andthe System Management application — prsysmgmt.war.

For more details on the System Management Application, refer to the System Management ApplicationReference Guide on the PDN.

Complete the following steps to deploy prsysmgmt.war and prhelp.war.

1. In the Preparing for the application installation screen, select Local file system and click Browse toselect the prsysmgmt file.

If you do not see the Preparing for the application installation screen, from the left frame, selectApplications > New Application.

2. Click Browse and navigate to select the application war file, either prsysmgmt.war orprsysmgmt.ear from the archive directory in your installation media.

3. Click Open and then click Next to begin the installation.

4. Click Detailed - Show all installation options and parameters.

5. Expand Choose to generate default bindings and mappings.

6. Select the Generate Default Bindings check box, and leave the other settings at their defaults.

7. Click Next.

You may see some security warnings.

8. Click Continue to bypass the warnings.


WebSphere displays the Install New Application wizard.

9. Accept the defaults and click Next until you get to the Map context roots for Web Modulesstep.

10. In the Map context roots for Web Modules step, enter prsysmgmt as the context root, andclick Next.

11. Accept the defaults and click Next on the remaining steps.

12. On the Summary page, click Finish.

WebSphere displays a message, Installing . . ., and updates it with information during the install.When the installation is complete, you see the following message:

13. Click the Save link to save the changes to the master configuration and return to the first page ofthe installation series.

14. Repeat steps 2 - 13 to deploy prhelp.war using the same procedure as prsysmgmt.war.

Use the name of the file, prhelp, as the context root and deploy to the same server.

Note: If you want to allow limited access to the SMA, use the Map Special Subjects dropdown to selectAll Authenticated in Application’s Realm, or click Map Users to assign the role to specific users.

Starting the Pega 7 applicationsEnsure that the application server is running and start the prsysmgmt, prweb, and Pega 7 applications.

To start the application:

1. In the WebSphere Administrative Console, select Applications > Application Types > WebSphereenterprise applications.

2. Select the three applications and click Start.

The application status turns green and the system displays a success message.

Logging in to Pega 7To test the installation, log into the Pega 7 web application, replacing the <server> and <port> valueswith your specific values.

http://<server>:<port>/prweb/PRServlet

Use the following credentials to log in:


l User ID: [email protected]

l Password: install

After logging in, Pega 7 automatically launches a process to index the rules in the system to support full-text search. While this process is running, you may notice some delay in the responsiveness of the Pega7 user interface. This process usually takes from 10 to 15 minutes to complete depending on your systemconfiguration.

If the index ends without generating an error message, the installation is successful.

Cleaning up unused tablesPegasystems recommends that you drop unused rules tables in the Data Schema after running a splitschema upgrade. If you upgraded with one database, also drop unused rules tables in the Rules schema.

1. Verify that you have the correct privileges to view and edit the Optimize Schema landing page. Setthese to true:

l ViewAndOptimizeSchema

l Dynamic System Setting (DSS) databases/AutoDBSchemaChanges

l ViewSchemaOnImport

l SchemaImport

See the PDN article How to set privileges to restrict database schema changes generated fromProcess Commander (https://pdn.pega.com/node/2103) for more information.

2. To open the optimize schema wizard, click the Designer Studio menu option > System > Database> Modify Schema.

3. Select the PegaDATA database.

4. Click view the unused tables to display a list of Pega 7 tables without Class mappings. Eitherselect the ones you want to delete and click Proceed with Changes to have Pega 7 drop thetables, or drop them manually in your database.

5. Repeat steps 3 and 4 for the PegaRULES database.

Next Step

Continue at Redeploying applications.


Redeploying applicationsPerform the following steps to redeploy the Pega 7 components.

1. Make sure that these applications are not running:

l prweb.war or the prpc_*.ear file for your application server

l prhelp.war

l prsysmgmt.war

2. Use your application server administrative utilities to remove each of the current versions of theapplications.

WebSphere

a. In theWebSphere Administrative console, navigate to Applications > Application Types> WebSphere Enterprise Applications to see a list of the installed applications. Select each ofthe applications and click Uninstall.

b. When you click Uninstall on a package, WebSphere empties the ./installedApps/*directories. To complete the uninstall, delete the following directories:

l ./config/temp/*

l ./wstemp/*

l ./temp

3. Delete everything in the temporary directory. This is the directory that you specified for the JNDIlocation url/initialization/explicittempdir.

4. Follow the procedures in the Pega 7.1.8 Installation Guide for your application server to deploy thePega 7 applications to your application server.

Note:When you restart the server following deployment of the archives, the first node you bringup becomes the default search node. If you are deployed in a multi-node environment, the searchnode is node 1 and must be started first.

l prweb.war or the appropriate prpc_*.ear file

l prsysmgmt.war — the System Management application

l prhelp.war — the Developer Online Help application

Note: Do not start the redeployed Pega 7 applications while the rulebase update process is runningin the IUA. By default, your application server may start the Pega 7 applications automaticallywhen they are deployed. If you deploy and start the Pega 7 applications before creating the


database, the applications generate an error and fail to start. This error is not harmful, and youwill be able to restart the application successfully when the database is available.

5. Verify that any third-party or custom JAR files that you installed with the Pega 7 applications arestill in place on the application server. Restore any that may have been deleted when the Pega 7components were redeployed.

Next Step

Continue at Configuring Pega 7.


Configuring Pega 7After updating the rulebase and redeploying the applications, follow these procedures to complete theupgrade.

Logging in to Pega 7 to perform final steps1. Stop and restart the application server.

2. Ensure that all the Pega 7 applications have started.

l prweb.war or prpc_ *.ear file

l prhelp.war

l prsysmgmt.war

3. Access Pega 7 through a browser. Enter the URL for the Pega 7 application:http://<server>:<portnumber>/<context_root>.

For example: http://prpc-server:8080/prweb

The Pega 7 log in window opens.


4. Log in using the following credentials.

UserID: [email protected]

Password: install

The Developer portal displays a welcome message in theWhat’s New section of the page. Thispage provides links to tools you will use to develop Pega 7 applications.

Enabling developer help and the System Management Application

Set the URLs that are used to access Help and the System Management Application.


1. Select the Designer Studio > System > Settings > URLs menu item.

2. Complete this page to specify the URLs to access the Online Help (prhelp.war)and SystemManagement (prsysmgmt.war) applications, and the Public Link URL used for Directed Web Access.

Note: Each of these fields takes the form: http://<host>:<port>/<application>. If you specifylocalhost as the <host>, only users logged into the same server on which the applications aredeployed are able to access the applications. In most cases you should supply the actual servername to allow access to the applications from other computers.

Edit the Online Help URL field to contain the specific server host and port for the prhelpapplication. For example: http://<your_host>:<your_port>/prhelp

Edit the Public Link URL field to contain the specific server host and port that will be used by theDirected Web Access feature. For example: http://<your_host>:<your_port>/prweb

Note: Directed Web Access (DWA) enables external users that do not have an Operator ID toprocess an assignment in your application on a one-time basis. The URL you specify here isprovided in an email to the external users to access Pega 7 and may identify a proxy server. Formore information, see the PDN article How to Implement Directed Web Access.

Edit the SMA URL field to contain the specific server host and port for the System ManagementApplication. For example:

http://<host>:<port>/prsysmgmt/getnodes.action

3. Click Submit.


4. Log out and log back in for these changes to take effect.

Locking and rolling ruleset versions

After an upgrade, lock your existing RuleSets and roll them into new versions before continuingdevelopment. This ensures that future development is based on the upgraded Pega RuleSets and thatyour applications consistently reference the latest features.

Note: The upgrade process automatically updates any prerequisite for Pega-ProCom to the highestversion of the RuleSet in the system.

1. Select the Designer Studio > Application > Structure >Other Applications menu item.

This page displays all applications in the system and lists the RuleSets and RuleSet versions thatmake up each application including those inherited from any built-on applications.

2. For each application, click Lock and Roll to display the application page.


Select + next to Prerequisites to see the ruleset version prerequisites for the application ruleset.Click the name of the ruleset version to open and modify its rule form.

3. Select the Lock box and select Update my Application to include the new RuleSet Versions.

The Password field appears.

4. Enter the Password for this ruleset version and select the Roll box.


5. In the Roll to Version field, enter a new Rule Set Version or accept the default version whichincrements the current version by one.

6. In the NEW section of the Prerequisites you can modify the ruleset prerequisites. By default,they are the same as the current prerequisite. You can select different prerequisites, add additionalprerequisites, and/or delete prerequisites from the New list.

7. Click Run to apply the changes to your RuleSet.

8. Repeat these steps for each application in your system.

Running the Final Rules Conflict Report

Select the Designer Studio > System > Release> Upgrade > Final Conflicts menu item. Pega 7displays a report of rules in your system that reference Pega rules that have been made Final in thisrelease. The rules listed vary depending on the specific release from which you are upgrading.


Rules that are marked Final can no longer be overridden. If you have custom rules in your applicationsthat override Pega 7 rules that have now been made Final, your existing rules will continue to executecorrectly. However, you will not be able to modify them after you upgrade to the new RuleSet.

Note: If you modify and try to save a custom rule that overrides a Final rule, validation fails and youreceive an error message. To resolve the conflict, you must delete application rules that override Finalsystem rules, and replace the functionality in your application with other rules. If you are unsure how torespond to a Final rule, contact Pegasystems Global Customer Support.

Upgrading Pega-supplied applications

If your installation includes any Pega-supplied applications, upgrade the Pega-supplied applicationsbefore continuing with these steps. Follow the instructions in the Upgrade Guide for the version of yourPega-supplied applications, then continue with the configuration described in this step.

Note: To ensure good performance when upgrading large Pega-supplied applications, such as CPM,disable all Pega 7 agents and run only a single node when you import the Pega-supplied applications JARfile. This ensures that the only activity executing in the Pega 7 system is the import job itself.

To disable agents:

1. Select the Designer Studio > System >Operations > System Management Application menu itemand open the Node for the system you are upgrading. You may need to click + and create the nodeif this is your first time in the System Management Application.

2. In the System Management Application, go to Agent Management > Agents and click Stop under Allactivities in queue.

3. After the Pega-supplied applications import is complete, click Restart to re-enable the agents.

For Upgrades from Pega 7.1.6 and earlier: Manually building Elastic-search indexes

Starting in Pega 7.1.7, the underlying platform for full-text search transitioned from Lucene toElasticsearch. Elasticsearch provides a more robust, fault-tolerant search capability and does not requiremanual configuration of switchover activities. Existing search customizations through Pega 7 APIs areintact and used exactly the same way with Elasticsearch; only the search query generation changes fromLucene to Elasticsearch.

For upgrades from Pega 7.1.6 or earlier, you must manually build the Elasticsearch indexes and specifythe host nodes.

Note: Build the Elasticsearch indexes as soon as possible after upgrading.


1. Check your directory sizes:

l Ensure that the directories for all Elasticsearch host nodes have sufficient free space to holdthe Elasticsearch indexes. Elasticsearch indexes are approximately three times the size ofthe Lucene indexes.

l Ensure that the directory for the initial Host Node, has sufficient space to initially hold boththe Lucene index and the Elasticsearch index.

2. Open the Designer Studio > System > Settings> Search landing page and expand Search IndexHost Node Setting. The system displays the Host Node IDs originally created for Lucene.

3. Specify one node to set as the Host Node. If necessary, delete all but one node. This is the node onwhich Elasticsearch indexes will be built. It is not necessarily the Host Node you used for Lucene.

Note: Do not include more than one node in the Search Index Host Node Setting list. Includingmore than one node in the list at this point may cause duplicate index builds and compromisesystem performance. You will create additional nodes later in this process.

4. Verify the Search Index Host Node ID and the Search Index File Directory.

5. Expand Automated Search Alerts, and enable Automatically Monitor Files.

6. Expand Index Administration, enable all desired index types, and click Re-Index. Re-indexingtakes significant resources on the host node and can be a lengthy process depending on the numberof rules and work objects in your system.

Note: Do not stop or bring down this node until the Elasticsearch indexes build completely. TheSearch Landing Page displays the status.

7. Check the status. If there are any errors, use the alert messages to resolve the error and repeatstep 6.

8. Click Submit to save the settings.

9. After the first indexing is complete, add additional Host Nodes. The system automatically replicatesthe indexes on the new nodes.

Note: You must configure a minimum of 2 Elasticsearch host nodes. Pegasystems recommendsthat you configure a minimum of 3 nodes for maximum fault tolerance. You may need more than 3nodes depending on the size of your cluster.

10. To enable communication between Elasticsearch host nodes in the cluster, open a TCP port in therange 9300-9399 on each node. (By default, Elasticsearch uses port 9300.) These ports are used forinternal node-to-node communication only, and should not be externally accessible.


Completing the post-upgrade configuration

Following the upgrade, restart Pega 7. Then, you may need to make some additional modifications toyour existing applications to take advantage of new functionality.

Reviewing upgrade tools

Use the Designer Studio>System > Release> Upgrade> Upgrade Tools menu to review additionalupgrade activities that may apply to your applications. Pegasystems recommends that you run all ofthese utilities as the Deployment user, even though some may not return results for your application.

Review the General Utilities and run those that apply to your applications. These utilities help youidentify general issues with your application.

Reviewing log files

The upgrade creates a series of log files in <PRPC_HOME>\scripts\logs. After you upgrade, even ifthe upgrade is successful, review the log file. In particular, review the Prebuild Conclusion for messagesabout conclusions that cannot be built. These messages do not indicate a problem with the upgrade butrather identify issues with your Pega 7 application that you must correct.

This is a sample of the Prebuild Conclusions section:


Prebuild Conclusions:

[java] May 1, 2015 1:00:21 PM com.pega.pegarules.in-ternal.bootstrap.PRBootstrapDataSource

[java] 19830421: Loading bootstrap properties from file:///e:\tem-p/PegaInstallTemp-24-November-2014-11.07.15/prbootstrap.properties

[java] May 1, 2015 1:00:21 PM com.pega.pegarules.in-ternal.bootstrap.SettingReaderJNDI

[java] 19830421: Could not find java:comp/env/prbootstrap/ in thelocal JNDI context, skipping prconfig setting lookup

Look for any warning or error messages. One common issue is that a conclusion cannot be built becausea class is invalid, for example:

[java] 2015-05-01 13:13:52,911 [ STANDARD] [ ] (ion-ary.ClassInfoConclusionImpl) WARNING -

[java] Unable to initialize a ClassInfoConclusion for PEGACARD-CPM-WORK-GENERALCUSTOMERCASE, classDef=null, classRule=null

The warning or error message includes information about the invalid class. If you cannot resolve theissue, contact Pegasystems Support.

Testing your applications

The procedures in this section remove the known compatibility issues between Pega 7.1.8and earlierversions. However, depending on your development methods, you may discover additional modificationsthat need to be made in your existing applications when they are upgraded to Pega 7.1.8. Be sure toperform full testing of your application functionality after the upgrade.

Checking the Pega Discovery Network (PDN) for updates

Visit the Pega Discovery Network (PDN) at https://pdn.pega.com for the latest information about thisrelease of Pega 7, including possible updates to this guide.


Appendix A: setupDatabase.propertiesThis appendix contains an example of how the setupDatabase.properties file should look when therelevant properties for your installation have been entered.

# Properties File for use with PRPC Utilities. Update this file

# before using setupDatabase.bat/sh script.

# Set the DB connection

################### COMMON PROPERTIES - DB CONNECTION (REQUIRED)##################

###################################################################################

# For database that uses multiple JDBC driver files (such as DB2). You may specify

# semicolon separated values for 'pega.jdbc.driver.jar'

#

# pega.jdbc.driver.jar -- path to jdbc jar

#

# pega.jdbc.driver.class -- jdbc class. valid values are:

#

# Oracle 10g (Type 4) oracle.jdbc.OracleDriver

# IBM DB/2 Type 4 com.ibm.db2.jcc.DB2Driver

# SQL Server 2008 com.microsoft.sqlserver.jdbc.SQLServerDriver

# PostgreSQL 9.1.4 org.postgresql.Driver

#

# pega.database.type valid values are: mssql, oracledate, udb, db2zos, postgres

#

# pega.jdbc.url valid values are:

#

# Oracle 10g (Type 4) jdbc:oracle:thin:@//localhost:1521/dbName


# IBM DB/2 z / OS jdbc:db2://localhost:50000/dbName

# IBM DB/2 Type 4jdbc:db2://localhost:50000/dbName:fullyMaterializeLobData=true;fullyMaterializeInputStreams=true;progressiveStreaming=2;useJDBC4ColumnNameAndLabelSemantics=2;

# SQL Server 2008jdbc:sqlserver://localhost:1433;selectMethod=cursor;sendStringParametersAsUnicode=false

# PostgreSQL 9.1.4 jdbc:postgresql://localhost:5432/dbName

#

# pega.jdbc.username db username

# pega.jdbc.password db password

#

# ** If you are installing or upgrading on db2 or udb you should do the following:

# set the rules.schema.name to the schema name required

# update the udb.conf file in the /config directory if you have additional

# connection properties that need to be set. (schema name will be automatically added)

pega.jdbc.driver.jar=/opt/tomcat/lib/postgresql.jdbc4.jar

pega.jdbc.driver.class=org.postgresql.Driver

pega.database.type=postgres

pega.jdbc.url=jdbc:postgresql://localhost:5432/pega

pega.jdbc.username=pega

pega.jdbc.password=pega

#Uncomment this property and add a list of ; delimited connections properties

#For example jdbc.custom.connection.properties=user=usr;password=pwd

#jdbc.custom.connection.properties=

#Rules schema name : Used for all databases.

#The user name is used for default schema name

rules.schema.name=pegarules


# Data schema name : Used for systems running on a Split Schema

# The value of rules.schema.name is the default value for data.schema.name

data.schema.name=pegadata

#User Temp Directory. Will use default if not set to valid directory

user.temp.dir=

#z/OS Site Specific Properties file

pega.zos.properties=

# Generate schema will be skipped if this property is set to true

# Note: Leave this property blank if you need to generate the schema

bypass.pega.schema

# Generate UDF will be skipped if this property is set to true

# Note: Leave this property blank if you need to generate the UDF

bypass.udf.generation

# The utility will skip disabling and enabling of Pega Triggers during processing

# if this property is set to true

# Note: Leaving this property blank allows the utility to control the Pega Triggers.

bypass.trigger.control

# Note: The utility will skip any DDL Generation if all three bypass properties above

# are set to true.

# Truncate UpdatesCache will be skipped if this property is set to true

# Note: This property should be left blank so that the UpdatesCache table

# may be truncated automatically by the installer. If your site

# chooses to bypass this reset of the UpdateCache table, then the

# site must do the truncate of the 'PR_SYS_UPDATESCACHE' in the Data

# schema, manually after the install, upgrade or update before the


# system is started up.

#bypass.db2zos.truncatecache

# Run assembler after install/upgrade? : Defaults to false.

# This setting is to generate the Assembled Java classes

run.assembler=

# Load Assembled Java Classes

import.assembled.classes=true

# Rebuild Database Rules Indexes after Rules Load to improve Database Access Performance

# It can be executed manually by running the stored procedure SPPR_REBUILD_INDEXES

# Default is false except for z/OS, where the default is true

rebuild.indexes

# The system name uniquely identifies a single Process Commander System.

# Since multiple PRPC Systems may reference the same database, it is important that each

# system has a unique name in order to distinguish them from each other.

# During installs, the following system name will be created.

system.name=pega

# During installs, the above system name is generated with the following production level.

# The system production level can be set to one of the below integer values (1-5):

# 5 = production;

# 4 = preproduction;

# 3 = test;

# 2 = development;

# 1 = experimental

production.level=2

# Is this a multitenant system?


# A multitenant system allows organizations to act as distinct PRPC installations

multitenant.system=false

# Run Update Existing Applications activity after upgrade?

# Default setting is false.

# For pre-7.1 upgrades: Update Existing Applications is always run, regardless of this setting.

# For 7.1+ upgrades or updates: Upgrade Existing Applications is run if this setting is set to true.

# Update Existing Applications can be run from upgrade scripts, prpcUtils, or by directly launching inPRPC after upgrade.

update.existing.applications=false

# codeset and version for loading hotfixes

import.codeset.name=Customer

import.codeset.version=06-01-01

# Pre build the Pega Conclusions.

build.conclusions=

# Workload manager to load UDFs into db2zos

db2zos.udf.wlm

# Run RuleSet Cleanup

# Generate and execute a SQL script to clean old rulesets and their rules from the system

# If you would like to only generate the script, not execute it, see cleanup.bat or cleanup.sh script

run.ruleset.cleanup

# uncomment to generate timing benchmarks

# generate.benchmarks=true

# benchmark.warning.threshold.value=

# benchmark.kill.threshold.value=

#Schema file name to be used for reversal

#reversal.schema.file.name=



Preparing your application serverThis section describes how to prepare your application server:

Synchronizing hardware clocks

Pega 7 uses Hazelcast distributed clustering technology to share data and send events between servernodes. Like most clustering technology, Hazelcast assumes that all cooperating servers havesynchronized clocks. Pega 7 validates time synchronization to ensure proper operations and triggers aPEGA0055 alert if clocks of sync between nodes. Pega 7 also reports these errors to AES. The impact ofthese errors can include timeout errors and other system problems.

Every operating system has a provision for referencing a common time standard like the one available atwww.time.gov. On UNIX, this is the network time protocol daemon, ntpd. On Windows, you can set asimilar service through the clock settings in the control panel or task bar. See the documentation for yourspecific hardware operating system for information about setting this critical service.

Configuring ports

Before you start to set up your application server, ensure that the following ports are open and available:

l Search (Elasticsearch): one TCP port in the range 9300-9399 (default 9300)

l Cluster communication - Hazelcast: multiple ports in the range 5701-5800 (default 5701)

Search

To enable communication between the host nodes in the cluster, open a TCP port in the range 9300-9399on each node. (By default, Search uses port 9300.) These ports are used for internal node-to-nodecommunication only, and should not be externally accessible.

Cluster Communication - Hazelcast

In a Pega 7 system, there can be multiple servers, or nodes, and each node can contain multiple JVMs.The number of available ports in this range needs to be greater than or equal to the greatest number ofJVMs on any one node in the cluster. For example, if there are 3 JVMs on one node, and 7 JVMs onanother node, there must be at least 7 ports available.

For cluster communication, the port range 5701-5800 needs to be left open. By default, the systembegins with port 5701 and then looks for the next port in the sequence (5702, followed by 5703 and soon). To override the default port range, set the value of cluster/hazelcast/ports in the prconfig.xmlfile.


Configuring Web SSO with encrypted assertionsTo configure Web SSO with encrypted assertions, add the following jar files to the endorsed directory ofthe application server:

l xerces

l xaml

l xml-apis


Documents

Pega 7.1.8 Upgrade Guide for DB2-z/OSl DB2-z/OS: db2zos--dbSchema rules.schema.name Inasingleschema environmentsets theRulesSchema andDataSchema. Inasplit-schema environment,sets theRulesSchema