[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] 60 character identifiers

From: Brian Tiffin
Subject: Re: [open-cobol-list] 60 character identifiers
Date: Wed, 13 Mar 2013 18:58:04 -0400
User-agent: Opera Mail/12.14 (Linux)

On Wed, 13 Mar 2013 16:00:08 -0400, john Culleton <address@hidden> wrote:

On Tue, 12 Mar 2013 20:59:13 -0400
Patrick <address@hidden> wrote:

Hi Vince

The change in the allowable length is part of the Cobol 2002 standard.

Please see here:

Please go to slide 32 of 35

I have written a bit of OO in several languages and all I have ever
used was singleton classes. I don't really think I need full blown
objection orientation. Cobol 85 already has facilities for code reuse
and code layouts that allow code to be private or public. I would
however like to use naming conventions that show relationships and I
am worried I will run out of space with 30 characters.

Thanks for responding to my post-Patrick

On 12/03/13 08:00 PM, vince wrote:
>> For my needs 30 character identifier are just fine for variables.
>> However I would like to simulate an object oriented approach and I
>> want to use very long file names, for example:
>> parent-child-private-doSomething.cob
>> parent-child-public-dosomethingElse.cob
>> etc
> Now some good news and some bad  ..
> Good:
> In Linux and Windows for that matter you can have long file names
>> Is there a way to set the limit to 60?
>> I am about 3-6 months away from being able to contribute to open
>> Cobol development, have to learn Cobol first and read up on Bison,
>> Flex and Autotools but I could try to tackle this if this is a
>> good 2002 feature to implement.
> Bad:
> Cobol has intrinsic limits for a range of variables that was
> set/created in the 50's.
> Increasing it would LIMIT the compilers/platforms that are used to
> migrate an existing source program that did not conform to a
> reasonable level of the Cobol standards.
> Good:
> There is an organisation based in the USA that has members around
> the world that have an interest in redefining and creating updates
> to the Cobol standard.

Frankly IMO many of the changes made in the standard since 1974 have
tended to defeat one of the chief objectives (no pun intended) of the
language. Programmer A should be able to pick up a program written by
programmer B and understand what is going on. The more features that
are added the less likely this is to be accomplished. I sometimes
worry about the standards writers. Did they ever work in a production
shop? Did they ever hear Grace Murray Hopper discuss her objectives in
designing the language? Not every change is an improvement.

John. I hang out on LinkedIn, COBOL Professionals Group (Grace Hopper Appreciation Society). Donald Nelson posts the odd snippet once in a while.

While discussing in a thread asking if people had met Grace Hopper (it's an open LinkedIn Group, so I don't think I'm in trouble for retweeting the quote).

"...I was chairman of the CODASYL COBOL Committee in the 70s, 80s, and 90s. She was on the CODASYL Executive Committee and we had yearly meetings. She often would accuse me of damaging COBOL because it was not like when she invented it. I usually gently told her that she didn't actually invent it, so she said that she was at least the grandmother of COBOL. She was a wonderful lady with a great sense of humor and was sharp as a tack..."

So, yeah seems they did hear Grace's objectives (and objections).   :)

But I'm all for extending COBOL out beyond its roots. I don't run banks though, and have way too much fun embedding things like the Shakespeare Programming Language into OpenCOBOL. Maybe not where COBOL wants to go, but so much fun to be had.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]