VSE/MVS Conversion Methodology

Introduction

z/VSE-to-z/OS migration projects are the latest iteration in a long line of related conversions, starting with the DOS-to-OS implementations in the 1960's, then continuing with all possible combinations of DOS, DOS/VS, DOS/VSE, VSE/SP, VSE/ESA, z/VSE to OS/VS1, OS/VS2, MVS/SE, MVS/SP, MVS/370, MVS/XA, MVS/ESA, OS/390 and z/OS. Although the tools and methods in use today are more sophisticated than those which existed thirty years ago, going from VSE/ESA or z/VSE to z/OS in the 21st century isn't always simpler than going from DOS/360 to OS/360 was in the 1970's. In the interval, DOS/VSE data centers have become more sophisticated, and converting them to z/OS more of a challenge as a result.

This document describes three different methods used to convert VSE applications to MVS and highlights the major differences between them.

Overview

A VSE/MVS conversion is the process of taking VSE applications, modifying and testing them to run in the MVS, OS/390 or z/OS environment. The term Migration, which is often used as synonym for Conversion, refers to the broader project of turning a VSE data center into an equivalent MVS, OS/390 or z/OS data center. The migration includes the conversion of the applications, as well as several other tasks such as planning, installing hardware and software, training, etc.

VSE/MVS conversions are easier to automate than most other operating system conversions, due to a large extent to the vast similarities which exist between the source (VSE) and target (MVS) environments. The fact that the same (or very similar) concepts, hardware, programming languages, compilers, and middleware exist in both environments makes it considerably easier to write almost-perfect conversion tools. As a result, a highly-automated method, such as the mass conversion described below, allows a VSE data center to migrate to MVS in a manner that is both predictable and largely transparent to end-users, a goal impossible to attain should the same VSE installation migrate to an unlike environment (e.g AS/400 or Unix) instead of MVS.

Methods

Three different methods are used to organise the conversion of VSE applications to MVS.

1. The Kernel Method
2. The Shelf Method
3. The Mass-Conversion Method

Note: The term Big Bang refers to the cut-over (or switch-over) of the converted applications en masse, at the end of the project, as occurs in the shelf and mass conversion methods. As a result, the terms Big-Bang method and Big-Bang conversion are sometimes used, inappropriately, to designate the shelf and mass conversion methods.

1. Kernel Method

In the Kernel (or progressive) method, the application inventory is split into several small sets of related applications ("kernels"). Kernels are converted, tested and cut over one by one until all of the applications have been implemented in the target environment. As a result, during most of the conversion project, converted applications run in the new environment while other applications, waiting to be converted, still run in the old one.

This situation, which can last for a year or more, requires the creation of temporary bridges to transfer data files back and forth between the applications already converted and running on the new system, and the rest of the applications, still running on the old system. In addition to the bridges, the operations staff must also manage two production environments (the old one and the new one) simultaneously, thereby creating a significant overhead and increasing the risk of production errors.

The Kernel method is issued from the 1960's, when most application data was on tape and exchanging data between applications running in the old (i.e. DOS) and new (i.e. OS) environments was relatively easy. Gradually, as the availability of disk storage increased, tapes lost their importance in favor of DASD and Data Bases; as a result of this evolution, conversion teams found it more difficult to build bridges between the old and the new environments. In the late 1970's, DOS/VS production environments were often built around a CICS system and on-line files and data bases shared between multiple applications, which made it all but impossible to split the applications into kernels that can be converted on their own.

2. Shelf Method

When management of a Kernel conversion project realises that the applications are too tightly integrated to be separated into independent kernels, the project is generally switched from "Kernel" to "Shelf" mode. In the Shelf method, sometimes referred to as the Snapshot method, applications are converted and tested, then "shelved" until all the other applications are also converted and can be cut over, at the end of the project, all at the same time. In essence, the Shelf method is the Kernel method with a single cut-over at the end.

Although the Shelf method simplifies operations because there is only one production environment to manage at any given time, this method invariably results in having two versions of every application, one in production in the old environment, and a second one sitting on a "shelf" in the new environment. This situation, which can last for months or even years, puts a heavy burden on the applications staff who must track maintenance to the VSE version of the application and apply it again to the MVS version, each time a change is made to already-converted programs or job streams.

Because converted applications are all cut over at the same time, en masse, at the end of the project, the Shelf method is sometimes referred to as "mass conversion". We believe this to be inappropriate, as the Shelf method lacks the iterative element of the true Mass Conversion method, which eliminates the need to freeze applications, as described below.

