Page 1 of 2

COBOL Enterprise

PostPosted: Mon Aug 29, 2011 10:09 pm
by freelar
Is there any big issues recompiling these older level of COBOL to Enterprise 3.2.1 ? The 400 page document on the upgrade is a little time consuming. :)

Thank you Rickey


OS/VS COBOL R1.0 0 217 0 0 0 217
COBOL II V1.3.0 0 4 0 0 0 4
COBOL II V1.3.2 0 78 0 0 0 78
COBOL II V1.4.0 0 24 0 0 0 24
COBOL/370 V1.2.0 0 1937 0 0 0 1937
COBOL/370 V1.2.2 0 48 0 0 0 48
COBOL/MVS V2.1.1 0 442 0 0 0 442
COBOL/MVS V2.2.0 0 74 0 0 0 74
COBOL/MVS V2.2.1 0 266 0 0 0 266

Re: COBOL Enterprise

PostPosted: Mon Aug 29, 2011 10:42 pm
by Robert Sample
Is there any big issues recompiling these older level of COBOL to Enterprise 3.2.1 ? The 400 page document on the upgrade is a little time consuming.
You mean, other than changes in the way the compiler functions, new verbs, removed verbs, and changes in the compiler options? If YOU are not willing to put in the time to understand a 400-page conversion document, just why do you expect US to spend the time in your place? Are you so arrogant or so lazy as to think YOUR time is worth more than OUR time?

I suspect you won't get a whole lot of usable answers on this forum with such an attitude, so you might want to start spending the time to read the 400-page document.

Re: COBOL Enterprise

PostPosted: Mon Aug 29, 2011 11:35 pm
by dick scherrer
Hello,

Is there any big issues recompiling these older level of COBOL to Enterprise 3.2.1 ? The 400 page document on the upgrade . . .
It appears as though you have answered your own question. . . If there "was nothing to it" it would not take 400 pages.

It would be rather irresponsible to begin the compiler upgrade without reading the document. In additon to reading the document, you would also be advised to do a proof-of-concept for each of the comiplers you intend to replace with Enterprise COBOL.

I should also mention that Enterprise 3.2.1 is not current. If you are going to leap forward, why not get current?

Re: COBOL Enterprise

PostPosted: Tue Aug 30, 2011 3:13 am
by freelar
Okay I just wanted to know in general since I had basically no time to do this estimate, i've done upgrades before, I know all about compiles, options, verbs, hey I can write code in binary imagine that... So I wasn't expecting a detailed answer just in general is the something magical about Enterprise, which I doubt, thanks Dick <know-nothing thoughtless rubbish removed>

Re: COBOL Enterprise

PostPosted: Tue Aug 30, 2011 5:08 am
by BillyBoyo
You could get a whole slew of problems - it depends, however, on what all that old code is like. If none of the stuff that is affected is used in the programs, then it'll be as smooth as pie. At the other extreme, you wouldn't get one to compile clean.

Get your compile options straight. That is going to be enough of a task.

With the code, you're going to have to find out what changed/removed features your systems use. To do that, you have to find out what they are and then ask the people who know your systems (or do a bunch of source scans yourself).

If you feel your time is so important, do the job properly, otherwise it will take 12 times as much of your valuable time.

Re: COBOL Enterprise

PostPosted: Tue Aug 30, 2011 10:25 am
by dick scherrer
Hello,

and yes my time is worth a lot more than yours
To who? Opinions vary. . .

If you do not appreciate what someone posts, fine, but your reply needs to address the post not the person. . .

d

Re: COBOL Enterprise

PostPosted: Wed Aug 31, 2011 12:55 am
by Ed Goodman
The biggest issue you will have is getting people to agree to TEST it when you're done. A lot of the program will recompile fine, but may not work the same as before.

I recommend you start with an estimate of how long it will take to test each program. (I call it a regression test, but that's probably incorrect) The test(s) of each program should take a given set of inputs and run the program, then save the outputs. Then upgrade the compile, then rerun the test and compare the output. THAT'S a big effort, and probably the only way to do it where everyone will agree that it's done right.

The big gothchas will be on the programs that still compile. The ones that don't compile, everyone will be like "We need to take a close look at THAT one." They'll want to test them because there will be code changes. The ones that compile, everyone will be like "COBOL is COBOL, no need to test it."

Re: COBOL Enterprise

PostPosted: Sat Feb 11, 2012 9:22 pm
by freelar
So after the hasty estimate with myself and another person both looking at it we came to the conclusion there were no "keyword" changes for these financial applications.
We gave an estimate of 3800 hours for around 7000 COBOL programs and our vendore gave 32,000 hours, we have just about completed the project and it will be around 3800 hours or most likely less.
For testing since all we could find was recompiling with no code changes I talked the director into minimal testing on each application, so far no issues.
The only keyword change to this point is a program not compiled when the COBOL/LE upgrade happened. Thanks

Re: COBOL Enterprise

PostPosted: Sat Feb 11, 2012 10:35 pm
by BillyBoyo
Thanks for the update. You must have the best-written programs in the world. All numeric data conforming to picture.

You doing parallel runs with file comparisons?

Re: COBOL Enterprise

PostPosted: Sun Feb 12, 2012 12:33 am
by enrico-sorichetti
You must have the best-written programs in the world. All numeric data conforming to picture.

they might have the best written program
...kiss my a$$ robert,

but certainly the TS has the worst manners and attitude ( for somebody asking for help ):evil: