Database Management

This chapter describes the activities you need to perform to implement the OpenFrame/HiDB database.

1. Overview

Managing a HiDB database includes the activities of designing, implementing, loading, and maintaining a database.

The following provides further information about each management.

Database Design

Define a data structure by analyzing user requirements. The data structure shows what kind of data will be stored in the database and how data is related.

Once you select a data structure, you can design the database. In this phase, you determine the detailed items and options to define the database.
Database Implementation

You use a macro assembler to implement programs to access the database using its features.

Database implementation is divided into two main activities of coding Database Descriptor (DBD) and Program Specification Block (PSB) scripts, and compiling them. You also need to define Application Control Block (ACB).
Database Loading

Once a database is implemented, you need to write an initial load program and use it to load data into the database.

Once data is loaded into the database, applications can perform tasks on the database. To use mainframe data in HiDB, the data needs to be migrated into HiDB.
Database Maintenance

When you start using a database, you need to perform database performance monitoring and tuning. A regular monitoring helps you to determine when to tune your database.

2. DBD

Once you finish designing a HiDB database and before running applications on it, DBA must create Database Descriptor (DBD) files and compile them so that the HiDB system has access to the physical or logical features of the database.

A DBD is a collection of macro assembler commands that define database structure, access methods, segments and fields of database records, and the relationship between segment types. In this and other relevant documents, a collection of such macro assembler commands is called DBD metadata.

The following describes how to store DBD metadata in a metatable by using the DBDGEN utility.

DBD Generation Process

DBDGEN takes a DBD macro assembler script as an input. It uses an assembly compiler to store the DBD metadata in the relevant metatable. The metadata in the metatable is used to process database records.

In HiDB, dbdgen tool is provided to create DBD control blocks.

Each database implementation requires an input script.

The following describes each statement in an input script.

Statement	Description
DBD statement	Database name and DL/I access method.
DATASET statement	Attributes for the data set used as physical data storage of the database. Depending on the type of the database, you can define up to 10 data set groups and use one DATASET statement per data set group. Each DATASET statement is followed by a SEGM statement and all segments defined in the SEGM statement are stored in the data set group.
AREA statement	In case of DEDB, the AREA statement, which defines data areas of DEDB, is used instead of the DATASET statement. Up to 240 AREA statements can be used to define multiple data areas in a database. The AREA statement must be placed between a DBD statement and the first SEGM statement.
SEGM statement	Segment type in a database. The SEGM statement defines the location of segments in the hierarchical structure, and their physical attributes and relationships. A segment must be hierarchically defined in a structure with up to 15 levels of depth and up to 1000. Added to syntax of the source system, it can specify EXTPROC and GNALLPARENT parameters. For more information, refer to Unique Syntax for Database Definition.
FIELD statement	Specific segment field in a segment. The FIELD statement must be preceded by the SEGM statement of the segment that it belongs to. The sequential field and the fields specified in an SSA of a DL/I call must be defined in a FIELD statement.
LCHILD statement	Secondary index or logical relationship between two segment types. It also defines the relationship between index database and root segment in a HIDAM database. To define the index relationship, specify the INDX and SYMB values in the PTR parameter and the definition of logical relationship specifies SNGL, DBLE, and NONE.
XDFLD statement	Use the XDFLD statement only for secondary index relationships. The XDFLD statement defines the name of an indexed field that is associated to an index target segment type, identifies the index source segment type, and identifies the index source segment fields that are used in creating a secondary index. SRCH: field to be specified as search conditions in the user application. SUBSEQ: not used as a search key, but in addition to the SRCH field, HiDB specifies a field to be managed by the key of the secondary index. DDATA: field to be used as additional data for the Index segment, not used as a search key.
DBDGEN statement, END statement	DBDGEN and END statements are defined at the end of the DBD creation script and have the following meaning: DBDGEN: last statement to indicate the end of DBD definition END: last statement of the input script

Statement

Description

DBD statement

Database name and DL/I access method.

DATASET statement

Attributes for the data set used as physical data storage of the database. Depending on the type of the database, you can define up to 10 data set groups and use one DATASET statement per data set group.

Each DATASET statement is followed by a SEGM statement and all segments defined in the SEGM statement are stored in the data set group.

AREA statement

In case of DEDB, the AREA statement, which defines data areas of DEDB, is used instead of the DATASET statement. Up to 240 AREA statements can be used to define multiple data areas in a database.

The AREA statement must be placed between a DBD statement and the first SEGM statement.

SEGM statement

Segment type in a database. The SEGM statement defines the location of segments in the hierarchical structure, and their physical attributes and relationships.

A segment must be hierarchically defined in a structure with up to 15 levels of depth and up to 1000.

Added to syntax of the source system, it can specify EXTPROC and GNALLPARENT parameters. For more information, refer to Unique Syntax for Database Definition.

FIELD statement

Specific segment field in a segment.

The FIELD statement must be preceded by the SEGM statement of the segment that it belongs to. The sequential field and the fields specified in an SSA of a DL/I call must be defined in a FIELD statement.

LCHILD statement

Secondary index or logical relationship between two segment types. It also defines the relationship between index database and root segment in a HIDAM database. To define the index relationship, specify the INDX and SYMB values in the PTR parameter and the definition of logical relationship specifies SNGL, DBLE, and NONE.

XDFLD statement

Use the XDFLD statement only for secondary index relationships. The XDFLD statement defines the name of an indexed field that is associated to an index target segment type, identifies the index source segment type, and identifies the index source segment fields that are used in creating a secondary index.

