PeopleSoft Global Payroll Performance

Analysis & Tuning Approach

Payroll processing is the backbone of an organizations employee operational and satisfaction focus. With the growing market hold, Oracles PeopleSoft (PS) Global Payroll has become a value for money choice for a wide range of the market. The product is intelligent and efcient to be able to process a few hundreds to multi thousands of employees records. The performance tuning of the PS payroll engine is well documented under various subjects. However, due to different needs of customers, some topics may not be relevant at a particular instance. At times this leads to customers trying out various possibilities to tune the engine, looking for multiple subjects, doing a hit and trial and in most cases getting lost in the vast span of subjects, possibilities, responsibilities and case studies. The paper discusses the building blocks that ensure a time saving performance tuning exercise applicable at a particular installation. The paper does not focus much on the range of resolutions to a poorly performing payroll engine. Instead it talks about a performance diagnostic and tuning approach that can be used at any PS Payroll 8.3 (DB2 - z/OS) installation.

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

About the Author

Jitesh Kohli Jitesh has been working with TCS since 2001. He holds a Bachelors degree in Mechanical Engineering from REC Kurukshetra. Jitesh has worked on PeopleSoft applications with several engagements of TCS. Additionally, his credentials includes working on Microsoft and eLearning technologies.

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

Table of Contents
1. Introduction 2. Recap-Global Payroll Fundamentals
Brief Introduction to PeopleSoft Payroll Architecture Global Payroll Organizational Structure Global Payroll Processing Structure Calendars Payroll Processing Preparation Processing Steps

3 3
3 4 5 6 7 8

3. Problem Statement 4. Solution

Benchmark the Target Identify the Task Force Find the Culprit Area Identify the Best Fit Solution

8 8
9 9 10 10

5. Summary & Conclusion 6. References

21 21

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

Introduction
PS payroll core engine is the heart of payroll processing for systems utilizing the PS payroll product. PS payroll core engine is a calculation COBOL program that processes its calculations based on rules set up in the PS global payroll set up pages. Performance of this critical PS component is of vital concern considering the importance of the output of the program and dependencies other systems may have to the timely completion of the processing of the engine. Most important, it is a reputation concern for an organization to be able to compensate its employees on time. The objective of this paper is to talk about an approach that shall help diagnosing, analyzing and tuning the performance of a payroll engine. At pit-stops, the paper also refers to possible solutions that shall contribute in improving the performance of a long running payroll engine.

Recap - Global Payroll Fundamentals

Brief introduction to PeopleSoft Payroll Architecture PS Global Payroll essentially is a coupling of two components: Core Payroll Application (a) Flexible payroll rule engine The rule based engine is a exible tool that denes and executes payroll and absence calculations. All business application logic such as earning, deduction, absences and accumulators are specied in terms of payroll and absence rules. These rules can be entered and maintained through a set of pages. (b) Processing framework The core Global Payroll application is a common foundation and structure that organizations in every country can use to build their own calculation rules. The core application determines the basic framework for payroll and absence processing. This basic framework supplies the normal processing structure for the calculation of a payroll or absence. Country Extensions Country extensions are built using the core application. Included in the country extensions are:

Statutory and customary rules including earnings, deductions, absence entitlements, accumulators and so on. Online look and feel for the country Self service applications Reports

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

Fig 1 Global Payroll comprehensive diagram Global Payroll Organizational Structure The PS Global Payroll core application determines the organizational structure for payroll processing. The organizational structure comprises a hierarchy of components.

Fig 2 Global Payroll Organizational structure

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

The following table will help recall the various components shown in Fig2 above. Pay Entity The organization that makes the payment The currency to be used as the processing currency for every calculation The country associated with the Pay Entity Associated with single Pay Entity Grouping of Payees to process together Linked with pay calendar in order to process a payroll Group of Element Groups Indicates the Elements for which a certain payee is eligible Default Eligibility Group is dened at the pay group level Payees are assigned to a default Eligibility Group, but it can be overridden Group of Elements Any number of Element Groups can be assigned to an Eligibility Group The basic building blocks of Global Payroll First component to be dened

Pay Group

Eligibility Group

Element Group Element

Global Payroll Processing Structure The processing structure of Global Payroll determines which elements are used for calculation of a particular payee and in what order.

Fig 3 Global Payroll Processing structure

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

