Salary range checking

Another example of IXF validation is range checking on salaries in a personnel table. tablesONLINE/CICS will ensure that the salary field has a numeric value, but that is hardly an adequate constraint. Range validation capabilities are provided with field definitions in tablesONLINE/CICS Views, but this may not be enough for a thorough validation check.

A field-level exit might be written for salary fields, but what could it use for rules? Any test for a positive integer less than, say, 200,000 would be reasonable in most companies, but not adequate protection in any.

Implementing an inadequate rule is dangerous. Consider the less than 200,000 rule. A typo producing ‘92,000’ instead of ‘29,000’, for example, is accepted. The cheque ends up framed on the recipient’s office wall.

A better rule would validate pay rates against limits for the job category. This requires access to category information from another field of the item, so it must wait until IXF exit time. Trying to do it at field validation time would create unreliable code as described under ‘Misused Field Exits’ above.

The code to implement this rule is just a table lookup with job category as key and an upper and lower boundary as retrieved data. Now the range check is more useful. Moreover, the system is easily maintained. If pay scales change, update the boundary table entries for the categories affected. All future validations will use the new scales.

Since all fields in the row are available at this point, more complex conditions could also be used. In some companies pay scales vary with location as well as by category. The New York office pays New York’s “going rates”; Cleveland uses another scale. The plant in Left Overshoe, Manitoba offers higher salaries as “isolation pay” while the one in Trendville, CA offers even more so that staff can afford housing there.

This can readily be handled in any of several ways. One way is to put the complexity into the table, i.e., make location as well as category part of the key for looking up range boundaries. You could also handle the problem in the code by adding conditional branches in the exit program. Consider the difficulty of adding a new region in each case: it is far preferable to be able to do this by table editing than to have to modify and recompile code.