SRCH: field to be specified as search conditions in the user application.
SUBSEQ: not used as a search key, but in addition to the SRCH field, HiDB specifies a field to be managed by the key of the secondary index.
DDATA: field to be used as additional data for the Index segment, not used as a search key.

DBDGEN statement,

END statement

DBDGEN and END statements are defined at the end of the DBD creation script and have the following meaning:

DBDGEN: last statement to indicate the end of DBD definition
END: last statement of the input script

3. PSB

An application does not need to access all segments and fields in a database. Moreover, in some cases, some segments or fields are not accessible for security reasons or integrated management purposes.

By creating and compiling program specification blocks (PSB), DBA enables a particular application to read or perform operations on a segment or field in the database. PSB is a collection of macro assembler commands that describe how applications access the segments of the database. A PSB consists of a number of program communication blocks (PCB), and each PCB defines application’s permissions to read from or write to relevant databases. In this and other relevant documents, the collection of macro assembler commands in a PSB is called PSB metadata.

Applications can have multiple PCBs. This means that an application can have multiple database views and can concurrently access multiple databases.

There is another type of PCB named Alternate PCB. Alternate PCBs are used to define Alternate Message Destination in online programs.

The following describes how to store PSB metadata in a metatable by using the PSBGEN utility.

PSB Generation Process

PSBGEN takes a PSB macro assembler script as an input. It uses an assembly compiler to store the PSB metadata in the relevant metatable and uses it to process database records.

In HiDB, psbgen tool is provided to create PSB control blocks.

The following describes each statement in an input script.

Statement	Description
Alternate PCB statement	Destination to send online transaction messages to. This is the first of the two PCB statements that can be used in the input script. This statement must be located at the start of the script.
Database PCB statement	Name of DBD of the database that the application program is trying to access. This is the second of the two PCB statements that can be used in the input script. This statement also defines what the application can do for the segments stored in the database (GET, INSERT, REPLACE, and so on). The databases specified in this statement can be either physical or logical. There must be one database PCB for each database that the application program accesses.
SENSEG statement	Type of segments to which the application program is sensitive. There must be one SENSEG statement for each segment.
SENFLD statement	Field of segments to which an application program is sensitive. The SENFLD statement must be used with the Field-Level Sensitivity function.
PSBGEN statement	Name of PSB and various attributes of the application. The attributes include program language used by the application and the maximum size of I/O buffer, and others.
END statement	There must be an END statement at the end of the PSB generation script. The END statement indicates the end of input statements to the psbgen tool.

Statement

Description

Alternate PCB statement

Destination to send online transaction messages to. This is the first of the two PCB statements that can be used in the input script.

This statement must be located at the start of the script.

Database PCB statement

Name of DBD of the database that the application program is trying to access. This is the second of the two PCB statements that can be used in the input script. This statement also defines what the application can do for the segments stored in the database (GET, INSERT, REPLACE, and so on).

The databases specified in this statement can be either physical or logical. There must be one database PCB for each database that the application program accesses.

SENSEG statement

Type of segments to which the application program is sensitive. There must be one SENSEG statement for each segment.

SENFLD statement

Field of segments to which an application program is sensitive. The SENFLD statement must be used with the Field-Level Sensitivity function.

PSBGEN statement

Name of PSB and various attributes of the application. The attributes include program language used by the application and the maximum size of I/O buffer, and others.

END statement

There must be an END statement at the end of the PSB generation script. The END statement indicates the end of input statements to the psbgen tool.

4. ACB

The ACBGEN utility generates an application control block (ACB) metadata by combining the PSB and DBD metadata. For online applications that use a HiDB database, ACB metadata must be generated before starting the online server.

In HiDB, acbgen tool is provided to create ACB control blocks.

The following shows how to store ACB metadata in a metatable by using ACBGEN.

ACB Generation Process

ACBGEN, a management utility for ACB, retrieves the PSB and DBD metadata from the PSB and DBD metatables to create ACB metadata.

By using ACBGEN, you can generate ACB metadata for all PSBs in the PSB metatable. You can also designate a particular PSB or DBD name to generate ACB metadata. ACB metadata created with PSB metadata is stored in the PSB metatable and ACB metadata created with DBD metadata is stored in the DBD metatable.

When an online program is scheduled for execution, the ACB metadata that is created from the PSB that the online program uses is immediately loaded into memory. This reduces the time consumed in application scheduling.

5. Variable-Length Segment

To define variable-length segments, the max and min values must be defined with the BYTES item in the SEGMENT statement of the DBD. When an application calls a DL/I to access a database with variable-length segments, the length information of the segment must be defined in the first 2 bytes of the segment’s I/O area.

Variable-length segments continue to be recorded in the current record as long as there is enough room to accommodate the segment length specified by the application. If the saved segment is replaced with longer data, which exceeds the length limit, using the REPL command, the segment prefix area and data area are saved in separate records. In this case, the segment prefix area stores the address of the new data area. The space that was occupied by the existing data area is now empty and can store other data. When variable-length segments are replaced with shorter data using the REPL command, the remaining space can also be used to store other data.

Since variable-length segments only occupy the amount of storage required to store the actual data, they can save storage space compared to fixed-length segments. Larger records and smaller segments reduce the number of I/Os, which improves the speed of batch INSERT operations. Too many REPL calls that increase the segment length creates segment splits, which increase record I/Os and lower performance.