The processing structure is comprised of the components specied in the table below: Process List Calculation type indicates whether the process list is for an absence or a payroll run Species the Elements via sections in the order in which they are to be processed and resolved Provides ability to conditionally execute sections Indicate the gross and net pay elements Group of elements Control the order in which these Elements are processed on the Process List Section use indicates whether the section can be used in payroll processing, absence processing or both There are four dierent section types available that can be used for dierent types of processing Sections can be reused in multiple process lists The basic building blocks of Global Payroll First component to be dened The system resolves each element in the Process List for each payee if they are eligible to receive it

Sections

Element

Calendars To run a payroll or absence process, the relevant components of the system are tied together through the use of calendars. A calendar controls who is to be paid, what amounts are to be paid, and the period of time for which the payment is being made. Only one pay group can be associated with a calendar.

Fig 4 Global Payroll Calendars

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

Through the use of various selection criteria, you can dene who is going to be paid: Calendar Run Types Calendar Period IDs Calendar ID Calendar Group ID Payroll Run Control Enable dening what is being paid Linked to the Processing Structure Enable dening the period of time for which the payment is being made Enables dening the payees going to be processed Linked to Organizational Structure Groups the calendars that are to be process at the same time Identier used to run the payroll or absence processing

Payroll Processing Preparation Now that we have recalled how the payroll run controls, payees and run types are linked together, let us look at how we prepare our system before we run a payroll process.

Fig 5 Global Payroll Processing Preparation Create Calendars (Required) Calendars tell the system which pay group, run type, process list, and calendar period to process. Pay groups, run types, and process lists are dened during system implementation. Calendar periods can be dened during implementation or when calendars are being setup. The calendar group ID identies the set of calendars that run together and the sequence in which the calendars are to be processed. If stream processing is required, then it is necessary to indicate it when setting up the calendar group ID. To use stream processing, the range of employee IDs for each stream is identied. Stream set up is a one-time process that may require the assistance of a database administrator. To use the group list feature, clerks who run the payroll process select the payees for each group list. (Group lists are tied to user IDs.) Positive Input (PI) for the pay period can be entered before or after you begin processing. If PI is entered after running the Calculate phase, then Calculate must be run again to pick up the new entries.

Create the calendar Group ID (Required)

Create Streams (Required) Create Group Lists (Optional) Enter Positive Input (Optional)

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

Processing Steps Fig 6 below shows how payroll processing happens starting from identifying payees to nalizing the process.

Fig 6 Global Payroll Processing Steps

Perform Payees (Identify Phase) Perform Calculations (Calculate Phase) Review Results

Correct Any Errors & Recalculate

Finalize the Run

The payroll cycle begins when you run a process that identies all payees that are to be processed. This phase computes each payees gross and net earnings (for a payroll run) or absence take or entitlement units (for an absence run). If the system encounters problems during the Calculate phasefor example, invalid element denitions or payee eligibility problemsit places the payee in error. You can use various PS payroll pages to review summary results, errors, and warning messages. To correct errors, you may need to update the Positive Input pages or make changes to the data in other applications that are integrated with PS Global Payroll, such as Human Resources or Time and Labor. You can then run the Calculate phase again to process only the payees that need to be recalculated. When youre satised with the processing results, run the Finalize phase to close the calendar group ID.

Problem Statement
The subject of payroll tuning involves multiple nodes, for example - database level tuning, server capacity utilization and application level setup improvements. A wide range of documents on these various subjects are available on the PS site already. There is, however, no single answer to the problem statement of a poorly performing payroll engine. Performance engineers are required to be able to catch the right spot(s) where there is need for improvement and apply the corresponding resources and solution(s). In simple terms, the quest is for an approach that leads an engineer to the performance tuning measures applicable in a particular scenario.

Solution
How can we improve performance? - The big question has multiple immediate child questions like: Is the performance currently really poor? Who would start? Where is the problem? Where do we start? How do we resolve the problem? Is this the correct solution? Is this a success? The approach to the solution discussed in this paper is simple and fruitful. All we need to do is to answer questions listed above in the correct order.

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

