[Info-vax] COBOL Was: Re: Digital

[Bill Gunshannon]

In article <uuudneDDALEhVYbNnZ2dnUVZ_tSdnZ2d at giganews.com>,
	"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
> 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!!!
 
You are joking, right?  I have seen lots of student programs in ADA
back when the school I worked at used it as the primary teaching
language (that was back when we used VMS, too...  :-)

And then we have the last chapter of the book that was used as a course
text which basicly explained how to get around all of these supposed
safety features of ADA when one needed to actually get the job done.

And lets not forget the stuff that is "left up to the implementor" which
means that a program need not run the same on two differnt systems.

Ada is no different than any other language in this respect.  It, too, 
falls under the axiom of your first paragraph.

bill 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>