3.3.3 Field Rules/Triggers and the Object Access Module
The field (and file) level validation rules which you have defined in the repository are implemented in the Object Access Module, (also referred to as the I/O Module). The repository validation rules cannot be tested until an Object Access Module (OAM) has been created. For example, a data entry screen may include the Employee Number field. This field on the screen has no validation rules associated with it until the field is used to perform a file operation such as adding a new record to the Employee Master file. When the insert to the database is performed, the Employee Number validation checks in the OAM are executed and error message will be sent back to the screen.
When you have added or changed any of the validation rules in the repository, it is necessary to make the file operational again. The OAM protects the functions from changes to rules so that the functions do not have to be recompiled. When you change a field level rule, you must use impact analysis tools to determine which files, if any, are affected by the rule change. You must manually request that the appropriate Object Access Modules be rebuilt. LANSA will not detect this change. If changes are made to rules a the file level, these changes are detected by LANSA and will cause the OAM to rebuilt.