IMS Database Utility (IMSDBU)

IMSDBU is a database management tool that offers a wide range of operational control. You can use it to initialize, load, unload and reorganize databases. You can tailor its operation to control file naming conventions, progress reporting, statistics, audit reports, and more.

IMSDBU runs as a standalone utility; a PSB is not required to use it. It operates on physical databases defined using the DBDGEN function. Because it runs outside of the Application Region, it can provide streamlined operation.

IMSDBU Features

Several IMSDBU features help you to manage your IMS databases, including:

High Performance
IMSDBU can load and unload a database in a fraction of the time taken by an application program issuing DL/I calls. This is because IMSDBU communicates directly to the physical access layer in the hierarchical database engine. This layer is common between the MFIMS DL/I language interface and IMSDBU to ensure consistent formatting of databases and segments.
Load and Unload Exits
The segment exit enables a user-written program to control segment selection and modify segment data during load and unload processing. The exit program is called for each database segment. It can delete the segment, modify the segment data, or pass it through unchanged. If a segment is deleted, all of its children segments are automatically deleted. The segment exit is enabled using the SEGEXIT directive.

The compression exit is used for the input file to the Load and the output file for Unload. It allows for segment compression and/or encryption of the input or output files. It is not used for the data stored in the MFIMS database. A standard routine named CBLDCIMS is provided to decompress input and compress output files. A user-written program can perform different segment encoding. This exit is enabled using the COMPRESS directive.

The IMSDBUV sample program for unloading IMS/ESA databases can create compressed files for input to the IMSDBU Load and decompressed using the CBLDCIMS routine.

Details of these exits are documented in the sample file DBUPARMS.CPY, located in the %PUBLIC%\Documents\Micro Focus\Enterprise Developer\Samples\Mainframe\IMS\Classic\Examples directory by default..

Progress Reporting
IMSDBU reports the progress it makes while processing a database function. When performing a database load or a logical pointer update, it shows a 'percent complete' and an estimate of the time remaining. For database unloads, a percentage cannot be calculated so IMSDBU displays the segment number in process. The frequency of progress reporting is controlled by the PROGRESS directive.
Detailed Reporting and Statistics
A detailed report showing the results of a database function is available. This report is produced as an ASCII text file. It can reflect the most recent function or can maintain a historical record. This reporting is controlled by the LIST and LISTOPEN directives. Items included in this report are:
  • A starting message indicating the date/time, database name and the function performed.
  • 'Options in effect' which lists the directives used.
  • Information, warning and error messages issued during execution.
  • Database statistics with the Load and Unload functions. These include segment counts, maximum per root, and average per root listed by segment type.
  • The ending message produced by the function. This states the success or failure of the function and the ending return code value. This message also appears in the historical activity log.
Historical Activity Log
A historical activity log can be kept for all IMSDBU activity. An entry is written to the log when a function completes. This entry consists of the date and time, database name and the ending message for a function. The most recent entries are written to the end of the file. This log is produced as an ASCII text file and is controlled by the LOG directive.
Simplified Logical Loading
IMSDBU loads all physical databases in the same way - with the Load function. For databases containing logical children, a pointer update function connects the logical children to their parents and resolves paired segments after loading.

Logical database loading is further simplified by the use of the Makelist function. Makelist generates all of the required steps to load a complete set of logically related databases. You provide one DBD name and Makelist follows its relationships to create the set. From this, it generates a file for input to the Runlist function to execute the steps.

Specialized and Generic Load Inputs
IMSDBU provides a special-purpose input file layout for loading databases. This file layout is created by the IMSDBU Unload function or by the IMSDBUV program. IMSDBUV is provided as COBOL source code and is installed in the source directory. You can transfer this program to your mainframe, compile, and run it to extract IMS/ESA segment data.

This special-purpose layout provides for simpler loading of the database. The physical characteristics of the file and data are stored in header and trailer records in the file. This includes items such as the placement of the segment name, segment data, and compression options. Loading a database with this format is as easy as naming the input file and using the LAYOUT(D) directive. For reference, the IMSDBU layout file is a variable length file to reduce storage requirements and file transfer times.

IMSDBU also supports a special purpose IBM layout. This is specified using the LAYOUT(I) directive and supports input files created using IMS/ESA DB Unload Utilities such as DFSURGU0. This layout sets the directive values SEGM(7), DATA(36), RECFM(V) and NOCOMPRESS. This layout honors delete byte settings in the input file and directs IMSDBU to skip over segments marked as deleted.

IMSDBU supports sequential input files using the LAYOUT(S) directive. This enables you to load an IMS database from an input file produced from COBOL program or downloaded from the mainframe using Drag and Drop as a sequential file.

IMSDBU supports generic layouts for the input load files using the LAYOUT(G) directive. The generic layout must contain the segment name and segment data in the same position of each record. It can be a fixed or variable length segment. A SEGM directive indicates the position of the segment name in the record area. A DATA directive indicates the starting position of the segment data. The segments in the file must be in hierarchical order, but do not have to be in key sequence.