3. Mass Conversion Method

The Mass Conversion method was created in 1982 in France in conjunction with the Cortex conversion software, as a way to significantly reduce the overhead inherent to the other methods. IBM sponsored the mass conversion method in 1984 when they licensed the Cortex product, which they later distributed to their VSE customers under the name MVS Migration System (MVS-MS). The Mass Conversion method is a structured method, described in great detail in the IBM Documentation, and based on three main elements:

• Automated: use of specially-designed tools to convert programs, translate JCL and transfer data is required (with the other methods, tools are optional).
• In Mass: processing the source code, JCL and data occurs "in mass" (with the other methods, elements are generally processed one by one). The entire application inventory is cut over at the same time, typically over a week-end.
• Iterative: every month or so throughout the conversion project, the translated JCL, programs and data are discarded, a new supply is brought over from VSE and converted, translated and compiled, a process referred to as a "dummy conversion". After each "dummy conversion", testing is resumed with a fresh set of JCL, programs and data. As a result of this iterative process, JCL and programs do not need to be frozen (with other methods, elements are generally translated once, tested, then frozen until project end).

After a number of dummy conversions have occured and testing results have been consistently positive, VSE production is shut down, a last mass conversion and transfer of application data are carried out and operations are resumed in the target environment. This event, called the "switch-over", generally occurs during a week-end.

The mass-conversion method is complex, technically demanding and requires specialised software, skilled personnel and a lot of discipline. Its iterative aspect is quite unusual and often misunderstood: when a sophisticated product like Prism-CS™ is used, inexperienced conversion team members may be discouraged by the amount and complexity of customization required and start freezing programs and JCL, gradually abandoning the mass conversion method for the more traditional shelf method, without realising the enormous overhead this will generate in the long term.

The mass-conversion method causes minimal disruption to operators, applications staff and end-users. Programmers can continue to update existing programs, or write new ones without impacting, or being affected by, the conversion project.

Because the programs and JCL are converted automatically, results are more homogeneous, and standards easier to implement.

Conversion Exceptions

When software tools are used to automate the conversion, it is frequent that these tools fail to produce perfect source code or JCL.. This creates situations known as conversion exceptions which all require corrective action from the conversion team. On an average-size project, the occurrence of thousands of conversion exceptions is common. How conversion exceptions are corrected depends on the conversion method:

• In a Kernel or Shelf conversion project, conversion exceptions are corrected manually, and the corresponding element (program, JCL) is immediately frozen.
• In a mass-conversion project, conversion exceptions are handled quite differently: when an exception is discovered, the conversion staff proceeds as follows:
  • first, conduct a global search to determine how widespread the exception is
  • then, select a mode of resolution based on the frequency of the exception:
    • Conversion exceptions with a large number of occurrences are solved by customising the conversion process.
    • Exceptions with a small number of occurrences are solved by "positioning" the programs or JCL in VSE, i.e. making small changes to the VSE element (program, JCL) to make it compatible with the automated conversion process.
    • Only as a last resort should the MVS version of the elements be manually modified and frozen, as is customary with the other methods.
• In conversion projects which do not use automated translation tools, the notion of "conversion exception" does not exist, as everything is converted (and corrected) manually and immediately frozen.

How Long Does It Take?

Most VSE/MVS conversions take from three months to three years, depending on three groups of factors:

1. Technical Difficulties

   The size of the application inventory is the most obvious factor that affects the technical difficulty of a conversion project, but there are many others, such as programming languages, particularities of the VSE JCL streams, utility programs, links with outside environments (e.g. RJE, EDI, Reports, tapes). Other factors have a very important effect on the difficulty of a project, among them the tools used to convert the applications, and the individual skills of the members of the conversion team. Using a state-of-the art conversion tool such as Prism-CS and services from highly-skilled consultants can considerably reduce the impact of technical difficulties.

2. Quality of the result

   For a variety of reasons, some companies can tolerate a significant number of errors when they switch the VSE production over to MVS, but others can't. For example, a financial institution in a heavily-regulated environment is under a lot of pressure to avoid any error that may affect its customers or the confidentiality of their data. These financial institutions must therefore spend a significant amount of time planning for contingencies and performing additional testing which will significantly lengthen the duration of the project.

