Planning Your Migration to COBOL V6
Overview: Dave Kartzman, Compuware Solution Consultant and COBOL Migration Expert, talks about the role of planning in migration to COBOL V6 and how companies can make the move easily and efficiently. Read this Q&A, then check out Dave’s recent webcast, “Moving to COBOL V6? Here’s What You Need to Know.”
Solution Consultant Dave Kartzman has experience with COBOL dating to 1973. As a member of Compuware Field Technical Support, he acted as an interface with beta testers of COBOL versions 5.1.0 and 5.1.1, ensuring that Compuware products supported the latest versions of COBOL on day one of their general release. Over years of working with clients as they migrated to COBOL V5 and now V6, Dave has accrued a wealth of knowledge which he has compiled into a presentation that has grown with his experience. Over the past 4 years, he has presented this information over 100 times to companies around the world to aid in their migration efforts.
Dave recently hosted a webcast entitled, “Moving to COBOL V6? Here’s What You Need to Know,” where he gave a brief overview of his migration presentation. We talked with Dave about COBOL V6 and how these presentations can help organizations effectively plan their migrations.
Q: When you give your presentation, where in the migration process are most of the companies? What kind of help are they looking for?
DK: Most of them are in the planning process. It isn’t that they need help, it’s that they need some guidance. The migration guide is almost 400 pages and it looks pretty intimidating, so there’s a lot of reticence and fear as to what they have to do. “How do I get started?” And once they get started, it’s normally not bad at all. And in fact, most clients will not recompile everything because it’s a nightmare to test your intermediate results and final results. It just does not work well that way.
Q: How does your presentation help companies with their migration?
DK: The whole intent of this is to get you migrated with the least amount of pain possible. And that’s been my goal all along—and how this whole thing came about—is to work with and pick up information that our clients have told us and try to come in with a presentation that is as complete as humanly possible within an hour and a half to two hours; what needs to be done and what you need to focus on when you’re doing your migration.
Keep it simple. Don’t overthink it. Use your standard development methodology and run with it and plan properly—that’s the key. If you don’t plan properly, it will be a nightmare. If they’ve planned properly virtually every client that I’ve worked with that’s migrated, it’s been a relatively smooth process. That’s not to say that there aren’t issues; there are things that come up as part of their programming that they didn’t realize. They thought that running the new version of COBOL, they shouldn’t have any issues. Well, occasionally you run into issues and it’s just constraints. Things that are different between version 4 and version 6.
Q: Is there a lot of downtime associated with migration?
DK: No, not at all. It depends upon the approach you take. The approach that we espouse is to take a single business unit application and all the programs that are in there and run the analysis as to what programs would be best suited to migrate to the new versions of COBOL. Test, convert them, recompile them, test them thoroughly, and use tools to monitor the performance impact. So, you at least benchmark some of the savings that you should expect to receive.
And then once you move that business unit into production, once you finish your pilot and you keep notes, you have a post-mortem so that the next business unit will take what you went through and build on that so that with each successive group of units it becomes easier and easier because you’ve basically kept from reinventing the wheel.
Once a business unit is moved over to the new version, then their compiled procedures no longer use the old version of COBOL. They only use the new version for any maintenance or new development. Bearing that in mind, you have concurrent development going on at the same time that you’re doing migrations. So, there is no downtime.
Q: You mentioned using tools when testing. What are the best tools to use?
DK: In order to analyze the load libraries or program object libraries, we have a utility within File-AID that’s called the load module analysis. It’s option 3.1 in the File-AID MVS screen—it’s part of the basic product and the user has the ability to go in and specify the name of a library or a program object library and generate a CSV file that they can upload to Excel and, using the filters, basically show every member in that library, all of the CSECTS of those individual program load modules and, in the case of COBOL modules, the compile options as well as a release of COBOL that they were compiled under. This is really important because if you have OS/VS COBOL and VS COBOL II programs, you really have to check those to make sure that they will work in the new environment.
The other one is using Strobe. If you want to monitor their performance, like if you have the same test bed under 4.2 and you run it under 4.2 and another one under 6.3, you can run Strobe measurements on both of those and you have the ability to go in and compare the savings. So, it gives you the opportunity to look at the difference in what the potential savings are and maybe benchmark what you’re hoping to achieve out of it. We have no products to sell in these presentations. Everything that we do to assist the clients is already embedded within our tools. We provide day one support for all the versions of COBOL.
Q: COBOL V4’s end-of-service date is September 30, 2021. Are you seeing an increased urgency to upgrade to V6? (Editor’s note: Since publication of this article, IBM has pushed the end of service date for COBOL V4.2.0 to April 30, 2022)
DK: I’ve done 108 of these presentations now in the last four and a half years and there is more emergency in the last year because people are realizing that that September 2021 date is coming up. And again, they can still run 4.2 but if they run into any issues, they know they need to go to V6 because their costs keep going up. If they’re doing Rolling 4-Hour Average and their business continues to go well, it’s going to keep bumping up how much more money they have to spend. So, by going to V6, they’re going to be able to save money by converting, over time, more and more of their applications and reducing their Rolling 4-Hour Average or getting a better price under Tailor Fit Pricing. So, there is a rush to go to it.
I’ve done presentations worldwide and it’s been great. The customers appreciated it. It costs them two hours of their time, but they get the PowerPoint presentation and a lot of information that they can take back and start using as part of their migration process. So, they’re not starting from scratch. What I’m doing is providing just a stepping-stone for them to start, to make them aware of things they need to pay attention to. The IBM migration guide is just a fabulous manual that is 400 pages and I’m just touching on the things that they really need to pay attention to and give them a start.
Q: How can a company get more information, or request a presentation?
DK: If anyone has any questions, they can reach out to Compuware or to their account reps. I’ve done presentations for non-clients because they’d caught wind that I do those and I’m happy to do it.
Latest posts by Matthew DeLaere (see all)
- Modern Enterprise Software Delivery System Architecture - May 18, 2020
- Key Characteristics of a Modern Software Delivery System - May 11, 2020
- Planning Your Migration to COBOL V6 - April 23, 2020