Table Access Programs

Selected Table Access Programs

This table describes selected table access programs:

Table Access Program	Description
PSPERNTB	Earnings Table Manager
PSCERNTB	Earnings Table Copy Section Manager
PSPDEDTB	Deduction Table Manager
PSCDEDT1 through PSCDEDT6	Deduction Table Copy Section Manager

Understanding Table Access Programs

To understand the function of the table access programs, let's look at how a process as Pay Calculation actually works. As Pay Calculation is calculating a pay group, it needs certain information. Among other things, it needs to know who needs to be paid. Pay Calculation bases the answer to the question of who needs to be paid on what earnings and deductions it finds on the database. At the employee level, it takes in all the earnings and all the deductions for a particular employee.

In addition, Pay Calculation must know the details about those deductions and earnings. It gets this information from the Earnings table and the Deduction table. These are pay-process-level tables, not employee-level tables, and when you run a process, they're managed by subroutines in the payroll system, the table access programs.

When Pay Calculation sees an earnings come in for an employee, it reads the employee-level data, and sees, for example, that this employee is going to be paid some regular pay. It then goes to the Earnings table to find out the details of regular pay, reads the information about regular pay once, and stores it in a table array in memory. When the next employee comes along and also has regular pay, it doesn't have to read the Earnings table again.

After the first few checks are calculated, the table access programs typically have all the details about all the earnings and deductions for that particular pay run. Ideally, Pay Calculation reads the Earnings table only once for each earnings type during a given run.

The key to running a process like Pay Calculation quickly is to reduce the number of hits on the database tables. This is why, if you have an Earnings table on the database containing 300 earnings types, we do not want Pay Calculation to read the Earnings table 300 times. For a particular pay group, you might use only 20 earnings types, so the table access programs reads them into the table array once, as they're first encountered.

Increasing the Occurs Count on Table Access Programs

If your company requires it, one fairly safe and easy modification you can make is to increase the occurs count on your table access programs.

The table access programs allocate a specified, limited amount of memory space to store in a table array all the details of particular pay process tables typical for one of your pay runs.

The table access program that manages the Earnings table is called PSPERNTB. What happens if the array it stores earnings data in is allocated to 50 earnings types, and your typical pay run requires more than 50? PSPERNTB attempts to go find some information about this new earnings code, and get its, but there's no more room in the array.

In this situation, PSPERNTB moves something else out of the array and replaces it with the information for the new earnings code. It does this without comment. It replaces one of the entries with a new one.

In this manner, you can encounter problems with the Earnings table, or other tables, on the database, if the amount of storage isn't enough. There are two ways to determine whether you're doing this:

The easy way.

Make a performance analysis of the payroll process and check the table accesses on particular tables. If the Earnings table, for example, is being hit more than you would expect—more than the number of entries in your Earnings table—then you know that you're starting to stress it.
The more difficult way.

Insert a display into PSPERNTB into the particular piece of code that actually does move one of the earnings codes out and send a message to yourself, saying something to the effect of, "I'm starting to replace entries in the Earnings table, you might want to look at this."

Note:

It's important to recognize that this kind of table destruction might be costing you a lot of processing time.

If you determine you're destroying a table, you can increase the occurs count in the appropriate table access program. For example, let's look at a piece of the unmodified code in PSCDEDTB, the Deduction Table Manager

02  DEDUCTION-COUNT  PIC 9999  VALUE ZERO  COMP.

    88  DEDUCTION-COUNT-MAX    VALUE 500.

02  DED-CLASS-TABLE-MAX    PIC 9999  VALUE 6     COMP.

02  DEDUCTION-TABLEOCCURS 500

    INDEXED BY

    DEDTB-IDX

    DEDTB-NEXT-IDX.

  03  PLAN-TYPEPIC XX.

88  PLAN-TYPE-DEDUCTION VALUE '00'.

88  PLAN-TYPE-HEALTH    VALUE '10' THRU '19'

...

  03  DEDCD     PIC X(10).

This is saying that you can have 500 deductions total for a pay run for any pay calendar. And if you exceed the 500, PSCDEDTB is going to start quietly replacing them. If you require a larger number of deductions, you want to replace the DEDUCTION-COUNT-MAX VALUE and DEDUCTION-TABLE OCCURS values of 500 with larger values.

PeopleSoft has built the Payroll system so that it runs under DOS; and with DOS there are severe memory constraints. Under MVS/DB2, OS/2, or UNIX, the memory constraints effectively go away. Increasing these two 500s to 999s, for example, isn't going to cost you anything other than storage, and on non-DOS platforms, storage is usually readily available.

This type of modification is not particularly difficult to deal with when you upgrade to a new Payroll for North America release. When you upgrade, PeopleSoft delivers a whole new set of source. At that point, you use your installation Compare utility to compare the new source we send you with the old source.

The code in the previous example is a piece of the copy section called PSCDEDT1, and when you run the Compare utility, you'll see that the new incoming source for PSCDEDT1 contains different values. You'll probably just decide to retain your change to the code.