Aug 1 ’09

Initial Project Analysis: An IMS to DB2 Conversion Example

by Editor in z/Journal

The fact organizations are facing tough economic times is an understatement. Mergers, acquisitions and compliance projects are in the forefront, leaving us minimal time to handle projects, such as conversions, within our limited time and budget. We’re regularly challenged to do more with less: less time, manpower and money. What happens when critical projects require an amount of analysis far beyond expectations? Must we accept the costs and inaccuracies of manual analysis or is there a better way to quickly and accurately determine the time and resources required for these projects?

This article presents an example of a successful project analysis for an IMS to DB2 conversion. The article doesn’t discuss the conversion itself, but data from the analysis was used to manage the conversion.

In IMS to DB2 conversions, employing a specific process for the analysis portion can help ensure a successful overall project. This process makes it possible to quickly determine the magnitude of the project, avoid potential problems that arise from inaccurate analysis, and eliminate unnecessary conversion of obsolete application elements. Using this process significantly reduces the time and manpower required for the analysis.

The Analysis Process

With any conversion project, it’s critical to accurately identify all application elements—jobs, programs, copybooks, files, Program Specification Blocks (PSBs), Database Descriptions (DBDs), etc.—to be included and to exclude obsolete application elements.

The analysis of the IMS to DB2 conversion project was organized into five phases:

1. Gathering application element information

2. Characteristics of application elements requiring conversion

3. Selecting application elements that require conversion

4. Assigning a complexity level to each application element

5. Reporting analysis results.

Gathering Application Element Information

Application element information was extracted from:

• Production source libraries, including Job Control Language (JCL), procedure, program and copybook libraries • Some system files, including the CICS System Definition (CSD) file and PSBs

• Batch execution and scheduling history

• Actual CICS program usage to capture information for dynamically loaded programs not in the CSD

• Application element change history.

A large amount of data was programmatically extracted and stored in files to allow manipulation of the information. Use of “error” and ”missing element” reports ensured all application elements were included in the files. We eliminated application elements that didn’t require conversion. After the analysis was complete, these files were regularly used by all programmers throughout the conversion project and were programmatically updated weekly. Figure 1 illustrates the files created in this first phase.

 

Characteristics of Application Elements Requiring Conversion

Determining the jobs and programs that should be included in the conversion project required identifying certain characteristics that would indicate whether IMS was being used by the program or job (such as naming standards used specifically for IMS application elements and IMS-specific syntax).

Performing a simple source search for IMS activity couldn’t directly identify all IMS programs for several reasons:

• Most IMS activity occurred in copybooks to standardize the processing. Each IMS segment was accessed and updated by a separate set of copybooks (e.g., copybooks to perform reads, deletes, add new segments, etc.). It was necessary to find all programs that used these copybooks.

• IMS databases were sometimes unloaded using an IMS utility. Programs using IMS segment layouts processed the resulting data as sequential data.

• Only a handful of online programs directly accessed IMS and performed all the IMS I/O. These programs passed IMS information in the commarea to other online programs. All online programs that used this commarea, or used copybooks for segment layouts, needed to be converted.

• Some programs used IMS index files as VSAM files instead of using IMS functions to access the data.

We looked for these characteristics:

• Customer-specific applications using IMS: Some jobs and programs used a naming standard to tie them to an application that used IMS.

• Identifying characteristics of IMS activity in program and copybook source: We looked for calls to CBLTDLI (COBOL and Assembler languages) and for application copybooks used to define segment fields for the programs and to execute IMS functions (get unique, get next, insert, delete, replace).

• Identifying characteristics of IMS activity in JCL and procedure (proc) libraries: This included JCL or proc that used data sets beginning with IMS.* or local high-level qualifier, JCL or proc executed by program DFSRRC00, and JCL or proc that executed an IMS utility program ( e.g . , DFSURG* , DFSUDMP0, DFSURPP0).

• Identifying characteristics of online IMS programs and copybooks: This included programs that used copybook DFHAID to indicate CICS usage and used copybook or macro DLIUIB to indicate the program used IMS. It also included items executed in an IMS Region in CICS or defined to a specific list or group for IMS in the CSD file.

Selecting Application Elements That Require Conversion

Next, we extracted and merged data from the application element files. The final files were imported into Excel spreadsheets that were used as checklists of JCL members, procedures, card members, programs, and copybooks to manage and monitor the project’s progress.

The relationships between application elements don’t lend themselves to simple unions because almost every relationship is many-to-many. That’s why we used an iterative process throughout the analysis. Each step added another relationship level, adding more jobs and programs to convert. For example, if a job executed one IMS program, other programs in the same job could be affected if the output of the IMS program changed. Similarly, a copybook used for an IMS segment might be used in a non-IMS program or job that didn’t execute IMS. These jobs and programs needed to be included in the conversion.

The analysis process provided the following lists:

• Batch and online programs that directly performed IMS functions or used copybooks that used IMS, or used called programs that used IMS

• Batch programs that used IMS segment layouts for input or output files

• Online programs that didn’t use IMS but used IMS segment layouts or commarea for processing

• Called subprograms used by the above that performed IMS functions

• Jobs that contained the above programs

• IMS database names, segment names and the programs that updated them.

Using the files created in the first phase, we proceeded with the iterative process shown in Figure 2.

 

Assigning a Complexity Level to Each Application Element

To determine how many programmers and how much time would be required for the conversion, we assigned a complexity level to each program. A program of:

• Low complexity required only a few variable name changes and/or the addition of one or two SQL statements without affecting the logic of the program

• Medium complexity required some logic changes to replace IMS with DB2 (most didn’t perform updates to DB2 tables)

• High complexity needed to be almost completely rewritten and redesigned.

Because all the detailed information was available in the analysis files, we could quickly evaluate the characteristics of the application elements.

For each program, we examined:

• IMS databases and segments used

• Data Language/I (DLI) calls

• Input, output and updated files (usually VSAM)

• Lines in the program

• DB2 tables used

• Read-only and update SQL statements

• Called programs and the number of calls to each program

• WS copybooks performing IMS functions and copybooks for IMS segments, indices, etc.

Additionally, for each online program, we examined the commarea and number of XCTL (transfer of control), LINK, LOAD, etc.

To improve the accuracy of the time estimate, we quickly “test converted” one program from each category and adjusted the estimated time for each category accordingly. This required 16 hours.

Reporting the Results of the Analysis

Using the complexity levels assigned in the last phase, we produced the conversion estimate shown in Figure 3.  

Conclusion

Our automated analysis process for the IMS to DB2 conversion saved a tremendous amount of time—more than 90 percent—in man-hours alone. The analysis took one week (for two people). Yet if done manually, it would typically have taken two months for a team of four. The automated process quickly provided the locations and characteristics of active application elements that required conversion and, just as important, those that were obsolete and could be eliminated.

This process greatly accelerated the conversion project by providing the ability to quickly analyze enormous amounts of data and avoid time-consuming, error-prone manual analysis. The same process provided the basis for guiding the project through the coding, testing, acceptance, and production implementation phases.