Steve Thompson writes: >A migration was proposed to translate (using an IBM utility) an >ISV’s code to COBOL (~NOV2013). The problem is, the group that >has the translation tool had NO idea about COBOL 5.1, and >apparently had no plans to make their tool COBOL 5.1 friendly (as >in, NOT using new reserved words and the like).
Which IBM utility? If that were true, that doesn't necessarily sound like the end of the world in November, 2013. (Enterprise COBOL 5.1 became generally available in late June, 2013.) It was (and is) as simple as making sure APAR PM85873 is applied to Enterprise COBOL 4.2 then compiling with FLAGMIG4. In the unlikely event there were a problem such as the one you describe (reserved words), that'd catch the problem.... ....Then take that translated-to-COBOL code and recompile it with Enterprise COBOL 5.1 right away (or in December, 2013), if you wish(ed). It's COBOL. "Apparently" the IBM utility only claimed (in November, 2013) that it could translate something into Enterprise COBOL 4.2-compilable code, but so what? Onward and upward, as with every other piece of COBOL code. That's assuming the translation is "one time" in nature. (See below if not.) >Why would a customer want to xlate to COBOL 4.2, and then have to >migrate all of that to COBOL 5 in less than 2 years? That'd be awful, wouldn't it? Fortunately it's not true. z/OS 2.1 still runs and supports COBOL code compiled decades ago. If the past predicts the future -- in this case I'd say that's a safe bet -- you can run that 4.2-compiled code decades from now on the then-current release of z/OS. There is no requirement to "migrate all of that" or even any of that. (Aside: Why is this particular hyperbole so popular? Just stop, please.) When/if you want or need to recompile one particular, specific program (or subset of programs), sure, use the current compiler. If you want to recompile every single line of COBOL source code in your enterprise whenever IBM introduces a new release of its COBOL compiler, Gentoo-style, you can if you wish. You certainly don't have to. I'm not sure where you're getting the "in less than 2 years." While I'm an enthusiastic supporter of adopting the latest IBM compiler releases as expeditiously as possible, IBM has not yet announced an End of Service date for Enterprise COBOL 4.2. Since...well, since "forever," IBM has introduced core and base technologies first, then supported and exploited those base/core technologies progressively over time. That's true of COBOL, and that's true of every other programming language. Java as well, to pick another example. IBM first introduces a new release of Java, then WebSphere Application Server follows to exploit that new Java release, then middleware products are progressively updated to exploit that new WebSphere Application Server release. IBM support policies provide lots of lifecycle overlap to help customers maintain reasonable release currency. IBM tries to do a reasonable job updating tools and utilities in priority order. For example, if a compiler gets updated then Debug Tool tends to get updated quickly if necessary. Other products (like a certain unnamed IBM migration utility) might take more than 5 months to update (if it even needs updating). Of course, if you're not happy about IBM's schedule, complain! (To the right people.) -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
