DEDB area design guidelines

When designing a DEDB, be aware of the considerations and guidelines related to the DEDB area.

The following considerations for DEDB area design also help explain why DEDBs are divided into areas:

• DEDBs should be divided into areas in a way that makes sense for the application programs.

  For example, a service bureau organization makes a set of applications available to its customers. The design calls for a common database to be used by all users of this set of applications. The area concept fits this design because the randomizing routine and record keys can be set so that data requests are directed to the user's area only. Furthermore, on the operational side, users can be given specific time slots. Their areas are allocated and deallocated dynamically without interrupting other services currently using the same DEDB.

  National or international companies with business locations spanning multiple time zones might take advantage of the partitioned database concept. Because not all areas must be online all the time, data can be spread across areas by time zone.

  Preferential treatment for specific records (specific accounts, specific clients, and so on.) can be implemented without using a new database, for example, by keeping more sequential dependent segments online for certain records. By putting together those records in one area, you can define a larger sequential dependent segment part and control the retention period accordingly.

• The impact of permanent I/O errors and severe errors can be reduced using a DEDB. DL/I requires that all database data sets, except for HALDB databases, be available all the time. With a DEDB, the data not available is limited only to the area affected by the failure. Because the DEDB utilities run at the level of the area, the recovery of the failing area can be done while the rest of the database is accessible to online processing. The currently allocated log volume must be freed by a /DBR AREA command and used in the recovery operation. Track recovery is also supported. The recovered area can then be dynamically allocated back to the operational environment.

  Make multiple copies of DEDB area data sets to make data more available to application programs.

• Space management parameters can vary from one area to another. This includes: CI size, UOW size, root addressable part, overflow part, and sequential dependent part. Also, the device type can vary from one area to the other.
• It is feasible to define an area on more than one volume and have one volume dedicated to the sequential dependent part. This implementation might save some seek time as sequential dependent segments are continuously added at the end of the sequential dependent part. The savings depends on the current size of the sequential dependent part and the blocking factor used for sequential dependent segments. If an area spans more than one volume, volumes must be of the same type.
• Only the independent overflow part of a DEDB is extendable. Sufficient space should be provided for all parts when DEDBs are designed.

  The /DISPLAY command and the POS call can help monitor the usage of auxiliary space. Unused space in the root addressable and independent overflow parts can be reclaimed through reorganization. It should be noted that, in the overflow area, space is not automatically reused by ISRT calls. To be reused at call time, the space must amount to an entire CI, which is then made available to the ISRT space management algorithm. Local out-of-space conditions can occur, although some available space exists in the database.

• Adding or removing an area from a DEDB requires a DBDGEN and an ACBGEN. Database reload is required if areas are added or deleted in the middle of existing areas. Areas added other than at the end changes the area sequence number assigned to the areas. The subsequent log records written reflect this number, which is then used for recovery purposes. If areas are added between existing areas, prior log records will be invalid. Therefore, an image copy must be made following the unload/reload. Be aware that the sequence of the AREA statements in the DBD determines the sequence of the MRMB entries passed on entry to the randomizing routine. An area does not need to be mounted if the processing does not require it, so a DBDGEN/ACBGEN is not necessary to logically remove an area from processing.
• Careful monitoring of the retention period of each log allows you to make an image copy of one area at a time. Also, because the High-Speed DEDB Direct Reorganization utility logs changes, you do not need to make an image copy following a reorganization.
• The area concept allows randomizing at the area level, instead of randomizing throughout the entire DEDB. This means the key might need to carry some information to direct the randomizing routine to a specific area.