Kindly note that in this paper we are discussing the approach to nd a solution more than the solution itself. The reason for this is that the solution belongs to a problem and there is no single problem which is always the culprit for poor performance of the payroll engine. What we would instead focus on is how to help ourselves nd the right cause of our problem and how to nd the right x for the identied problem. The following are the 6 steps to success: 1. Benchmark the target 2. Identify the task force 3. Find the culprit area 4. Identify the best t solution 5. Fix and compare against the benchmark 6. Freeze Benchmark the Target Performance is a fairly relative term. To be able to comment on the performance of the payroll engine at a particular installation, we rst need to know what the corresponding benchmarks are. Please note that all performance tuning benchmarks are environment and data volume/distribution specic. To access the benchmark reports on the PS site, please follow the steps mentioned below:1. Logon to the PS site (http://www.peoplesoft.com) using your connection user ID and password 2. Click on the link Implement, Optimize, and Upgrade 3. Click on the link Optimization Guide. On the following page, choose the link Performance Tools 4. Click on the link Benchmark Performance Reports. Needless to say, the person responsible for the payroll engine tuning needs to verify the total time the payroll engine takes against the benchmarks established in the above mentioned reports directory. Deciding the target for performance improvement depends on the reasons due to which the current performance is not acceptable. It also depends on how much deviation is found between the installed version and the corresponding benchmark results. What is now crucial is to brainstorm on these factors and decide a target for the tuning exercise. Identify the Task Force By comparing the time the payroll engine takes to process against the time in the corresponding benchmark in previous section, we should, by now, know if we need any performance improvement tasks at all. If yes, then the next step is to identify the human resources required to bring the performance up and close to the benchmark results. The payroll performance tasks can include application level tuning, SQL changes, database conguration changes, server capacity review tasks and so on. Before drilling down to the problem, make sure that a competent task force capable to cover all the aspects mentioned above is available. You may or may not deploy one or more members depending on the kind of performance improvement potential at your installation.

PeopleSoft Global Payroll Performance

TATA CONSULTANCY SERVICES

The following list demonstrates an example task force for the tuning activities:

Team lead/coordinator PS payroll business analyst PS payroll technical developer PS DBA Systems Engineer with server capacity, utilization insight

Find the Culprit Area On the mark, get set. Go! The rst step in tuning is to nd out what is to be tuned. In other words identify the area deteriorating the performance of the payroll engine. The domain pertains to DBAs and System Administrators. The idea is to trace the payroll engine programs to identify the area impacting the overall processing time. There are multiple tools to study this behavior like Strobe, OMEG, TMON, Apptune, Detector and so on. Your System Administrator should be able to suggest a tool suitable to your environment. For information on the various tools in the z/OS environment and their usage, please use the links below. http://www.db-consulting.com/ http://www4.peoplesoft.com/2001presentsamer.nsf/SessionTrack?readform

Identify the Best Fit Solution Broadly, the payroll engine processing can be distributed time-wise into system idle time, DB2 wait time and processing time.

Fig 9 Payroll Engine Processing Time (High Level) Out of the three components - system idle time, DB2 wait time, processing time, the most debatable is the processing time. Therefore, let us for the moment park this aside and look at the other 2 components.

PeopleSoft Global Payroll Performance

10

TATA CONSULTANCY SERVICES

System Idle time (tuning z/OS, Disk I/O etc) Diagnostic step 1 a) Wait for OS related system services As with any other process, there are some operating system related activities with the payroll engine processing. An example of such activities would be opening/closing les. In most of the cases, this is not a problem, however if it is considered high by the system administrator, then the emphasis needs to be laid at the hardware aspects, abnormal system behavior (virus!, network) etc. b) Wait time for shared memory Host environments are expensive and in most of the cases shared amongst multiple applications. While analyzing the statistics please note which CPU (In multiple CPU scenario) the wait time belongs to. If you are not using payroll streaming, then you would nd that most of or all the wait time belongs to a single CPU. Study the statistics against this single CPU only and do not average it amongst all the CPUs in place (which would increase the %age wait time and give incorrect impression). If the system administrator still nds that the %age wait time is high, then analyze the factors behind high wait time. In most of the cases you would nd another job running on the CPU with priority higher than the payroll job. Readjust the application priorities based on your business requirements. In worst case, you may also look at the option of utilizing a dedicated (against shared) environment for payroll (or PeopleSoft application).

DB2 wait time Diagnostic step 2 In a way, the system idle time and DB2 wait time are interdependent. Therefore while analyzing the statistics gathered for these two components, it is important that your DBA and the system administrator work in tandem. If your DBA nds this time abnormally high, then review is required in the areas of disk I/O, DB2 connect parameters, PTPSQLRT package bind parameters etc. Following case discusses such a case where one of the PTPSQLRT bind parameter was found to be the culprit causing the DB2 wait time to grow up to 64%. Case begins:In one of the scenarios, following was the time distribution noticed (the statistics were gathered using STROBE tool). System idle time 23.5% (Waiting for the shared memory 11.5%, System services (OS related) 12%) DB2 wait time 64% Processing time 12.5% This clearly indicates that one of the rst diagnostic targets is the DB2 wait time. Upon investigation it was found out that one of the bind parameters of PTPSQLRT package - IMMEDWRITE was incorrectly set to IMMEDWRITE (YES) by the local conguration management tool (SCM). Once the parameter was reset to IMMEDWRITE (NO), the statistics changed to the following: System idle time 23.5% (Waiting for the shared memory 11.5%, System services (OS related) 12%) DB2 wait time 10.5% Processing time 66% Case ends. For more information on the DB2 connect parameters, please see the Solution ID 47387 on the PS site (http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/RC_SELF_SERVICE.RC_SOLNSRCH_SW_ SS.GBL?portalispagelet=true)

