tablesONLINE/CICS uses the security mechanisms of its environment — CICS login and transaction-access security and the tableBASE password mechanism — so some security is achieved without writing exit programs.
Where tighter security is required, you can make the tablesONLINE/CICS System sign-on exit invoke a security package such as RACF, ACF2, or Top Secret. All user and application IDs passed to tablesONLINE/CICS are then validated by the security package. Typically, there is only one such exit program per installation and developers do not have access to it, so it will not be covered in any detail here. See the security section in the tableBASE Administration Guide.
User exits could also be written for other security tasks. Consider the table with critical data that should be accessible only to certain employees. This might be protected by making it accessible only to one application and limiting access to that application via the Application Control Table (ACT), with or without a System sign-on exit call to a security package. The tableBASE password mechanism would also protect the table. These are the usual protection methods.
There is also a third option. Install a TOB exit in that table’s View to check a table of authorized users and refuse to open the table for others. This controls all tablesONLINE/CICS access and offers one advantage over using the ACT as a control mechanism—a manager could be given control over this mechanism without being given access to the ACT. In some applications, this ability to give departmental managers control over some security mechanisms for their own employees without compromising overall system security by allowing many people access to its mechanisms, might be essential.
Data encryption on non-key fields could be implemented either in field-level exit programs or in an IXF exit. The exit programs and Views involved would look much like those described below for the example which translates between state ZIP codes (NY, MI, etc.) and state names (New York, Michigan, etc.) except that they would be encrypting and decrypting with some user algorithm rather than simply encoding and decoding via tableBASE lookup.
Encryption of key fields would affect tableBASE searches so whole row data encryption, while possible, would be trickier. Hash searching on the encrypted keys would work provided the encryption algorithm guaranteed a unique encrypted form for each unique key. You would have to decrypt in the IIB exit and encrypt in the item-level output exits.