3. Commitment of the Company

   This is the most important factor: the management of a company converting from VSE to MVS must show their commitment by assigning the right resources at the right time throughout the project. The resources consist of people (e.g. conversion team, IT staff, end-users, coordinators, auditors), hardware (e.g. CPU, DASD, Tape drives, network connections), software (e.g. Operating system, vendor products, conversion tool), office space, etc.

What does this mean in real life? Well, it's difficult to say, but over the past 25 years we have noticed that most average-size projects done in-house (i.e. without the help of sophisticated tools or skilled consultants) lasted two years or more. In contrast, most average-size projects we performed with sophisticated tools such as Prism-CS lasted ten months or less.

Emulators

Emulators allow VSE objects programs (PHASEs) to run in the MVS environment, directly, without having to convert source programs and compile them. An emulator may be a useful option when a significant amount of source code is not available, but we believe emulators to be a counter-productive solution in all other cases.

Emulators have their roots in the 1960's and 1970's, when available language conversion programs (LCPs) were not apt at properly converting certain programming elements in wide usage at the time, such as COBOL D or assembler programs which used ISAM, EXCP or overlays. In that context, using a product such as UCC2/DUO (which still exists today as CA-DUO) made sense, even if it made JCL conversion more of a challenge, and required maintaining programs in DOS format for months or years in an OS world. The situation changed dramatically in the 1980's, when COBOL D and ISAM largely disappeared, Data Base Management Systems (DBMS) and CICS became commonly used, and enhanced LCPs became available which were able to better convert programs written in commonly-used languages.

Using an emulation solution today neither reduces the amount of effort for, nor the cost of, converting applications from VSE to MVS, but in fact increases these two factors. In particular:

1. People often believe that a conversion from VSE to MVS consists mostly in converting programs. Yet, experience shows that converting application source programs, even those written in assembler, only represents a small portion of a typical conversion effort, generally 5% to 10%, perhaps even less if the VSE COBOL programs have already been upgraded to COBOL II or COBOL for VSE. As a result, not converting source programs is unlikely to translate into significant savings in time and effort.
2. The process of converting programs allows the gathering of file and CALL information which provides information indispensable to a successful translation of the JCL. As a result, not converting programs makes JCL translation more difficult, sometimes much more difficult. The increased difficulty, in itself, may significantly outweigh any possible (or perceived) effort savings which may result from not having to convert the source programs.
3. Emulators only provide a solution for batch application programs. In a typical VSE installation, 1/3 of the programs are on-line (CICS), and 1/3 of the JCL steps execute utility programs such as SORT, IDCAMS, BACKUP, FTP. Furthermore, emulators do not support Data Base Management Systems (DBMS). It is interesting to note that the only DBMS mentioned in the CA-DUO marketing literature available on the Web (a document which seems to have been written in the late 1970's) is DBOMP, a long forgotten precursor to DL/I.
4. An emulator introduces an additional level of complexity between the application program and the operating system. In case of abend or erroneous results, the added complexity makes the process of problem determination more of a challenge: is the problem caused by the application? by the emulator? Something else? If it is an emulator problem, what do I do to fix it?
5. The emulator software is costly and will have to be retained for a long period: some DUO users have had to keep using it for five or more years. In comparison, a powerful conversion product such as Prism-CS™ is less costly and has no long-term licensing requirements.
6. Application programs will have to be converted to MVS, one way or another. Not converting (and testing) programs as part of the VSE/MVS conversion project only delays the inevitable. Actually, when an emulator solution is chosen, programs will have to be tested twice, once as part of the VSE/MVS conversion itself, then again, later, when times comes to convert them. Furthermore, the approach of converting programs and putting them into production one by one creates a number of issues of its own, such as those inherent to having several levels of COBOL in production at the same time. These two issues, i.e. dual-testing and dual-COBOL, undoubtedly make the conversion more complex and costly. Such issues do not exist when programs are converted during the course of a VSE/MVS conversion, particularly when they are converted "in mass", resulting in significantly lower costs.

In conclusion, an installation considering using an emulator as a cost- and effort-saving solution to their VSE/MVS conversion should not rely too much on the vendor's literature and consider all the arguments listed above before making their decision.

IBM Documentation

VSE to OS/390 Migration Workbook SG24-2043
MVS-MS General Information GB11-8074
MVS-MS Planning Guide SB11-8077
MVS-MS Planning Chart SB11-8090
 

Return to the Prism-CS™ main page.