PeopleSoft Global Payroll Performance

11

TATA CONSULTANCY SERVICES

Processing Time Once the System Idle time and DB2 wait time are tuned, we get much closer to the application tuning. Please see the chart below, detailing the preferred sequence and drill down of diagnostics steps. Diagnostic steps 1 & 2 are already discussed in section 5.4.1 and 5.4.2. Steps 3 to 8 relate to the time spent in processing the payroll engine program.

Fig 10 Payroll Engine Processing Time (Low Level) Environment health check Diagnostic step 3 With the help of the DBA and the system administrator, review the health of the DB2 z/OS environment. A typical health check in the DB2 z/OS environment would include:

Zparm check for example edmpool, lock thresholds, sort pool, rid pool, parallelism Buffer Pool Check for example non-catlg tsps in BP0 Tablespace Locksize Compressed tablespaces Non-clustered clustering indexes

Additional precautionary health check steps could be to: 1. recreate indexes to be sure none are corrupt 2. update Statistics Both these activities are affected by the volume of data. During the rst cycle, following the upgrade or implementation operation, it could be helpful to often rebuild the indexes and update statistics. The tables used in Payroll Calculation are constantly being updated, deleted, tested, or restored. This makes the statistics useless and, in many cases will lead the optimizer in the wrong direction. Hence, it would be advisable to rebuild indexes and update statistics at regular intervals of data loading or conversion.

PeopleSoft Global Payroll Performance

12

TATA CONSULTANCY SERVICES

Database statistics Diagnostic step 4 In the previous section, we noticed that one of the measures to ensure good health of DB2 is to run the database statistics at regular intervals. However with respect to the payroll engine there is an exception DB2 statistics handles some tables not as they should be handled. These are the tables used as temporary tables during the payroll run, which start with a record count of 0 and end with a record count of 0. But during a payroll run they may have a record count of several hundred thousand or even more. In such a case the statistics calculation always sees 0 and therefore these tables are handled as unused or seldom used. For temporary payroll tables this is clearly incorrect and it ends up in huge and time consuming insert, update and delete statements. The solution to this problem could be to:

Identify the tables used in the payroll engine Separate out these tables from other tables by putting these tables in independent tablespaces (1table per tablespace) For the tables identied in the previous step, set the statistics related rowcount to a value of -1. This is a more generic way to set the statistics to an optimum for tables which can store up to 10,000 or 20,000 rows. Set the rowcount to a realistic value. This requires a manual catch of the real gures during a payroll run which has to be manually monitored.

Thus, we can ensure that the database statistics do not negatively affect the tables. Payroll partitioning Diagnostic step 5 In simple terms, payroll streaming can be dened as segmenting employees into dened streams. These streams are processed in parallel, reducing the processing time for the complete population. Let us take a case where an employee-range GP00001 GO00400 falls under one pay run ID. In a typical sequential processing, this is how the employees would be processed in the payroll engine:

Fig 11 Payroll Engine Processing Without Streaming On the other hand, if we segregate the employee range into 4 streams (GP000001 to GP000100, GP000101 to GP000200, GP000201 to GP000300, GP000301 to GP000400), the pattern of parallel processing would be as follows: In the case shown below, an ideal parallel processing (implemented through streaming) should reduce the total processing time to approximately .

PeopleSoft Global Payroll Performance

13

TATA CONSULTANCY SERVICES

Fig 12 Payroll Engine Processing With Streaming Having said that, please note that the amount of time saved by implementing streaming, among other factors, depends upon the employee population, server capacity and CPU states, under normal sequential payroll run. The streaming option saves the processing time by making use of the unused server capacity in the sequential processing. In the case mentioned above, if we assume an ideal scenario with 4 load sharing CPUs; this is like how the load distribution would change by implementing streaming as opposed to sequential processing: CPU states before implementing payroll streaming (sequential processing):CPU 0 1 2 3 Average 0.0% 92.4% 10.8% 0.0% 25.8% USER 0.0% 5.8% 2.2% 1.6% 2.4% SYS 100% 1.8% 87% 98.4% 71.8% IDLE

