IMS DB Compatible Production DBMS

Supported IMS Features

DLI Functions

• GU, GHU, GN, GHN, GNP, GHNP, ISRT, REPL, DLET
• Fast Path: FLD, POS
• GSAM: OPEN, CLSE
• AIBTDLI: INQY
• AERTDLI: CIMS, APSB, DPSB
• CICS DL/I calls: PCB, SCHD, TERM

Database Access Types

IMS DB provides several database access types, typically chosen for best performance as determined by the application.

• DEDB
• GSAM
• HALDB
• HDAM, HIDAM, HISAM, HSAM
• INDEX
• LOGICAL
• MSDB
• PHIDAM, PHDAM, PSINDEX
• SHISAM, SHSAM

Database Segment Types

• Uniquely keyed segments
• Non-uniquely keyed segments - first, here and last rules
• Non-keyed segments - first, here and last rules
• Fixed and variable length segments
• Segments containing source data for secondary index segments
• Logical children and logical parents
• DEDB sequential dependents (SDEP) segments

Database Recovery

DLI Program Batch Backout

Segment Search Argument (SSA)

Programs retrieve data by qualifying the retrieval with a Segment Search Argument (SSA). Enterprise Server provides compatible SSA support including:

• Up to 15 SSAs per call, each SSA limited to 4,000 bytes
• SSA relational operators supporting up to 125 boolean operations on each SSA
• SSA command codes

User Exits

The IMS user exits within Enterprise Server provide a mechanism to implement custom extensions to maximize compatibility with the original mainframe implementation. However, within Enterprise Server, exit routines must be written in COBOL rather than in Assembler as mainframe Assembler is not supported in production on open systems. This means that during any migration, existing mainframe exit routines written in Assembler must be converted to or re-written in COBOL as part of the migration.

The following IMS-specific user exits are supported:

• MFS field and segment edit routines.
• Sparse index exits.
• Data capture exits - The EXIT operand is supported for both the DBD and SEGM statements along with all of the EXIT options (DATA, PATH and CASCADE options) except the LOG option. The sub options for CASCADE (KEY, DATA and PATH) are also supported. A maximum of nine different exit routines can be specified for any one segment.
• All fields in the XPCB and XSDB parameter blocks.

Maximum Database Size

IMS production databases are implemented as IDX-8 files, so the theoretical maximum size for an IMS database is tied to the maximum size for an IDX-8 file. Micro Focus has not performed tests or performance benchmarks on IMS databases larger than 300GB. Very large databases could prove to be impractical in terms of performance and maintenance (time to rebuild, etc.). We recommend that you allocate time to test for accounts that are migrating large databases as part of the prototype or proof of concept process.

The internal database structure within Enterprise Server uses symbolic keys, rather than pointers, and maintains some redundant key information, increasing the amount of actual storage required for the IMS database on Windows, UNIX or Linux. However, the key and data compression performed within the Enterprise Server file system typically compensates for this overhead.

Two Phase Commit Architecture

The IMS DB Compatible Production DBMS uses a two-step commit protocol. All registered resources are sent commit requests. The sequence for commit depends on whether the resource supports a two-step sequence or not. For two-step resources, a "Prepare" is issued to each resource before sending the "Commit" step. If all Prepares succeed, commit processing begins. If any prepare fails, backout starts. When a resource responds negatively to the prepare, it means that it cannot complete a commit but it can complete backout or has already backed out.

Our two-phase commit architecture is similar to the two-phase commit support in mainframe IMS, and shares some of the same benefits; however, it does not provide recovery from failures that might occur during backout processing or during the second step of commit processing.

The main benefit of this two-phase process over a "single-phase" commit protocol is that it eliminates the integrity window between the time the application last accessed a resource to when commit processing begins. The Prepare step catches any failures that occur during this interval and begins backout processing. Contrast this with two separate resources using a single-phase protocol. In single-phase there is no Prepare phase, only a commit or backout. If the first commit succeeded but the commit to the second resource failed, you could have a mixed outcome.