Protecting tableBASE libraries and tables

Resource Access Control Facility (RACF) or equivalent protection can be placed on tableBASE libraries. If an unauthorized user attempts to open a protected library, the open attempt will fail with appropriate messages sent to the job’s JES log. An error code is returned to the user, which may result in an abend, depending on the abend status switch setting.

Concurrent multiple updates

When a table is identified for updating in a region with the use of the Open for Write command (OW), steps are taken to prevent other MVS tasks on the same or other MVS images from updating the same table. This is achieved by issuing an enqueue request that includes the Table Name and Table Library Dataset Name. The major enqueue name is TBLBASE. The scope of the enqueue is SYSTEMS.

An installation’s modifications to Global Resource Serialization (GRS) PARMLIB controls must not prevent the propagation of the major enqueue name throughout the complex. Failure to adhere to this can result in the corruption of the tableBASE libraries on DASD shared between several MVS images running tableBASE.

Since these requirements are beyond the scope of tableBASE software, you must ensure that these conditions are met if the same tableBASE table libraries are to be shared among separate MVS images.

tableBASE table protection

tableBASE tables can be individually protected on the library (read and write passwords) and when loaded in-memory (LOCK-LATCH). It is important to note that these passwords offer only limited protection against unauthorized use of tableBASE tables. More formal security can be implemented via user exits and 3rd party measures, such as RACF or equivalent security products. tableBASE user exits are documented in tableBASE Administration Guide.

tablesONLINE® exits provide security at the tables, fields and/or rows levels. For more information, please see the tableBASE Programming Guide.

Library table read and write passwords

Passwords are used to open tables from the library. However, once in memory, these tables can be accessed by any application with access to the memory. A read password protects a table from being opened for either read or write. A write password protects a table from being opened for write. For more information on passwords, see the tableBASE Programming Guide.

Table protection in the TSR

In a multi-threaded environment (e.g., CICS, DB2 SPAS, VTS-TSRs) tableBASE ensures that a table open in a TSR cannot be updated by more than one tableBASE command simultaneously. (An update command includes the table’s data, indices, and definition.) It also ensures that no commands that read the data will proceed until the update is completed. Such commands will wait on an internal lock.

To prevent processes from waiting indefinitely for a lock, use the TBOPT/TBOPTGEN LOCKTIMERC and LOCKTIMEWTO parameters. See Appendix A of the tableBASE Installation Guide.

TSR LOCK-LATCH

LOCK-LATCHES are used by tableBASE to protect a table in a TSR while an update is in progress. It can be used to ensure that an update process that requires multiple tableBASE commands will not be invalidated by intervening updates from another transaction or process. A LOCK-LATCH is set when the table is opened for write and is needed for any update access once it is set. For more information on LOCK-LATCHES see the tableBASE Programming Guide and the tableBASE Concepts and Facilities Guide.