[Info-vax] COBOL Was: Re: Digital

[Richard B. Gilbert]

On 8/1/2012 6:27 AM, Paul Sture wrote:
> 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.
>

You can write poor code, bad code, and worse code in most languages.
Were that not true, what would they need us for?  Really good code is 
much harder to find!

ADA makes it difficult to write poor code.  Not impossible!!  Most other
languages allow just about anything and the Lord Have Mercy on You!!!