Most important precautions when upgrading COBOL and CICS

Most important precautions when upgrading COBOL and CICS

Are you missing the most important precautions when upgrading COBOL and CICS? Search390.com experts Jim Schesvold and Tom Ross will outline the necessary steps to ensure your upgrade goes smoothly.

A Search390.com member asked this question:
Our shop is planning to migrate old COBOL and CICS (VS COBOL, MVS COBOL) to COBOL 390. Can you please tell me what precautions I should take, what reserve words I should be aware of and whether I should test each batch and online programs after conversion?

Jim Schesvold's answer:
The biggest precaution you can take, in my opinion, is to carefully research both your applications and COBOL migration considerations and tasks. Do this in conjunction with your application programmers, and communicate your findings with them when this phase of the project is complete. Then write down a thorough migration plan, including specific dates that are negotiated with the people performing the migration, and track this plan on a weekly basis. This includes weekly status meetings with the key players.

Without knowing your application program inventory, it is difficult to tell you what reserved words to be concerned with. If you don't use a specific reserved word, you obviously don't need to concern

    Requires Free Membership to View

    Login

    When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by IT professionals today working with data center technologies.

    Margie Semilof, Editorial Director

    By submitting your registration information to SearchDataCenter.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchDataCenter.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

yourself with that one. The COBOL migration documentation is useful in this area. I've listed a number of key references below.

Yes, I would test every program if that is at all feasible. Solving a problem in test is less time-intensive, is more easily debugged and involves a whole lot less stress than when the problem occurs in production. And while you may view a group of programs as essentially identical from a testing perspective, sometimes the slightest difference can make a huge difference.

Here's a list of COBOL migration references which will be helpful to you:

One last thing to keep in mind: There are products from IBM and other vendors that aid in your conversion. I won't recommend any particular product, because that is in no small part dependent on the nature of your applications and how they are structured. But it is worth looking at this option, because these products can in many cases reduce the effort of performing a COBOL conversion.

Tom Ross' answer:
The first step you take should be to do a run-time only migration from the older run-times to LE (Language Environment), if you have not already done so. Make sure that neither the OS/VS COBOL library nor the VS COBOL II runtime library are in your LNKLST/LPALST. After you have done this, you are fully supported by IBM service, even with your old modules. The COBOL Migration Guide will tell you how to get to LE. In most cases you don't even need to relink!

If you want to start using new compilers (after you have everything running under the new runtime library) then you will start doing recompiles. You mention moving to "COBOL 390," and I don't know what that is, but IBM had a compiler called "COBOL for OS/390 & VM" that went out of service at the end of 2004, so you should not be moving to that one. You should move to Enterprise COBOL version 3, with our last release being 3.4 in September 2005. There is a huge difference between recompiling OS/VS COBOL programs with a newer compiler versus recompiling VS COBOL II or later programs: VS COBOL II and later compilers are all compatible; OS/VS COBOL is not. So, if you really have some programs that were compiled with COBOL for MVS and VM (that is how I interpreted your reference to "MVS COBOL"), then you don't need to test those programs when you compile with Enterprise COBOL; they are guaranteed compatible. Moving from OS/VS COBOL requires some pretty good testing, on the other hand.

Reserved words are not generally a problem for the thousands of customers I have worked with, but the source conversion tools can handle them for you anyway. IBM sells a tool, CCCA, that can automatically convert OS/VS COBOL programs to Enterprise COBOL, including reserved words. As I said, VS COBOL II (with NOCMPR2) and later programs do not need to be converted when moving to Enterprise COBOL -- just recompile when ready!



This was first published in November 2005

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top