From: arne@vajhoej.dk

On 12/1/2025 8:37 AM, Dan Cross wrote:
> In article <10gg48s$3srom$1@dont-email.me>,
> Dave Froble   wrote:
>> On 11/11/2025 10:23 AM, Waldek Hebisch wrote:
>>> Defining a function need a several lines of
>>> overhead code.  Function calls are more verbose than in other
>>> languages.  There are fixable problems, which however may
>>> appear when dealing with real Cobol code.  In particular
>>> Cobol support old control structures.  In new program you
>>> can use new control structures, but convering uses of old
>>> control strucures to new ones need effort and it is likely
>>> that a bit more effort would be enough to convert whole
>>> program to a different language.
>>
>> I apologize in advance, but that is idiotic.  Any re-write of any
non-trivial
>> application in another language, will never be complete. There will be
errors
>> and things will be lost.  IT   WILL   HAPPEN   !!!  And when done, what
will be
>> the gains in a sideways move?
>
> I got the impression Waldek was referring to updating programs
> written to old versions of COBOL to use facilities introduced in
> newer versions of COBOL, though perhaps I am mistaken.
>
> Regardless, this raises an interesting point: the latest version
> of COBOL is, I believe, COBOL 2023.  But that language is rather
> different than the original 1960 COBOL.  So even simply updating
> a COBOL program is akin to rewriting it in another language.

The Cobol standard has been continuously updated over
the decades. But very few are using the new stuff added
the last 25 years.

For good reasons.

Let us say that a company:
* have a big Cobol application
* want to add a significant chunk of new functionality
* that new functionality could be implemented using
   features from recent versions of Cobol standard

Options:
A) implement it in Cobol using features from recent
    versions of Cobol standard and have the team learn
    the new stuff
B) implement it in old style Cobol, because that is what
    the team knows
C) implement it in some other language where the functionality is
    common and call it from Cobol
D) implement it in some other language where the functionality is
    common and put it in a separate service in middleware tier and
    keep the old Cobol application untouched
E) say NO - can't do it

Few will choose #A. #B, #C and #D are simply more attractive.

Arne

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)