Periodically (and unpredictably) BenAdmin may issue a Maximum Number of Pay Calendars error message in the program section get-cal. Sometimes this may occur at the end of the year after you have created pay calendars for the new year. Often the error seems unpredictable - rerunning BenAdmin will eradicate the error.
The reason for this is that the Pay Calendar is a case where we cumulatively read in calendars, as needed for each employee we process, until we're full, and then we abort. Since the system must accommodate all possible event date rules, we read in all calendar rows from the start date forward into the future for all built-out entries. Standard practice is to build out the entire current year, or the next year when you get well into the current year. As you can see from the SQL, you would not want to build out years into the future, since that is going to be returned to BenAdmin unnecessarily. One thing that is controllable by the customer is that "starting date": it's either the OE Event Date, or it's the EM Start Event Date. So if the customer has not advanced the Start Event Date for a while, they might want to consider doing that.
As currently configured (PSCCALTB.CBL), the Pay Calendar array can hold 5000 total pay-period rows spread across 250 separate Company/Paygroup combinations. This is a reasonable mix of monthly (12 pay-period rows) through weekly (52 pay-period rows) pay groups. Similarly, as currently configured (PSCBATBL.CBL), the Eligibility Override array can handle an aggregate of 1500 entries, across all Elig Rules being referenced.
Here's the SQL that retrieves the pay calendars. To test how many pay calendar entries are actually on your system, copy the SQL into Query Analyzer or SQL Talk, change the variables to match the values on your system, and see how many rows the SQL retrieves.
SELECT
PAY_BEGIN_DT
,PAY_END_DT
,COMPANY
,PAYGROUP
FROM PS_PAY_CALENDAR
WHERE COMPANY=:1
AND PAYGROUP=:2
AND PAY_END_DT>=:3
AND PAY_OFF_CYCLE_CAL = 'N'
ORDER BY
COMPANY ASC
,PAYGROUP ASC
,PAY_END_DT ASC
The best solution is to move up that Start Event Date on the installation table.