From: cross@spitfire.i.gajendra.net
In article ,
bill wrote:
>On 7/12/2025 10:41 AM, Arne Vajhøj wrote:
>> On 7/12/2025 9:35 AM, bill wrote:
>>> On 7/11/2025 8:16 PM, Arne Vajhøj wrote:
>>>> The idea of a 1:1 port is usually bad. Yes - you can implement the
>>>> exact same flow of your Cobol application in Java/C++/Go/C#,
>>>> but that only solves a language problem not an architecture problem.
>>>
>>> The biggest problem with this the idea of going from a domain specific
>>> language to a general purpose language. While you can write an IS in
>>> pretty much any language (imagine rewriting the entire government
>>> payroll currently in COBOL in BASIC!!) there were real advantages to
>>> having domain specific languages. But then, no one today seems to even
>>> consider things like efficiency. Just throw more hardware at the
>>> problem.
>>
>> That argument made sense 40 years ago, but I don't think there
>> is much point today - the modern languages have the features
>> the need like easy database access and decimal data type and
>> the missing features like terminal screen and reporting are no
>> longer needed.
>
>Jack of all trades, master of none.
That's a bad take. It is true that any general-purpose language
may not be great for a particular task, but it does not follow
that just because a language is general purpose means that it a
priori will not be good for a particular domain.
When I work on a compiler, I prefer a functional language (it's
so easy to write parsers in, say, OCaml) but when I work on
kernels, I prefer Rust. I could certainly write a compiler in
the latter, though I prefer the former for that kind of task.
Both are GP languages; but they excel at different things.
COBOL is an interesting case, in particular: it is perhaps best
to think of it as a DSL for expressing business data processing
rules, and at that, it excels. But that doesn't mean that other
languages cannot be gainfully employed to do the same thing. We
have a few decades of evidence now that, for example, Java can
be used very effectively here.
So the "jack of all trades, master of none" quip is just not
supported by evidence at this point, and indeed, there are
decades of contradictory evidence showing the claim to be false.
>>>> You need to re-architect the solution: from ISAM to RDBMS,
>>>
>>> This is the only one I totally agree with but the original problem
>>> had nothing to do with the language. It had to do with the fact that
>>> RDBMS wasn't around when COBOL was written. I have been doing COBOL
>>> and RDBMS since 1980 and it was old code when I got there.
>>
>> True.
>>
>> But it is still a relevant example of where 1:1 will go wrong.
>
>No one thinks 1:1 is a good idea. Many of us think converting to
>a different language, any different language, is not a good idea
>and carries with it risk that need not be taken. Using the logic
>that conversion is always a good think, why is anyone still on VMS?
>Why do people stay on VMS? Because in many cases it is the right
>tool for the job. The same can be said about "legacy" languages.
Programming languages, and operating systems, are fundamentally
different things. You know this.
You may believe that it's never a good idea to rewrite a COBOL
system in some other language, but this ignores that using COBOL
(or continuing to do so) does carry with it certain risks.
First of all, it is a very old language, and while it _has_
been modernized over the years, as you well know, that is only
relevant if the code bases written in it have been updated to
reflect the modernization of the language, which is a very
different thing.
Second, there is the matter of COBOL programs often being deeply
entwined with the surrounding system environment. The issue of
ISAM vs RDBMS has been raised, but that's just one: how about
VTAM versus other UI paradigms, CICS versus other transaction
monitors, and all of other surrounding supporting technologies
(JCL!). IBM, in its infinite wisdom, has made it very difficult
for new programmers to "break" into the mainframe world.
Which brings me to point three, if you want to maintain legacy
COBOL code, you need to bring in programmers who a) are already
skilled in COBOL development (and maintanenance, which is a
related by different skill) or b) somehow get them trained. OJT
is one approach, sure, but you've got to find pepole who are
willing to be trained, as well: if I were a new-grad, or even
someone out of high school, and I were doing my cost/benefit
analysis of where I wanted to apply my focus to maximize my
career potential for the next 10-15 years, it'd be hard to
justify learning COBOL. Sure, I could probably get a job
working in a COBOL shop, but my options for future growth would
be limited to other COBOL shops.
>> you have a Cobol system using ISAM files, then do not want to convert
>> it to a Java/C++/Go/C# system using ISAM files.
>
>If you have a COBOL program using ISAM today it should have been
>converted to DBMS years ago. That does not imply that it should be
>converted to JAVA/C++/Go/C#. Unless we are talking about trivial
>programs, like balancing your checkbook, there are many potential
>problems in moving a well functioning "legacy" program to a new
>language. And to be totally honest, no apparent value.
It does not imply that, but asserting that it should not should
be based on a solid argument, and sadly, your argument is
ignoring legitimate risks associated with leaving a system in
COBOL. They exist.
That doesn't automatically imply a system should be rewritten,
but it doesn't do anyone any good to pretend that those risks
are just FUD.
>>>> from vertical app scaling to horizontal app scaling,
>>>
>>> Not really sure what this means. :-)
>>
>> You can call it cluster support.
>>
>> If you run out of CPU power, then instead of upgrading from a
>> big expensive box to a very big very expensive box then you just
>> add a cluster node more.
>
>OK. But I don't see what that has to do with it being written in COBOL.
It doesn't. I don't see why one can't horizontally scale a
system written in COBOL. I don't know if that's the best way to
go about things, but I don't know that it isn't, either.
>Or are you saying that IBM Systems don't scale?
That's completely orthogonal. Whether a system is designed to
scale horizontally or vertically is a function of the design of
the system and how it was designed. Clearly, applications
written for mainframes have been capable for horizontal scaling
for decades.
A separate question is whether systems designed for IBM
environments and written in COBOL are typically designed with
horizontal scaling in mind; I suspect that _most_ are not.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