CPU states after implementing payroll streaming (parallel processing):CPU 0 1 2 3 Average 94.0% 92.4% 96.4% 89.2% 93% USER 2.8% 5.8% 2.2% 3.6% 3.6% SYS 3.2% 1.8% 1.4% 7.2% 3.4% IDLE

For details on implementation of payroll streaming, please refer to solution ID 200748163 on the PS site. From the database aspect, some of the payroll tables are required to be partitioned in the pattern of the streams dened. Essentially the tables are partitioned so that two or more processes (payroll streams) are simultaneously able to make changes to the same table for their corresponding and mutually exclusive rows.
PeopleSoft Global Payroll Performance

14

TATA CONSULTANCY SERVICES

The solution referred above includes the reference to the list of the tables required to be partitioned for streaming to run successfully. Case begins:In one of the tuning exercises, it was found that the following tables are required to be partitioned for streaming to run successfully. 1. PS_GP_EXCL_WRK 2. PS_GP_GRP_LIST_RUN 3. PS_GP_HST_WRK 4. PS_GP_JOB2_WRK 5. PS_GP_MESSAGES 6. PS_GP_NEW_RTO_WRK 7. PS_GP_OLD_RTO_WRK 8. PS_GP_PI_GEN_DATA 9. PS_GP_PI_GEN_HDR 10. PS_GP_PI_GEN_REF 11. PS_GP_PI_GEN_SOVR 12. PS_GP_PYE_PRC_STAT 13. PS_GP_PYE_RCLC_WRK 14. PS_GP_PYE_RUN 15. PS_GP_PYE_SEG_STAT 16. PS_GP_PYE_STAT_WRK 17. PS_GP_RSLT_ABS 18. PS_GP_RSLT_ACUM 19. PS_GP_RSLT_DELTA 20. PS_GP_RSLT_ERN_DED 21. PS_GP_RSLT_PIN 22. PS_GP_RTO_PRC_WRK 23. PS_GP_RTO_TRG_CTRY 24. PS_GP_RTO_TRGR 25. PS_GP_RTO_TRGR_WRK 26. PS_GP_RUNCTL 27. PS_GP_SEG_WRK 28. PS_GPCH_RP_FK01 29. PS_GPCH_RP_FK02 30. PS_GPCH_RP_SI07 31. PS_GPCH_RP_SI08 32. PS_GPCH_RP_TX01 33. PS_GPCH_RP_TX05 34. PS_GPCH_RP_0001 35. PS_GPCH_RP_0002 36. PS_GPCH_RP_MT This list may need addition or deletion for a different version of payroll or for customized applications. The shortest way of getting to know which tables have to be partitioned is by hit and trial method. Let us suppose you partition the tables listed above and still at least one of the payroll engine streams fails indicating that a table is locked by another process. In this case, you need to nd out if the table was partitioned or not. Partition the table, run the streams again and check for success.

PeopleSoft Global Payroll Performance

15

TATA CONSULTANCY SERVICES

Another learning drawn from this exercise is the run control table for payroll engine - PS_GP_RUNCTL. This table needs to have lock size of not more than 1 row per page for 2 or more streams to run in parallel. This is required to avoid one of the processes from locking the run control table while reading the parameters which can happen because the table size is small (usually not more than a couple of rows). From the database perspective, partitioned tables had the following disadvantages:

