IBM COBOL/370 Upgrade

Overview

Symptoms

Companies with an investment in legacy IBM COBOL applications will have to migrate those applications in the near future to IBM's newer language standards as support for OS/VS COBOL was discontinued in June, 1994.

The newest language standard is IBM COBOL/370. This language level includes all the features available in the COBOL 85 standard, plus some new intrinsic functions and object-oriented language extensions, as well as support for the Language Environment/370 (LE/370). LE/370 introduces a common run-time environment across language platforms currently including COBOL, PL/I and C. Support for FORTRAN will be added in a future release.

In keeping with its objective of standardizing language platforms and architectures around a centralized model, IBM is also introducing COBOL for VSE, COBOL for OS/2 and COBOL for AIX, to increase portability and flexibility of applications by creating a consistent language implementation among COBOL systems.

This scenario will focus on the migration of OS/VS COBOL systems to COBOL/370 standard. If desired, however, this scenario could be used as the framework for a migration from OS/VS COBOL to VS COBOL II, DOS/VS COBOL to COBOL for VSE or even DOS/VS COBOL to COBOL/370.

The IBM COBOL/370 upgrade approach outlined in this document applies to organizations that have the following characteristics:

· Large scale and/or critical mainframe IBM COBOL applications utilizing language levels for which IBM has discontinued support

· Management committed to move the current systems to a new language level

· Identified, business driven requirements to take advantage of visual development and/or object oriented technologies while retaining current investment in application source code and programmer skill set

· Systems in need of virtual storage constraint relief

· Strategic directive to employ distributed processing technologies in new and existing applications

· Language level upgrade to the new COBOL standard can serve as a first step toward a desired OS/2 client/server migration

Requirements

Requirements for COBOL/370 migration include:

· Migration to LE/370 run-time platform first

· Verification that system tools and products that require run-time libraries (common execution libraries, condition handling routines, common dump, etc.) are LE-enabled and can run without disruption in the new LE environment

· Sufficient storage space to accommodate the following storage requirements

- for COBOL/370 - 30 cylinders of 3390 or equivalent

- for LE/370 - 45 cylinders of 3390 or equivalent

- for VS COBOL II Rel. 4.0 - 27 cylinders of 3390 or equivalent

- space for 2 COBOL compilers and the new run-time libraries

· All new development after run-time migration to be undertaken using the new COBOL/370 language standard

· Future modification of all source to be done in COBOL/370

