Table of Contents
This section discusses remaps for the data set record and the global data record, and the use of logical databases by host language programs.
The database administrator can control security at the following three levels:
-
Item-level security. This controls which items within a record a user can access or modify.
-
Record-level security. This controls which records within a data set are visible to the user and which records, if any, the user can alter.
-
Structure-level security. This controls which data sets, sets, subsets, and other database structures a user can invoke. Remaps provide item and record-level security, while logical databases provide structure-level security.
In addition to providing security, remaps and logical databases provide data independence. Data independence is the ability to make changes to the database without requiring existing programs to be reprogrammed or recompiled. The database administrator can use the DASDL update and reorganize operations to make changes to an existing database which will affect the format of data set records. Programs which invoke the data set directly must be recompiled following the change. Programs which use remaps need not be recompiled so long as the logical databases and the remaps they invoke remain the same.
It is important to consider data independence and security when the database is first defined. If database security is of no concern, or if there is little chance that record formats will change, or if there are so few programs using the database that program recompilation is not a major problem, then remaps and logical databases are not necessary. If security and data independence are of prime importance, all programs should invoke logical databases which contain only remaps. Thus, global data remaps can be used only with logical databases. By setting up logical databases that reference some data sets directly and others through remaps, one can achieve security and data independence at intermediate levels.
