Field-level data validation

The most common application of exit programs is data validation. Some validation—checking field values against View data definitions — is built into tablesONLINE/CICS and does not require an exit program. This will, for example, ensure that only numeric values are entered into the salary field of a personnel record, or that the Date Of Hiring field holds a syntactically valid date string. Similarly, range checking or existence checking for field data is available through built-in View capabilities.

The built-in validation checks only test syntax. If not all numbers, dates, character strings or whatever “make sense” in your application, then field-level exits may be needed.

A straightforward example is an exit to test whether a field describing a customer discount code holds a sensible value if that code is only valid for specific time periods. This could be an FOB exit looking for mixed-case input values or an FOA exit checking for upper-case codes only, after tablesONLINE/CICS had moved the data and performed lower-case to upper-case translation.

Doing the test after the move often means a simpler test, as in this example. It has the disadvantage that bad data is not caught until after it has been transferred. In a field-level or item-level exit this cannot corrupt data; the bad data has only been moved in memory, not stored to disk, and if the exit program has set the BYPASS-ACTION-IND to E, processing will not proceed until the error is corrected, so no permanent damage can be done.

Some inconvenience can be created, since old data is overwritten by the transfer. In the example, when the user gets an error message about the customer discount field there is only one way to discover what the value was before the error was made—cancel out of the row edit screen and reselect the row to pick up a fresh copy of the version on the table.

The sample exit EXITPGMC in the supplied education dataset performs a similar test for a gender field, with a few features thrown in to make a more interesting example.

Field-level exits can also perform specialized range checks and check for valid formats in entries such as part numbers, serial numbers, model numbers, invoice numbers, employee numbers, department codes, or any other data with a fixed format.

In many organizations it makes sense to provide a shared central library for reuse of tested exit code, thereby implementing corporate standards for important fixed format data.