In a partitioned tablespace, only one table can be created (table space (TS) and table denitions are related and dependent).I In a normally segmented TS you can create more than one table. In partitioned TS, a table cannot be dropped explicitly. It needs the TS to be dropped which drops the table implicitly. PeopleSoft application does not support making table partitioning through its development environment. Therefore after the tables are partitioned at the database level, the PeopleSoft metadata would not match with the table denitions on the database. If a table is not partitioned, this is how you alter it with alter by rename option: 1. Create a table with the new structure (new attribute denitions) with a similar name in the same table space as the original table. 2. Populate the new table with the old rows from the original table (insert into tab new select ... from tab old). 3. Drop original table. 4. Rename new table to original name This process is no longer possible with tables in a partitioned TS. One solution is to change the original table with an ALTER Table command. This is possible only if new attributes are added to the table or if varchar attributes are to be enlarged. It is not possible if an attribute needs to be eliminated or if changes are done for attributes with the types CHAR, DECIMAL, FLOAT or if a varchar is being reduced in length. Another time consuming solution, but the only solution for all kinds of changes, is to create a new table space (with the specic partitioning parameters set) and create the new table in it (partitioning index is mandatory, new index name is needed because original one cannot be dropped). The new table may then be populated and the old table space dropped. Rename the new table to original table name. For empty tables (work tables, temp tables) in a partitioned TS the process is shorter because no data is affected; drop TS (table included), create new TS, new table, indexes. There is one advantage related with partitioned TS for the housekeeping process. Utilities like image copy, re-organization, unload, load can be processed on a specic partition or can process the partitions in parallel to reduce elapsed time. Case ends. SQL Tuning Diagnostic step 6 The above 5 diagnostic and tuning exercises should result in fairly high degree of performance gain. Further tuning can be made by diagnosing and tuning long running SQLs in the program. However, please note that this exercise can be time consuming. Also it needs precise impact analysis since the dynamically generated SQLs in payroll engine may impact the performance in multiple dimensions at multiple instances. You can nd out which SQL is running slow using PS traces, DB2 historical traces or DB2 real time traces. Diagnostic tools to be used in conjunction could be DB2 explain or any other tool recommended by your DBA.

PeopleSoft Global Payroll Performance

16

TATA CONSULTANCY SERVICES

