Cobol - OldBOL to NewBOL

Author

OldBOL to NewBOL

Arnold Trembley

2006-02-12, 6:55 pm

Carl Gehr wrote:
> I would be happy to get into war stories about migrating from old
to > new COBOL compilers. [My first reference would be Bill Klein's
> book: "OldBOL to NewBOL".] Migrating OldBOL to NewBOL is the vast
> majority of our business, but it should probably be in another
> thread as we have gotten far off the 'subject' of this one. I'll
> wait for someone to ask...

Okay, I'm asking. I have a few war stories about this too.

--
http://arnold.trembley.home.att.net/

William M. Klein

2006-02-12, 6:55 pm

One interesting thing, is that I am *still* finding new and "interesting"
migration problems. In the IBM-MAIN list, just within the last few w

s,
someone mentioned that they had programs making calls to ILBOSPI0. Now, I have
previously seen (lots) of calls to ILBOABN0 and ILBOWAT0, but this one was a new
one to me. It turns out that it was an interface to the COUNT, FLOW, and other
"spie-related" features of OS/VS COBOL.

Certainly, some of the biggest problems with migrations from OS/VS COBOL to the
initial FEW releases of VS COBOL II were:

A) performance - particularly in the case of "highly modular" applications with
LOTS of CALLs. The VS COBOL II run-time *tried* to be prepared to handle EITHER
OS/VS COBOL or VS COBOL II object code - and this introduces some serious
performance hits. (There were also some problems with IBM programs and a
"weirdly" documented user-mod that could be made to ILBOCOM.)

B) "Undocumented extensions" (aka undiagnosed user errors). The OS/VS COBOL
compiler had grown from previous IBM compilers and allowed lots AND LOTS of
syntax that the documentation never supported, e.g
> THEN (not even THAN)
SORT ... INPUT PROCEDURE XYZ UNTIL A > B

C) Mixed RES NORES applications (Similarly CALLs under CICS). Always
documented as "no-no's" - but they USED to work

D) NUMPROC "stuff". Users expected applications to ABEND when they used to and
NOT to abend when they hadn't before. All of this related to "invalid
sign-nibbles" (not to mention spaces in numeric fields).

E) *TOTAL* lack of coordination between IBM and the 3rd party vendors. In many
ways, this was one of the things that those of us at GUIDE pushed IBM the
hardest on - and something that they have continued to have problems with.

Interestingly enough, the introduction (many years later) of the LE run-time
turned out to be its own MAJOR migration problem. When it came to Y2K an those
shops that TRIED to do simultaneous compiler and run-time migrations, they
really had a hard time of it.

***

P.S. Carl, If you really think back. Mark Duckworth was able to move VS COBOL
II R1 into production for "batch" and I got R1.1 into Linklist. However, we
certainly WERE in the "minority" on this. I found that lack of Exponentiation
was a "bigger" problem than lack of floating-point.

