A firm's most important asset is its data. For many firms, this data lives on a mainframe and is religiously protected. This protection of data must be maintained, so we will start by looking at how this protection is done.
With the traditional mainframe, the application validates the data and forwards the data to the mainframe for storage. The mainframe handles the storage and retrieval of records without using business rules. This approach results in each application duplicating validation requirements. The typical Customer Information Control System (CICS) application using the VSAM file system does not have a server database as the back end—it's only a file system. The movement of applications from VSAM to more advanced products such as DB2® or ORACLE® rarely results in a redesign of the system to use database server features. Validation logic still lives in the application and not in the database for most mainframe applications.
The server validates all data in client-server architecture. The server never trusts the data passed from the application. The server protects the data by implementing business rules. The application may do some validation to improve the user interface, but not in place of server validation. The application only does some ID checks.
Today, I would classify mainframe databases into the following classes:
These are functional classes, not software brands. If you are using a product that supports procedures and triggers, the mainframe database may be either Type I or Type II. If triggers are used to enforce the business rules, the database is a Type I.