More information on the topic can be obtained from the PS customer connections. Below is a brief guide to using TraceSQL for trouble shooting. TraceSQL is not normally invoked during processing so the rst step is to recreate the problem with TraceSQL invoked. For COBOL processes, this is normally set in the le which sets parameters for the Process Scheduler. The parameter name is TraceSQL with value set as desired according to the following: TraceSQL is implemented as a bit map with the following values -1=SQL statements - 2=SQL statement variables - 4=SQL connect, disconnect, commit and rollback - 8=Row Fetch (indicates that it occurred, not data) - 16=All other API calls except SSBs - 32=Set Select Buffers (identies the attributes of columns to be selected. - 64=Database API specic calls -128=COBOL statement timings - 256=Sybase Bind information - 512=Sybase Fetch information So, if you want statements, Row Fetch and COBOL timings, you would specify TraceSQL=137 (1+8+128). For troubleshooting, sometimes it is best not to guess which values you want so 255 will set all values on -- except for the Sybase specic settings. Once you have the cobsql le -- and the COBOL TraceSQL results, the next step is locating the clues provided for the problem at hand. Locate the SQL consuming high processing time. Once you nd the point of the problem, note the cursor number -- for example #12. Working your way on up in the le, locate the SQL statement that established this cursor. It is that statement that needs to be further analyzed for the cause of the problem. Start by copying that statement into your SQL tool and replacing any variables (:1, :2 and so on) with appropriate values. Break down the statement into smaller statements as needed to determine the cause of the problem. This is the basic for problems with SQL. Tracing can be used for trouble shooting logic issues also, but that is another chapter. Commit level Diagnostic step 7 To access the commit frequency for the payroll engine: Browse to Set up HRMS, select Product Related, then select Global Payroll and then click Installation Settings. A high commit frequency set at this place degrades the engines performance. Review the frequency set here and revise it to the optimal for a successful run. Note that, on the other hand, having a low commit frequency (committing less often) may result in a conict with payroll streaming. As discussed above, the two (or more) streams run in parallel in case of streaming access the same tables at almost the same time. Therefore there remains a risk of clash on a un-partitioned table. Lower the commit frequency, higher the chances of such a clash.

PeopleSoft Global Payroll Performance

17

TATA CONSULTANCY SERVICES

Other payroll setups Diagnostic step 8 Having worked on most of the possible technical tuning options, if you do not see a considerable performance gain, it becomes essential to look for potential payroll setup improvements. The following sections have some tips to revise your payroll setup.

All Elements - There are two attributes on the Element Name page that can affect performance and data volume: Always Recalculate and Store/Dont Store. (a) Always Recalculate - You should select the Always Recalculate option (on the Element Name page, GP_PIN record) only when it is required in situations where you encounter the element multiple times within the same slice or segment and you expect its resolved value to change. When the PIN manager encounters an element, it rst checks to see if that element has already been resolved for the payee for the appropriate slice, segment or period. If the element has not been resolved, the system automatically resolves the element, regardless of the Always Recalculate setting. If the element has been resolved, the system checks the Always Recalculate setting. If the setting is No, the system uses the previously resolved value. If the setting is Yes, the system resolves the element. Each resolution slows down the performance. (b) When to store data - You should only be storing an element if it is needed in one of these situations: - Reporting, either in result tables or in a writeable array - Retroactivity - Historical rules - Fictitious calculations - Chart elds - Audits

In addition, with earnings and deductions you can indicate whether you want to check the resolved value or all individual component values to determine whether to store the element. Unless you need the individual component values for purposes of reporting or historical rules, you should only be storing earnings and deductions if the resolved value is not zero.

Arrays
Arrays must be set up correctly in order to maximize performance. (a) Calling the Lookup Processing Option Formula - There are multiple ways to set up an array. The most important thing you can do to enhance performance is to reduce the number of times you call the lookup formula. If the goal of your array is to return only one row by segment or slice, it is best to avoid the lookup formula process by using the key page with the appropriate conditions and the return page with the appropriate logical order. (b) Ordering the Fields Retrieved - It is important to nd the appropriate order of your rows to minimize the call to the formula. Usually, when you check an effective date it is better to order the date eld by descending value. (c) Using the By Formula, Apply All Rows and the By Row, Apply All Formulas Options - You may use By Formula or Apply All Rows if you need a rst reading before handing the array.
PeopleSoft Global Payroll Performance

18

TATA CONSULTANCY SERVICES

Formulas Consider the following options: (a) using variables with default values (b) formulas that use other formulas - You should always think about this when making the decision on whether to create a separate formula. Maintenance is also a consideration. (c) exit functions - When you are using If logic in a formula, you should remember to use exit logic whenever applicable so that the system does not resolve any unneeded elements. (d) IF functions - When you have multiple conditions, you should always put the most popular condition at the top so that you match the majority of your population at the very beginning. (e) Min/Max functions - When you need to retrieve the smaller or larger value of two or more elements, it is better to use the Min/Max function as opposed to IF/Then logic.

Generation Control versus Conditional Section Logic

As you know, generation control and conditional section logic are two of the various ways that you can control if an element is resolved for a payee. However, there is a big difference between generation control and conditional section logic. In fact, the conditional sections skip element resolutions. If you have PI for an element in a section and the condition is false, the element will not be resolved, so the PI will be ignored. The same concept is true for retro adjustments. Conversely, if you have a group of elements that you know should never be resolved except in a specic situation, such as a termination, it might make sense to use conditional section logic because it is easier and faster to bypass a subset of elements than to resolve generation control for each. If you are sure about your needs it is quicker to use a conditional section. But make sure that you understand the implications of conditional section logic before using it.

Historical Rules
Before deciding whether to use a historical rule, you need to consider the following: (a) the number of periods or segments that your historical rule must read. (b) the frequency at which your historical rule will be resolved. This will help you determine whether using a historical rule makes sense.

Proration Rules/Counts
If you must access Work Schedule information, such as scheduled hours and so on, in order to help resolve Proration Rules, you should try to read the work schedule only once in order to improve performance. You typically read a Work Schedule through a Count Element (which uses a formula that checks to see Scheduled Hours and so on). When you need to have multiple proration rules such as calendar days, workdays and work hours for the same slice periods, it is better to have one count element to resolve all proration rules. Thus you read the work schedule information only once.

Checking the Performance of Your Rules

To check the performance of your rules, select the Trace All option on the Payroll/Absence Run Control and execute your calculation.

PeopleSoft Global Payroll Performance

19

TATA CONSULTANCY SERVICES

After that you can utilize the SQL below to help analyze the performance of your rules. DECLARE @CAL_RUN_ID VARCHAR (18) SET @CAL_RUN_ID = KD% SELECT A.CAL_RUN_ID, B.PIN_NM, B.PIN_TYPE, B.RECALC_IND, A.SUM_INSTANCE_IND Call From Process, COUNT(*) Count Nb, SUM (A.DIFF_SECONDS) Delay in Second, AVG (A.DIFF_ SECONDS) Average FROM PS_GP_AUDIT_TBL A, PS_GP_PIN B WHERE A.CAL_RUN_ID Like @CAL_RUN_ID and A.PIN_NUM = B.PIN_NUM and A.DIFF_SECONDS > 0 GROUP BY A.CAL_RUN_ID, B.PIN_NM, B.PIN_TYPE, B.RECALC_IND, A.SUM_INSTANCE_IND ORDER BY 1, 8 DESC

No. 1 2 3 4 5 6 7 8 9 10 11 12

CAL_RUN_ID KDG0101 KDG0101 KDG0101 KDG0101 KDG0101 KDG0101 KDG0101 KDG0101 KDG0101 KDG0101 KDG0101 KDG0101

PIN_NM DE_DV_DATA DE_SI_SETUP DE_INIT_PA DE_GR_EE DE_SI_EE_DATA DE_FL_INIT_ELIG DE_AB_DISABILITY_G DE_SI_RATE_FUND DE_SI_K_STATUS DE_SI_PROV_KEY DE_SI_A_PROV DE_CC_COND

PIN_TYPE AR FM FM AR AR FM AR FM VR VR VR FM

RECALC_IND Y Y Y Y Y Y Y Y N N N N

Call From Process Y Y Y Y N Y N N N N N Y 1 25 1 1 1 1 1 25 25 25 25 1

Count No.

Delay in Second .370000 4.550000 .150000 .150000 .140000 .130000 .130000 3.120000 3.110000 3.110000 3.110000 .100000

Average .370000 .182000 .150000 .150000 .140000 .130000 .130000 .124800 .124400 .124400 .124400 .100000

Fig 13 Payroll Engine Performance of Payroll Rules Brackets - It is recommended that you do not have more than 100 rows for the same effective date by bracket. If you have more than 100 rows for a bracket, you should consider using an array instead. The payroll setup recommendations above have been extracted from the Tuning PeopleSoft Global Payroll document available over customer connections. Additionally please see the document referred above to nd details on the sections mentioned above and also to nd information on Methods for Reducing the Size of Result Tables and List of Tables to Aid in Archiving Solutions.

PeopleSoft Global Payroll Performance

20

TATA CONSULTANCY SERVICES

Summary & Conclusion

PS payroll engine performance tuning is a vast subject with multiple nodes. Some of the nodes may not be applicable at a particular installation. To ensure that the correct node is looked at and the culprit issue is found and corrected without wasting effort at non important subjects, the tuning exercise can be structured in the following way: 1. Benchmark the target 2. Identify the task force 3. Find the culprit area 4. Identify the best t solution 5. Fix and compare against the benchmark 6. Freeze The following would be an optimal task force for the tuning activities to guarantee success: 1. Team lead/coordinator 2. PS payroll business analyst 3. PS payroll technical developer 4. PS DBA 5. Systems Engineer with server capacity, utilization insight Also, identifying the loophole and applying the best t solution should be carried out in the following sequential fashion: 1. Address the system Idle time (tuning z/OS, Disk I/O etc) Diagnostic step 1 2. Address the DB2 wait time Diagnostic step 2 3. Address the processing time 3.1 Environment health check Diagnostic step 3 3.2 Database statistics Diagnostic step 4 3.3 Payroll partitioning Diagnostic step 5 3.4 SQL Tuning Diagnostic step 6 3.5 Commit level Diagnostic step 7 3.6 Other payroll setups Diagnostic step 8

References
PS 8.3 Global Payroll PeopleBook Oracle PeopleSoft website - http://www.peoplesoft.com http://www.db-consulting.com/

PeopleSoft Global Payroll Performance

21

TATA CONSULTANCY SERVICES

About PeopleSoft Practice

Building an internet-based real-time enterprise is a DREAM! Connecting and synergizing the enterprise, its internal systems with its customers, suppliers and business partners is a huge challenge. The PeopleSoft practice at TCS helps organizations translate this dream into reality through PeopleSoft applications. The PeopleSoft Practice specializes in implementation, upgrade and production support services of PeopleSoft applications. PeopleSoft Practice consists of more than 350 consultants addressing the needs of global customer base in verticals as Telecom, Pharmaceuticals, Banking, Financial Services / Insurance, Retail and Healthcare. The 350+ consultants in TCS PeopleSoft are spread across different geographies and they offer solutions focusing on Human Resource Management (HRMS), Financials, Supply Chain Management (FSCM) and Customer Relationship Management (CRM).

Tata Consultancy Services (TCS) is among the leading global information technology consulting, services and business process outsourcing organizations. Pioneer of the exible global delivery model for IT services that enables organizations to operate more efciently and produce more value, TCS focuses on delivering technology led business solutions to its international customers across varied industries.

About Tata Consultancy Services

For more information contact

Natarajan Srinivasan Tata Consultancy Services Limited SJM Towers, No.18, Sheshadri Road, Gandhinagar, Bangalore - 600 009, Karnataka, India Phone: +91-80-5660 6421 Fax: +91-80-2220 7510 Email: natarajan.srinivasan@tcs.com Website : www.tcs.com

All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modied, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties. Copyright 2004-05 Tata Consultancy Services Limited PeopleSoft Global Payroll Performance

22

TATA CONSULTANCY SERVICES