--
Bill Klein
wmklein <at> ix.netcom.com
"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:taLHf.382861$qk4.270284@bgtnsc05-news.ops.worldnet.att.net...
> Carl Gehr wrote:
> to > new COBOL compilers. [My first reference would be Bill Klein's
>
> Okay, I'm asking. I have a few war stories about this too.
>
> --
> http://arnold.trembley.home.att.net/
>

2006-02-12, 9:55 pm

William M. Klein wrote:
> One interesting thing, is that I am *still* finding new and "interesting"
> migration problems. In the IBM-MAIN list, just within the last few w

s,
> someone mentioned that they had programs making calls to ILBOSPI0. Now, I have
> previously seen (lots) of calls to ILBOABN0 and ILBOWAT0, but this one was a new
> one to me. It turns out that it was an interface to the COUNT, FLOW, and other
> "spie-related" features of OS/VS COBOL.

Oh, absolutely! It is amazing the ways programmers found to precipitate
the unintended consequences! ILBOSPI0 is also a new one for me. I'll
have to put that one on the 'Watch List' along with Assembler routines
that do [E]STAE, [E]SPIE, LINKs and LOADs.

><Snip>
>
> P.S. Carl, If you really think back. Mark Duckworth was able to move VS COBOL
> II R1 into production for "batch" and I got R1.1 into Linklist. However, we
> certainly WERE in the "minority" on this. I found that lack of Exponentiation
> was a "bigger" problem than lack of floating-point.

Yes, Mark's primary issue was mixing RES/NORES. Fortunately, that is
now very easy to find and fix. He actually was the impetus for the
MIXRES run-time. But, I believe that, after he got MIXRES, he found the
band-aid to be more of a problem than just fixing the problem. That is
still my recommendation today: Recompile the NORES program(s)!

Don't forget that the reason you did not have exponentiation is because
the compiler did it with floating point. Sure, simple cases could have
been done without float. But, for consistency [as I recall] all were
done with float. It would have been more difficult to recognize and
define all the exceptions than to just do it all with float.

William M. Klein

2006-02-13, 3:55 am

Another interesting aside to this discussion (and this MAY sound familiar to
some of our Workstation "friends" who worry about "run-time fees").

One of the reasons that several of the phone companies were able to "justify"
the move to VS COBOL II was that CA-Optimizer V5 (as I recall) suddenly started
"charging" run-time fees. (Earlier CAPEX and CA-Optimizer releases only used
run-time libraries for certain "non-production" options like DTECT.) Many
shops remained on R4.2 (I think it was) but were worried about "support" for
OPTIMIZED COBOL code. Now almost EVERY IBM shop that I knew used
CAPEX/CA-Optimizer for OS/VS COBOL code (which was well known for INCREDIBLY bad
code generation).

However, IBM created a "great new" OPTIMIZE option with VS COBOL II (Thanks Nick
Tindal). Therefore, many shops (and this was particularly common among the
"phone company" shops) were able to "prove" that (especially for long running
batch programs) the VS COBOL II (free) OPTIMIZE option worked BETTER than the
older OS/VS COBOL with CA-Optimizer. Even when the performance was just
"comparable" the fact that we could be supported withOUT a run-time license for
CA-Optimizer on every CPU was part of the initial justification for moving to VS
COBOL II.

On the other hand, I think it was State Farm that had moved to many, MANY levels
deep of "dynamic calls" to implement "modular programming" in the 70's and early
80's. They found that their move to the VS COBOL II run-time (much less
compiler) was a NIGHTMARE for performance. I may have the release wrong, but I
think it may have been R3.2 before CALL performance enhancements actually made
it possible for some shops to do their upgrades. Then when LE cam in, a whole
NEW set of run-time problems showed up.

--
Bill Klein
wmklein <at> ix.netcom.com

2006-02-13, 3:55 am

Arnold Trembley wrote:
><Snip>
> Okay, I'm asking. I have a few war stories about this too.

Migration really has to be broken into two separate subtopics. First,
you should concentrate on the run-time migration. Once you have LE
implemented, then you move to compiler migration. Since the target of
this group is more compiler than run-time, these are compiler issues.

I would say that, today, the three most prominent issues [especially
when the starting point is OS/VS COBOL] are probably:

1) Use of undocumented extensions. Most of these have now been
'post-documented' but as Bill points out, you should not underestimate
the cleverness of programmers to find one more strange way to circumvent
the system. The new compilers or other tools are available to help with
most of these. The credit for identifying many of the undocumented
extensions should go to Bill and the rest of the GUIDE COBOL Project.
They also deserve credit for the fact that IBM now provides Migration
Guides for all of the LE-based languages and for LE itself. [Check the
"Acknowledgment" section of the COBOL Migration Guide.]

2) Probably the item that is easiest to deal with, assuming the right
preparation, is getting the default compiler options for the new
compiler to match what the majority of your applications are using with
the old compiler. And, in this same effort, you must also assure that
when you do recompile a program with the new compiler, you have the
options specified as close to the old options as possible even when they
do not match the defaults you have chosen. Different compiler options
can change the answers and the behavior of the migrated program.

3) Mixtures of Assembler [ASM] with COBOL [or any High Level Language
(HLL)] need to be carefully investigated. Not that ASM is necessarily a
problem, but until you check it out, you cannot be sure. The three best
ways of dealing with ASM: Get rid of it and use native COBOL instead.
Get rid of it and replace it with LE Callable Services. Leave it alone
because it is likely not a real issue.

Certainly these are not the only issues. But, they are common across
the broad spectrum of shops. And, if it pleases the group, a starting
point for other discussions.

Carl

Sponsored Links