[Info-vax] COBOL Was: Re: Digital

Paul Sture paul at sture.ch
Wed Aug 1 06:27:40 EDT 2012


On Tue, 31 Jul 2012 13:25:19 -0600, Bob Koehler wrote:

> In article <1c33e186a94de7793fe65564135d43a7 at dizum.com>, Nomen Nescio
> <nobody at dizum.com> writes:
>> David Froble <davef at tsoft-inc.com> wrote:
>> 
>>> I can show you tens of thousands of lines of Cobol code that don't
>>> generate a single report.
>> 
>> I can show you ten million lines of COBOL code that does. But my point
>> was and is, COBOL is great for reporting and that is its primary
>> strength.
> 
>    I, too have see large volumes of COBOL that didn't generate reports.
>    But I wouldn't cite it as good programming.
> 
>    I had a lot of 4 times replicated fuctionality generated via cut and
>    paste code instead of calling reusable subroutines.

I came across that as well.  One particular payroll program had code 
replicated far more than 4 times, with names extensively modified so that 
SEARCH didn't catch them all.  I announced several times that I had fixed 
one particular bug, only to be told I hadn't - go back and look again.

Another feature of that program was that it shuffled records up and down 
some kind of array.  Not one of us dared touch that bit of code.

Some bad COBOL programming habits have their heritage in compiler 
limitations, others in common working practices of yore.

Prior to COBOL 85(?) the standard specifically banned the use of global 
variables.  Fortunately VAX-COBOL circa 1981/2 looked ahead and allowed 
these. 

In another example whoever was in charge of defining programming 
standards had decreed that program Sections should be banned because they 
had a performance penalty, and "Perform x thru y" was far more efficient. 

That may have been true on whatever platform he had used before, but the 
reverse was true with VAX-COBOL.  I improved the maintainability of quite 
a few programs by converting them to use Sections.

For those who don't know what COBOL sections are, they are chunks of 
inline code with full access to the main program's data structures but 
with defined (and enforced) entry and exit points.

Did I tell the story about the building society which took on school 
leavers at the age of 16 or 17?  The programmers sat at desks lined up 
facing the front, just like a school class, with the chief programmer 
sitting at a desk on a raised platform overlooking them.  This was in the 
days when you coded onto paper then passed it to the data prep department 
who put it on punch cards.  These folks probably didn't even get to see 
their program running.

>    And when we compiled it, it overflowed the COBOL line counter on
>    DECSYSTEM 20s, leading to a nice latin message.

I came across this mentality too.  Some obviously former COBOL programmer 
had written a huge DIBOL program on RSTS, with not a subroutine in 
sight.  It simply wouldn't fit into the available memory we had on RT-11 
so we had to chop it up and use overlays.

At some places they also paid bonuses based on the number of lines of 
code written.  There might be a more effective way to encourage copy and 
paste but I can't think of one at the moment.

"You can write bad FORTRAN in any language."  The same applies to COBOL.

-- 
Paul Sture



More information about the Info-vax mailing list