· Organization wide conversion to COBOL/370 will require phasing and staging of systems (CPU's) as some are completed and others are not

· Migration to the new language standard will require some programmer retraining

· Potential to perform migration of COBOL applications from mainframe to workstation environment will now exist

· Interlanguage communication with other high-level languages (besides COBOL, C, and PL/I) might be limited or non-existent with LE/370. LE/370 Release 2 and 3 do not support PL/I multitasking.

· Vendor products should be LE/370 and COBOL/370 enabled.

· MVS/ESA Version 3.1.3 and above is required with COBOL/370 (without OO extensions).

· MVS/ESA Version 4 or above is required with COBOL/370 (with OO extensions).

· COBOL/370 Release 2 requires LE/370 Release 5.

· COBOL/370 Release 2 will no longer support IMS Version 2.

· OO COBOL requires COBOL/370 Release 2, LE/370 Release 5, MVS Version 4 or 5, and SOMobjects product 5696822.

· For migration to COBOL/370, the following release levels are required:

- CICS/ESA V3.3
- IMS/ESA V3.1 for CBLTDLI and CTDLI
- IMS/ESA V3.2 for CEETDLI
- IMS/VS V2.2 or higher
- DB2 V2.1 or higher

· For migration to VS COBOL II Rel. 4.0 (an intermediate step to migration to COBOL/370), the following release levels are required:

- CICS/ESA V3.1
- IMS/ESA V3.1 or higher
- IMS/VS V1.3 or higher
- DB2 V1.3 or higher

COBOL/370 Migration Strategy

A language level conversion of COBOL applications must occur over the entire enterprise, as it would be counter-productive to try to maintain two different run-time environments and several levels of COBOL to accommodate both migrated and un-migrated systems. However, it is highly recommended that organizations complete a pilot migration project before taking on the enterprise wide migration. Migrating a small application first will allow the organization a chance to test tools and technologies, to determine what modifications (if any) to make to the migration protocol, to tighten estimates of effort and resources required to migrate, and to develop some migration expertise. Once the pilot has been completed, an enterprise wide assessment plan can be finalized and implemented.

Recommended guidelines, which must be used in conjunction with the Upgrade Unit scenario steps themselves, directly follow.

Pilot/Proof of Concept Approach

The initial pilot or proof of concept is typically performed on a system or a sub-system that is small enough to complete in a reasonable time frame and large enough to demonstrate value. A recommended reasonable time frame for a pilot is approximately 30 to 90 days, or less. Key attributes of a pilot system include:

· System or sub-system of roughly 100 to 500 source programs

· Standard language type (i.e. OS/VS COBOL or VS COBOL II)

· Standard file or data base usage

· Standard (command level CICS, for instance) teleprocessing monitor

· Limited number of interfaces to other application areas

Recommended pilot steps are as follows:

· Select one candidate system based on criteria listed above

· Verify that the selected system is one or more cohesive application units all implemented under a single CPU

· Refer to guidelines listed in the IBM COBOL/370 Upgrade scenario

· Begin at the second phase of activities entitled "Assess System(s) for COBOL Language Level Upgrade"

· Review these guidelines with Comsys-TIM experts

· Ensure that system resources are available to support both compiler releases and run-time environments during pilot project

· Verify that the proper tools are available to support analysis and implementation

· Follow scenario guidelines to build and implement an upgrade unit migration

· Verify results of the migration through thorough validation of the system

Subsequent pilot projects may be warranted if the organization requires more detailed planning or wants to increase expertise before beginning the enterprise wide migration. These follow-up pilots could include migrating different data base systems, different on-line systems, and non-standard platforms.

Proof of Concept Summary

Once an organization has completed the pilot stage, it is ready to perform a complete enterprise wide assessment. An overall strategy can then be completed to finalize time frames, resources, proof of concept phasing and related requirements to address the IBM COBOL/370 upgrade across the enterprise.

Enterprise Wide Assessment - Planning Considerations

In order to outline a phased approach for organizations wishing to address migration to IBM COBOL/370 at the enterprise level, IS must first perform an enterprise wide migration assessment. Enterprise wide assessments vary from the upgrade unit assessments mostly in terms of scale. They may also vary in terms of environmental and tool issues, compilers, languages and architectures analyzed, and coverage of non-standard technologies. An upgrade unit is a system, or group of related systems, being treated as a single unit of work for purposes of a given redevelopment project scenario.

At the enterprise level, migration activities should address integrated systems. In other words, it is best to migrate one whole application or group of interrelated applications at a time. Resource management will be a key element in the success of the migration process, and care should be taken to schedule migration activities at times that impact actual production the least.

The following conditions will likely be inherent in an enterprise wide assessment, and should be taken into account when planning even if such conditions were not present in the upgrade unit assessment.

· Multiple, interrelated systems and sub-systems that pass control between them

· Systems that do not share hardware platform, language type and operating system

· Potential occurrences of non-standard technologies (home grown TP monitors, macro level CICS, etc.)

· Widely varying quality and availability of system documentation and human knowledge base

· Systems under different management ownership

Migrating from VS COBOL II Baseline - Planning Considerations

From a conversion standpoint, the only language difference between VS COBOL II Release 4 and COBOL/370 is the addition of two new reserved words: FUNCTION and PROCEDURE-POINTER.

If upgrading from VS COBOL II Release 3, there are also three minor language differences due to COBOL 85 Standard Interpretation changes:

· REPLACE and comment lines

· Precedence of USE procedures

· Reference modification of a variable-length group receiver with no length specified

Besides the above differences, a VS COBOL II Release 3 or 4 program compiled with the NOCMPR2 compiler option will most likely compile under COBOL/370 with the NOCMPR2 option without change.

VS COBOL II Release 2 programs are usually coded to the COBOL 74 standard as well as VS COBOL II programs compiled with the CMPR2 compiler option. To compile these programs with NOCMPR2 under COBOL/370, source conversion is required. For more information, see the "IBM COBOL/370 and COBOL for MVS & VM Compiler and Run-Time Migration Guide".

Perform Enterprise Wide Analysis

Build Enterprise Wide Analysis Plan

Strategic Goal Analysis

Note: Briefly review redevelopment requirements and focus on establishing information asset inventory and documenting enterprise wide data flows.

Establish Redevelopment Related IS Goals

Note: In following step, establish assessment objectives as follows:
· Obtain basic inventory of systems environment
· Define current system boundaries
· Determine technological attributes of current systems environment
· Document existing data structures across enterprise
· Define interfaces between major applications being assessed
· Develop enterprise wide project segmentation strategy

Establish Enterprise Architecture Objectives

Note: Complete the following step in its entirety, including entry of information on Enterprise Summary Form 040B.

Establish Enterprise-Wide Analysis Scope

Information redevelopment plan development

· Following tasks/steps should be included in task/step list resulting from this step.
Technical Architecture Assessment
· Categorize systems inventory
· Summarize technological attributes
· Inventory enterprise mainframe systems
· Update technical summary legacy model
Information Redevelopment Planning
· Create enterprise segmentation strategy
· Build enterprise project recommendations

Create Enterprise Assessment Step List

Complete enterprise analysis planning

Verify Assessment Roles & Deliverables

Develop Enterprise Assessment Estimates

Finalize Enterprise Analysis Work Plan

Perform Enterprise Wide Assessment

Note: Technical architecture assessment establishes and categorizes enterprise wide inventory as baseline planning task for COBOL/370 migration.

Technical inventory analysis summary

Note: Analysts should take a pass at grouping systems into business area categories based on upgrade unit delineation. Categorizations will be refined under segmentation step of enterprise strategy.

Categorize Systems Inventory

Note: Wherever applicable, list version and release numbers in conjunction with technical attribute information such as Language and DBMS on Enterprise Summary Form 040B. If necessary, expand spreadsheet cells to accommodate this information.

Summarize Technological Attributes

Note: Physical inventory count is required. Quality rating (1 to 5) is optional. Automated analysis of component inventory is key to accurate and expeditious tally and subsequent estimates.

Inventory Enterprise Mainframe Systems

Note: Repository update is optional yet critical for large portfolios. Tracking data stores across upgrade unit boundaries and managing interfaces through phased implementation is greatly simplified with the use of a repository.

Update Technical Summary Legacy Model

Establish COBOL Migration Upgrade Units

Note: Creates enterprise staging plan that segments all systems and related components into manageable upgrade units. Upgrade units can be established at CPU or business area. Initial business area categories were established based on upgrade unit requirements.
Note: Careful implementation of this step will decrease the impact to normal production processing and will increase the efficiency of the migration project.

Create Enterprise Segmentation Strategy

Note: Utilize this step primarily to set priorities for determining the order of migration for the upgrade units.

Build Enterprise Project Recommendations

Perform Upgrade Unit Migration Analysis

Finalize Upgrade Unit Assessment Plan

Note: Following steps are derived from Inventory/Analysis stage of Comsys-TIM.

Upgrade unit migration plan development

Note: Use only the applicable step estimates of the following planning steps to create the combined estimate for COBOL migration.

Finalize Environmental Analysis Work Plan

Finalize General System Architecture Work Plan

Finalize Data Access Layer Assessment Plan

Finalize User Backlog Analysis Plan

Finalize IS Infrastructure Analysis Plan

Determine Upgrade Unit Design Requirements

Environmental analysis

Note: Environmental analysis produces most of the baseline information required to implement a migration project.

Identify/Categorize Physical System Components

Identify/Categorize External System Components

Inventory/Cross Reference Mainframe Components

Examine Run-Time/Execution Environment

Review/Refine Environmental Analysis Results

Note: If redevelopment objectives combine source code quality improvement with this migration to COBOL/370, insert process flow analysis at this point to provide the baseline assessment of code quality.

General system architecture assessment

Note: Determine any non-standard technologies employed which will have to be accommodated during the migration, such as CICS macro-level statements, undocumented COBOL extensions, embedded non-COBOL code, COBOL language elements no longer implemented, etc. Refer to the "IBM COBOL/370 and COBOL for MVS & VM Compiler and Run-Time Migration Guide" for more information on non-standard technologies and their conversion procedures.

Identify Use of Non-Standard Technologies

Data access layer assessment

Note: Use the following step to identify use of access methods such as ISAM and BDAM, which make the migration more complex.

Rate Data Architecture Conformance

User backlog requirements analysis

Note: This step offers an accurate assessment of frequency of enhancement for each system.

Categorize User Backlog Requests

IS Infrastructure Assessment

Note: This step offers an assessment of the level of staff expertise in the new language standard and migration tools.

Determine Staff Experience/Skill Ratings

Determine IS Maintenance/Redevelopment Tool Ratings

Finalize COBOL/370 Migration Plan

Create upgrade unit COBOL migration plan

Finalize Application Staging Plan

Finalize Language Change Work Effort

Establish Validation Criteria & Plan

Execute COBOL/370 Migration

Migrate Run-Time Environment

Application staging

Identify/Categorize Components of Interest

Create Working Version Libraries

Document Versions and Library Protocol

Synchronize Staged Source with Production

Teleprocessing monitor synchronization

Note: If macro level CICS still exists in current applications, an upgrade to command level CICS (Rel. 3.3) is necessary before installing the new LE run-time environment.

Migrate Teleprocessing Monitor

Run-time environment change

Note: Before migrating to the new LE run-time environment, run tests with captured data on current run-time environment to set a benchmark.

Identify Validation Data Sets

Note: Run parallel tests with same captured data on same source code, but with LE/370 in STEPLIB mode, and compare with original tests to determine if run-time migration will cause any problems. Such problems are more likely to include symptoms of non LE-enabled system tools and functions than test data discrepancies.

Validate Modified Programs

Note: Install LE/370 as default run-time environment. Continue to maintain the original run-time environment for the applications which will not be converted.

Migrate Run-Time Environment

Note: It is highly recommended that use of the STEPLIB mode be made an ongoing standard for all applications, converted and unconverted, within the organization. This will guarantee that each application will access the correct run-time environment, and will prevent system disruptions should default environments change. (Environmental changes are possible when execution of code switches from one CPU to another, when programs are recompiled, etc.).

Migrate Upgrade Unit to COBOL/370

Language change and upgrade preparation

Note: This step assumes that the new COBOL/370 compiler has been installed and is available.

Prepare Source Code for Conversion

Note: If redevelopment goals include structuring the most complex and un-maintainable code prior to converting it to COBOL/370, obtain outputs from the previously performed process flow analysis, and then perform the following steps:
· Produce detailed flaw analysis reports
· Perform program structuring adjustments
· Establish restructuring parameters
· Perform source code restructuring
Note that this will broaden the scope of this project considerably, and be prepared to increase the migration estimates correspondingly.

Language change and upgrade

Note: When executing the pilot migration project, all modules do not have to be recompiled and re-linked under the new standard. Testing a mix of programs, some recompiled and re-linked, some just re-linked, and some left in their original state, will verify that mixed systems can co-exist under the new standards. When performing the formal migration, recompile and re-link all programs.

Convert/Upgrade Each Source Module

Perform Environmental Migration

Re-Document Converted System

Schedule/Deliver Conversion Support Training

Validate COBOL/370 Upgrade Unit

Validation

Note: Create matrix of files/databases to source programs requiring them for validation.

Identify Validation Data Sets

Note: Enhance test data coverage of date upgrade units if under 70%.

Refine Validation Data Sets

Note: Compile and link original upgrade unit modules under original language level compiler and environment.

Compile/Link Baseline Components

Note: Compile and link modified upgrade unit modules under new language level compiler and environment.

Note: To avoid synchronization problems between compile and link options having to do with 24-bit versus 31-bit addressing, specify data PARM compiler option for each program, but allow link editor to automatically set AMODE/RMODE options.

Compile/Link Positioned Components

Note: This involves a functional equivalency test to determine that no change was introduced to production for that upgrade unit.

Validate Modified Programs

Obtain Validation Sign-Off